search

flightaware / dump1090

Dump1090 is a simple Mode S decoder for RTLSDR devices
Other
898 stars 235 forks source link

Long default network flush time #244

Open wiedehopf opened 2 months ago

wiedehopf commented 2 months ago

https://github.com/flightaware/dump1090/blob/a80ba8f82a74c90a29619ddbc10909c561198541/dump1090.c#L125

500 ms seems quite a long default. 50 or 100 ms might be a good choice and not too many packets still?

mutability commented 2 months ago

I'm not particularly attached to 500ms, but what's the use case you're looking at here that would need a lower value?

The lower limit is going to depend on the main loop's sleep time, so ~50ms (if demodulating) or 100ms (if in net-only mode) minimum.

The flush interval only kicks in if data has not been otherwise written due to the buffer filling, which happens at the ~1300 byte mark by default; so the effective interval is going to be <500ms anyway for data rates above about 2.6kB/s

wiedehopf commented 2 months ago

General timing precision consistency for aggregator programs for example. Or really any other 2ndary program to do something with the data (somewhat rare). There are no guarantees i'm well aware.

Doesn't hurt for mlat-client if you add if you add satellite internet or something to the latency (ok this is kinda far fetched).

The flush interval only kicks in if data has not been otherwise written due to the buffer filling, which happens at the ~1300 byte mark by default; so the effective interval is going to be <500ms anyway for data rates above about 2.6kB/s

So that means the latency behaviour changes unexpectedly when there is low traffic. And it shouldn't hurt to improve that by just defaulting to 100ms. While for typical stations it won't change the number of packets emitted most of the time as the buffer fills anyhow.

I'm not saying i have a really good argument here, but i don't really see a downside of lowering that interval.

mutability commented 2 months ago

I'd guess that 95% of installs are only transporting raw data locally (same host, or a host on the same local network) so maybe that's a good argument for pushing the latency right down, since lots of small writes doesn't matter so much there.

wiedehopf commented 2 months ago

The only concern of going to 100 or 50 ms might be people on metered mobile data connections. But those could always change --net-ro-interval manually if it's a concern.

DSL connections won't be affected by even 50 ms flush interval.

On readsb i'm defaulting to 50 ms (with some extra special casing if it's set at 50 ms or lower and demodulating, then it flushes immediately after the demodulation buffer is processed).

100 ms will be a big improvement over 500 ms and good enough for almost all situations. And considering for the longest time 200 ms was the effective dump1090-fa default due to the default configuration file, 100 ms will just be halfing that so it should be a somewhat conservative change in that regard.

Maybe go for 90 ms just to make sure the 100 ms timed net only loop more consistently flushes instead of comparing roughly 100 ms to 100 ms.

I'll just make a PR for 90 ms, if you would rather go to straight to 45 ms i can easily amend the PR.

https://github.com/flightaware/dump1090/pull/245