There are a number of things that may affect ethernet latency. I have to disagree that 0.75 ms is normal, unless maybe the AML chips with stock config (in their Bookworm image) are that bad. Can’t recall when I last used one straight stock…
First, summarizing a few quick pings:
GHz to GHz (apu3s):
rtt min/avg/max/mdev = 0.169/0.189/0.219/0.019 ms
GHz to 100MHz (apu3 to Beagle Bone Black):
rtt min/avg/max/mdev = 0.328/0.385/0.572/0.063 ms
GHz to 100MHz (apu3 to frite):
rtt min/avg/max/mdev = 0.238/0.277/0.319/0.023 ms
These are all somewhat tweaked for NTP performance (so latency over throughput). For the frite network interface:
ethtool -C end0 rx-usecs 25 tx-usecs 1 tx-frames 0
Frite NIC/driver has some quirks. 25 is smallest rx delay setting it will accept - reports it set to 24 after that.
After setting frite's rx-usecs to 384, it did get worse:
rtt min/avg/max/mdev = 0.625/0.650/0.730/0.031 ms
And I seem to recall that the default setting was weirdly large, but
I'm not going to reboot just to check the number. So I guess this
matters after all, at least for 805/905 chips. tx-usecs didn't
change pings either incoming or outgoing...
EEE (ethernet energy efficiency) can also delay things. IIRC the frite doesn’t accept setting it to off, but the switches involved here do have it disabled. Oh yeah, frite rejects even --show-eee, oh well.
What has probably had the biggest effect on NTP performance [after reducing the coalesce delays as much as possible, see next posting for more] has been disabling the deeper idle state and, for the BBB and frite, choosing the performance (non-)scaling frequency manager. For frite:
#!/bin/sh
# disable low power states to improve interrupt response time (for chrony, mostly)
for c in 0 1 2 3
do
echo 1 >/sys/bus/cpu/devices/cpu$c/cpuidle/state1/disable
done
# there is only one cpufreq governor to bind them, one to run them...
echo performance >/sys/bus/cpu/devices/cpu0/cpufreq/scaling_governor
exit 0
This doesn’t seem to change the power draw much if at all for the frite, at least when it’s lightly loaded.
With all this (and more that I’ve tried along the way), I find the frite (and the sweetp) make less good NTP servers than the old single cored BBB. The apu3 leaves both of them in the dust, but they’ve been EOL for a couple years now. Uhm, this is mostly in the context of using them with a GPS PPS source, and working on a local ethernet. Talking to anything out there in the Interwebs is doing great of it’s only a few msec off, of course.
Just for the record, I am not a timenut: no rubidium or cesium references in the building, nope. 