And if I understand correctly we can deal with this by creating baseline based on the difference (can be positive or negative) and then looking at the increase between ticks. Only problem comes in with the clock synchronization events, which would somehow need to be managed? Is this an example where the two pole butterworth would deal better with step change.
And do we use this:
uplink time = Receive - Originate downlink time = rtt - uplink time
And create separate baselines for each and look for increases associated with bufferbloat in uplink or downlink?
Oh, and these two baselines is per reflector. Or something funky like offset kept for each reflector and somehow amalgamated into overall baseline for each direction. But former approach maybe easier?
My first assumption is that these should be rare enough to ignore, which works better if we can rely on a hard minimum rate setting helping us over periods of artificial bufferbloat caused by clocks changing out of phase and then the EWMA adjusting to the new value over time (it should converge fast on the minimum which should hep with bufferbloat)... alternatively we could look for ridiculously large jumps and immediately reset the EWMA in such cases.... but let's only go there if we have to, no? Side-note: the current code has a similar problem in the case when the nearest reflector goes away for whatever reason there will be a jump in the current_RTT values that will take a while to be reflected in baselineRTT, but that is a conscious and acceptable trade-off IMHO (says the guy who can not even tests the script properly )
Not sure.
technically it seems cleaner to do (Originate + rtt) - Transmit here allowing for the upstream system taking a break between receive and transit, but that will in all likelihood have zero practical relevance... given that the 1ms time stamp resolution is a looong time for a recent CPUs.
+1; that is the idea, but now we need to keep track of two EWMAs per reflector instead of a single EWMA for the whole system.
Sweet, then if we can get hping3 made an Official OpenWrt package - who can help with this - any thoughts @richb-hanover-priv(?) then I at least know now how to implement this in script. Unless someone beats me to it.
This offers the potential to get true directional rate control, which is rather exciting.
I'm trying, i have no experience with compiling software, but there are several tutorials which i read. Maybe I am succesful and can provide a hperf3.ipk, but it can only be for Turris Omnia then i suppose
sadly there is no libpcap-dev for openwrt, with it (and much space on the router), somebody could build it "relatively" easy direct on the router and then share
If anyone from the experienced coders out here reads this: PLEASE HALP US
Yeah the code is ancient and does not actually assume Linux to be a thing (effortlessly explained by the code's age), I mostly linked that because the whole thing seems rather short and some of us wanted parts of this project to move to C-code .
Ace - thanks for trying. Don't forget to post issues on this thread because help is pretty fast. It's like placing a match next to a tinderbox. So much eagerness from many different parties. It's quite amazing really.
On first glance they look relatively stable, but the script prints out one of these tables (always ordered by Round Trip I believe, so the exact sequence is not fixed) per iteration making it tedious to track the offset per IP-address.
Since I was running this on my macos laptop outside of my home network, systemd would need to be active at the reflector sites, and I do have my reservations about systemd's prevalence on servers...
In my experience with my own scripts, the offsets are generally very small (mostly <5ms) and stable once ntpd has settled on an accurate time for your system clock (i.e. about 24 hours after a reboot).
In terms of offset size there are some outliers with much larger offsets, as shown in @moeller0's output above (presumably these hosts aren't sending back timestamps based on milliseconds-since-midnight-UTC), but even these offsets are pretty stable.
Just comment out this line to remove the sorting by RTT:
my @results_to_print = sort {&get_sort_string($a) cmp &get_sort_string($b)} @results_to_print;
just for update on compiling i give up. (at least for today).
I tried first with the arm compiler, then with the toolkit (seems to be the makefile which does problems, but i don't understand it completely), in both ways I am differently stuck.
Hope you or another person has more luck or knowledge. or both.
The bunch of hosts with offset around -228670 all resolve to the same owner in Sweden via whois, well possible that they have a 3-4 minute offset of their main clock....
Then, thank you very much for sharing your code and the timestamp reflector list.
Thanks, I guess I need to export the data in a way that is easier to parse for post processing....
Timestamped pings are used to separate out request (upload) and reply (download) latency in exactly the same way as the example script I posted a few weeks back.
)
.