overview for Gandalf1783

Guaranteed function return time in C/C++? in c/[email protected]

[–] [email protected] 1 points 1 year ago

Thanks, its not a university project, more of a home project trying to beat some other software :)

Fore more info, I just posted under @[email protected] comment on this post!

It will be open source later on, but I have to tidy everything up before pushing to github

Guaranteed function return time in C/C++? in c/[email protected]

[–] [email protected] 3 points 1 year ago

Nope, to be specific, my application is going to apply many effects onto light sources (DMX).

Those effects are going to be sine/cosine, pwm, triangle and more. Those make my head hurt most, especially since I cannot predict how long the calculation takes for the 8192 values (512 channels times 16 universes, this can/will expand to even more, e.g. 512 channels times 128 universes).

Those output-frames need to be fluent, e.g. it should not lag (-> high refresh-rate, max allowed is around 40-45 Hz).

Currently, Im running in lockstep, e.g. a single thread decoupled from the parent which first has to run inputs (e.g. network input, etc. and then has to apply effects (e.g. math operations) on many thousands of parameters.

While I only need 8 bit precision per channel ( a channel is a single byte), some devices may take 2 channels for fine control (e.g. 16 Bit), where my accuracy has to be higher.

I think that I can remove the inputs, I can just decouple them into another thread and just update some shared buffer, where it can be always read regardless of how long the input method actually takes.

Btw, while technically there can be multiple effects running (e.g. a sine on channels 1-12, a triangle on 32-35), no channel will ever have multiple effects. So I am technically always computing max. 8192 (or however many universes times 512) values.

I cannot post code yet (still have to tidy up the codebase), but it will be open source later on.

Guaranteed function return time in C/C++? in c/[email protected]

[–] [email protected] 1 points 1 year ago (2 children)

In general, dropped frames/effects that either take too long or are lost are not inherently bad, since theres another one in just 10-20ms.

Its just that I want to make sure that these function are not taking literal seconds or longer.

But thanks, I already feared this was the case. I will take a look on an RTOS, I just havent read far into it and therefore dont know how you would code something against that.

Thanks anyways!

9

Guaranteed function return time in C/C++? (feddit.de)

submitted 1 year ago by [email protected] to c/[email protected]

6 comments fedilink

I tried searching on google, but I need to apply "effects" as in mathematical equations (especially sine waves) for around 8192 values. All of this should ideally be around a few milliseconds, but should not take longer than 10ms.

Similarly, I need to run Input on 8192 values too. This most likely will happen with memcpy, from one array to another, but this might take longer as it can have multiple inputs (network/serial/usb).

In this case, I have to guarantee, that both steps before outputting do not take longer than around 25 ms.

Is there a way to definitely limit these functions to timeframes, so they will be killed/returned if taken to long?

I cannot spawn new threads for each input/effect step, as it takes some time to build these threads. Both methods will be called in a loop, directly after another, so they will run approx. 30-45 times a second.

Whats the way to limit these? I can surely guarantee the read-time where I copy a buffer, but running maths operations seems like something that could potentially take too long.

Realtime-Operating Systems also can somehow guarantee those times, so whats the way here?

(BTW, this all is going to run on a minimal debian linux system, with the GUI decoupled from the actual mehhanism.)

One of my ideas would be to pre-calculate those values in some other thread, lets say the next 100 ops for a given value and then just replay them, so I have some buffer.

Other ideas?

11

L2TP/IPTABLES: Routing ETH0 default traffic (feddit.de)

submitted 1 year ago by [email protected] to c/[email protected]

0 comments fedilink

Hey y'all,

I have my L2TP Client on my Raspi CM4 setup.

It should function as a VPN Gateway. It connects to my home network and enables clients connected to eth0 to reach devices at home.

In this case, I am using eth2 (my phone via USB tethering) to connect to the internet, to make sure no NAT issues or similar are occuring.

I can traceroute to our FritzBox (Router) which is sitting before the l2tp server (which is running on pfsense), meaning all of my home network is reachable through the tunnel.

vpngw:~# traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
 1  192.168.1.251 (192.168.1.251)  46.765 ms  46.553 ms  51.218 ms
 2  192.168.178.1 (192.168.178.1)  61.878 ms  61.784 ms  66.704 ms

There is also no issue to get to pfsense itself (192.168.1.251) (curl/ping).

Current interfaces on vpn gateway:

vpngw:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d8:3a:dd:07:da:4a brd ff:ff:ff:ff:ff:ff
    inet 10.1.9.1/24 brd 10.1.9.255 scope global eth0
       valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether d6:eb:d2:ac:7a:c0 brd ff:ff:ff:ff:ff:ff
4: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether d8:3a:dd:07:da:4b brd ff:ff:ff:ff:ff:ff
5: vpnbridge: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 52:12:ec:25:25:ee brd ff:ff:ff:ff:ff:ff
9: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 72:31:7f:86:2d:7e brd ff:ff:ff:ff:ff:ff
    inet 172.20.10.2/28 brd 172.20.10.15 scope global dynamic noprefixroute eth2
       valid_lft 84939sec preferred_lft 74139sec
11: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1410 qdisc pfifo_fast state UNKNOWN group default qlen 3
    link/ppp 
    inet 192.168.10.1 peer 192.168.1.251/32 scope global ppp0
       valid_lft forever preferred_lft forever

The iptables running on the vpn gateway:

vpngw:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   udp  --  anywhere             anywhere             udp dpt:l2f redir ports 7331

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere

And the current routes:

vpngw:~# ip route
default via 172.20.10.1 dev eth2 proto dhcp src 172.20.10.2 metric 209 
10.1.9.0/24 dev eth0 proto kernel scope link src 10.1.9.1 
172.20.10.0/28 dev eth2 proto dhcp scope link src 172.20.10.2 metric 209 
192.168.0.0/16 via 192.168.1.251 dev ppp0 
192.168.1.251 dev ppp0 proto kernel scope link src 192.168.10.1

(These routes may not be correct, as in some were added due to trial and error, and therefore do not have any function)

IPTables has to redirect the 1701 L2TP port due to my routers settings, it just blocks those ports. Therefore I am running everything over Port 7331 and am rewriting this on my pfsense back to 1701. I have added the 3rd Route (192.168.0.0/16 over 192.168.1.251) to make my home devices reachable.

What I want to achieve: Clients connect on eth0 (10.1.9.0/24) can access the firewall and more local devices running at my house. However, they cannot connect to the internet. In my case, this does not need to happen over the L2TP VPN. This is why I left the default ip route on the vpn gateway, hoping all other traffic would just flow over the WAN of the gateway instead of through ppp0.

I currently dont have traceroute on the client (connected on eth0 with ip 10.1.9.10), so I cannot do one there. However, this is one from the vpngw with eth0's ip as a source address:

vpngw:~# traceroute -s 10.1.9.1 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
 1  192.168.1.251 (192.168.1.251)  35.315 ms  46.007 ms  45.905 ms
 2  192.168.178.1 (192.168.178.1)  55.449 ms  61.238 ms  61.131 ms

vpngw:~# traceroute -s 10.1.9.1 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  172.20.10.1 (172.20.10.1)  0.851 ms  0.707 ms  0.820 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * *^C

As you can see, it cannot reach 1.1.1.1. The gw without any source address can reach it:

vpngw:~# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  172.20.10.1 (172.20.10.1)  3.731 ms  3.493 ms  3.334 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  one.one.one.one (1.1.1.1)  31.162 ms  29.583 ms  32.708 ms
 8  one.one.one.one (1.1.1.1)  29.658 ms  29.678 ms  29.651 ms
 9  one.one.one.one (1.1.1.1)  36.693 ms  35.672 ms  36.714 ms
10  one.one.one.one (1.1.1.1)  38.520 ms  44.091 ms  37.902 ms
11  one.one.one.one (1.1.1.1)  62.050 ms  61.541 ms  48.789 ms
12  one.one.one.one (1.1.1.1)  48.346 ms  60.115 ms  54.037 ms
13  one.one.one.one (1.1.1.1)  53.662 ms  59.044 ms  58.985 ms

Whats the solution here? I am sure I missed some information about my routes. I left the default route, shouldn't the kernel route the incoming traffic to 1.1.1.1 from clients connected to eth0 over this? Do I have to define how to handle returning traffic (e.g. the packets are routed correctly, but the response is not arriving back at the client at eth0)?

Thanks for your help!