Time Advertisement on OpenWrt - bugs and misfeatures

Thank you for the explanation of the reason for the mini-hostap rather than the full one. I've been looking at the wpad mini source code, and I see the Time Advertisement code in src/ap/beacon.c. I'm wondering what is the reason that the full wpad package is required to support Time Advertisement? It would be very nice to use the standard wpad mini package.

Indeed, that's why I'm restarting hostapd with "wifi" after NTP sets the clock.

You make an interesting point about clock drift. The TSF timer isn't synchronized to NTP like the router system clock, so it might drift a bit over a long time. This seems like a design flaw in the IEEE standard, but a minor one. It should be easy to have, say, a cron job that restarted wifi every day or so.

Hello @gazotz

Would you mind explaining you manage precision time over network with OpenWRT

I am curious to know how close can we sync clocks to each other over ethernet using consumer hardware.

So that would be start of IEEE 1588 support where possible and using hardware TSF counter for PTP clock emulation, and lacking both other those, what is the best time synchonization still achievable, is 1 microsecond synchronicity achievable with something like regular PC and archer c7 for instance ?

is 1us achievable over typical ethernet? Good luck... here's 11 pings to my router:

64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=1 ttl=64 time=0.492 ms
64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=2 ttl=64 time=0.311 ms
64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=3 ttl=64 time=0.252 ms
64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=4 ttl=64 time=0.271 ms
64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=5 ttl=64 time=0.288 ms
64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=6 ttl=64 time=0.257 ms
64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=7 ttl=64 time=0.999 ms
64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=8 ttl=64 time=0.926 ms
64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=9 ttl=64 time=0.279 ms
64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=10 ttl=64 time=0.272 ms
64 bytes from pirouter.lan (fd56:9122:70e4:1::6): icmp_seq=11 ttl=64 time=0.360 ms

The shortest was 252 us and the longest was 999 us

so, variation on the order of hundreds of microseconds from ping to ping... seems unlikely you're going to get better than 50-100us variation between clocks even after a while of smoothing that out.

serial port pulse-per-second from a GPS directly can maybe get 1us accuracy, my understanding is over USB you're more like 50-100us also. If you want very precise clocks I'd go with a serial-port GPS on each device that needs synchronization.

And what/where is your precision "Master Clock" time source?

What does this statement mean?

(It seems like you're implying to somehow make a WiFi chip a pseudo precision clock - but I'm not sure?)

According to this article, the TSF counter would allow maintaining synchronicity within at least 25 microsecond

As for the master clock, I would use the router's clock and resynchronize clients on an hourly basis.

My concern is maintaining the clocks of cameras within one frame (1/240fps) of precision, so anything better than about 2 millisecond is good for my purpose.

I also stream real time audio over the network to maintain perfectphase control up to 20kHz you need to be better than 50 microsecond, although anything under 1 millisecond is still excellent.

If anyone needs a true good clock then I suggest this one

Or a GPS receiver such as the 5$ NEO-6M. Although I believe you need at least one gpio to sync your system clock to it

I combined a raspberry pi 4B with the following GPS receiver:

and then configured the pi's NTP server to use the PPS signal from the GPS... and then enabled software PTP on the pi's ethernet interface...
see: https://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html

1 Like

note that these oscillators are not necessarily correct. It's possible to synchronize everything exactly to a clock, and not know exactly what that clocks oscillation frequency is. For example you could have a device that says that it has a 25Mhz clock, and you could have a whole bunch of devices synchronized to it exactly, but then if you measure it with a precise atomic clock it's really 24.74128 Mhz and they're all wrong systematically.

not sure how that would affect your usage.

As far as I know, each clock runs at its own frequency inside of the error margin.

Ntp, PTP and TSF corrects the absolute drift between clocks but not their individual drift rate / frequency since that is part of the oscillator itself and not controllable as far as I know.

As far as I know, most rtc use a 32768khz( 20 to 100 PPM) crystal/piezo electric mechanical oscillator and then use a phase locked loop to multiply this frequency (which increases clock jitter at this higher frequencies)

Without ieee1588 hardware in your ethernet, TSF looks like the best candidate for ubiquitous sub 50 microsecond clock synchronizing but I have no idea of often this functionality is exposed outside of the silicon and binary blob. (In my case the archer c7)

As I understand it something like NTP measures drift rate and compensates for it by either adding a few ticks every so often or ignoring a few every so often. If NTP detects the oscillator is 100ppm slow for example then it will every second or so add 100us to the clock or some such thing.