Bob, I want to revise my previous statement about ESP8266 WiFi times with some actual measurements. Below are pings to ESP8266 on local Wi-Fi. Most are 0.7ms to 1.1ms with occasional spikes larger than that.
PING 192.168.1.13 (192.168.1.13) 56(84) bytes of data. 64 bytes from 192.168.1.13: icmp_seq=1 ttl=255 time=0.877 ms 64 bytes from 192.168.1.13: icmp_seq=2 ttl=255 time=0.881 ms 64 bytes from 192.168.1.13: icmp_seq=3 ttl=255 time=1.97 ms 64 bytes from 192.168.1.13: icmp_seq=4 ttl=255 time=1.11 ms 64 bytes from 192.168.1.13: icmp_seq=5 ttl=255 time=0.936 ms 64 bytes from 192.168.1.13: icmp_seq=6 ttl=255 time=0.805 ms 64 bytes from 192.168.1.13: icmp_seq=7 ttl=255 time=0.760 ms 64 bytes from 192.168.1.13: icmp_seq=8 ttl=255 time=0.826 ms 64 bytes from 192.168.1.13: icmp_seq=9 ttl=255 time=0.838 ms 64 bytes from 192.168.1.13: icmp_seq=10 ttl=255 time=0.850 ms 64 bytes from 192.168.1.13: icmp_seq=11 ttl=255 time=0.898 ms 64 bytes from 192.168.1.13: icmp_seq=12 ttl=255 time=3.07 ms 64 bytes from 192.168.1.13: icmp_seq=13 ttl=255 time=1.06 ms 64 bytes from 192.168.1.13: icmp_seq=14 ttl=255 time=0.986 ms 64 bytes from 192.168.1.13: icmp_seq=15 ttl=255 time=1.03 ms 64 bytes from 192.168.1.13: icmp_seq=16 ttl=255 time=0.792 ms 64 bytes from 192.168.1.13: icmp_seq=17 ttl=255 time=0.885 ms 64 bytes from 192.168.1.13: icmp_seq=18 ttl=255 time=0.883 ms 64 bytes from 192.168.1.13: icmp_seq=19 ttl=255 time=0.815 ms 64 bytes from 192.168.1.13: icmp_seq=20 ttl=255 time=0.869 ms 64 bytes from 192.168.1.13: icmp_seq=21 ttl=255 time=0.777 ms 64 bytes from 192.168.1.13: icmp_seq=22 ttl=255 time=0.880 ms On Mon, Dec 2, 2019 at 9:56 AM Tim Shoppa <tsho...@gmail.com> wrote: > Bob, I find that 2.4GHz Wi-Fi UDP latency with ESP8266 will frequently be > tens of milliseconds and is never/rarely consistent. > > There are specialized non-WiFi 2.4GHz systems for time distribution that > are far more consistent (possibly even at the tens of microseconds). I > think several years ago on this list, we were talking about tricking > commodity WiFi chipsets into doing these but haven't seen anything as of > late. > > Tim N3QE > > On Mon, Dec 2, 2019 at 8:02 AM Bob kb8tq <kb...@n1k.org> wrote: > >> Hi >> >> Indeed, if you get up into the “many tens” of ms, that rules it out in >> my application. >> A consistent 90 ms would be ok, you could compensate for that. Random >> flopping >> from 4 to 90 … not so much. >> >> It seems like that sort of jitter would get in the way of a lot of >> things. I guess that just >> shows how little I know about a lot of things :) >> >> Bob >> >> > On Dec 1, 2019, at 11:18 PM, David Kern <da...@mju.io> wrote: >> > >> > I did some testing against an ESP32 this evening to see how feasible it >> would be to use this platform. Unfortunately there is extremely high >> jitter on the wifi interface of the ESP32 (between 4ms to 90ms) - even >> after adjusting some settings and disabling all power management. This was >> testing against a quiet wifi network with consistent 1ms pings between my >> workstation to the router. >> > >> > I believe that high jitter would make it difficult to get a good result >> with NTP over wifi. >> > >> > I'm not sure if the 8266 has the same issue. >> > >> > Shame, because with the ultra low power processor you could do some >> interesting things. >> > >> > -David (AD7WZ) >> > >> > >> > >> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> > On Sunday, December 1, 2019 5:24 PM, Didier Juges <shali...@gmail.com> >> wrote: >> > >> >> "Didier, I'm not sure I saw Bob write that 5uS was his goal." >> >> >> >> I realize that now, I saw 5uS in another email thread and wrongly >> >> associated the two :) Happens when doing two things at once... >> >> Anyhow, I mentioned it because I did do some experiments early on the >> >> ESP8266 and the seemingly random flash reload was quite unexpected. It >> was >> >> in the 10's of uS if I recall, so of course not a real concern for this >> >> application but it could be in other cases. Something to keep in mind >> when >> >> comparing architectures. >> >> >> >> On Sun, Dec 1, 2019 at 5:00 PM Tim Shoppa tsho...@gmail.com wrote: >> >> >> >>> Didier, I'm not sure I saw Bob write that 5uS was his goal. >> >>> I don't think anyone would claim that ordinary cheap WiFi can achieve >> >>> consistent sub-millisecond variations in latency. >> >>> Tim N3QE >> >>> On Sun, Dec 1, 2019 at 5:06 PM Didier Juges shali...@gmail.com wrote: >> >>> >> >>>> You should look at latency. The ESP8266 has serial (SPI) flash and a >> >>>> relatively small internal cache. When the chip needs to load code >> from >> >>>> flash, that can take a while, compared to the 5uS target. Great for >> cheap >> >>>> IoT stuff, not so great for time sensitive, in my opinion. >> >>>> On Sun, Dec 1, 2019 at 2:01 PM David da...@mju.io wrote: >> >>>> >> >>>>> I'd think one of the ESP32's would be a fine choice. They have some >> >>>>> good >> >>>> >> >>>>> power management options to wake up periodically to do the work, >> making >> >>>>> for >> >>>>> even lower power consumption. >> >>>>> Looks like someone has already written some code that could be >> adapted? >> >>>>> https://github.com/DennisSc/PPS-ntp-server/blob/master/README.md >> >>>>> -David >> >>>>> -------- Original Message -------- >> >>>>> On Dec 1, 2019, 09:49, Bob kb8tq wrote: >> >>>>> >> >>>>>> Hi >> >>>>>> So something like one of the many ESP32 based boards? >> >>>>>> Of course when it comes to the “code from scratch” part there is >> the >> >>>>>> problem that I’m >> >>>>>> pretty (most would say very …) lazy :) :) :) >> >>>>>> Bob >> >>>>>> >> >>>>>>> On Dec 1, 2019, at 12:29 PM, Poul-Henning Kamp p...@phk.freebsd.dk >> >>>>>>> wrote: >> >>>>>> >> >>>>>>> You can do better than RPi, since a NTP server basically >> >>>>>>> only needs to understand two packets: IP/UDP at port 123 >> >>>>>>> and ARP packets. >> >>>>>>> There are WiFi enabled microcontrollers that could be taught how >> >>>>>>> to do that, but you'd have to write up your NTP daemon from >> scratch >> >>>>>>> which is not hard when you do not have to do the "sync clock from >> >>>>>>> remote servers" part. >> >>>>>>> -- >> >>>>>>> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> >>>>>>> p...@freebsd.org | TCP/IP since RFC 956 >> >>>>>>> FreeBSD committer | BSD since 4.3-tahoe >> >>>>>>> Never attribute to malice what can adequately be explained by >> >>>>>>> incompetence. >> >>>>>> >> >>>>>> time-nuts mailing list -- time-nuts@lists.febo.com >> >>>>>> To unsubscribe, go to >> >>>>>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> >>>>>> and follow the instructions there. >> >>>>> >> >>>>> time-nuts mailing list -- time-nuts@lists.febo.com >> >>>>> To unsubscribe, go to >> >>>>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> >>>>> and follow the instructions there. >> >>>> >> >>>> time-nuts mailing list -- time-nuts@lists.febo.com >> >>>> To unsubscribe, go to >> >>>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> >>>> and follow the instructions there. >> >>> >> >>> time-nuts mailing list -- time-nuts@lists.febo.com >> >>> To unsubscribe, go to >> >>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> >>> and follow the instructions there. >> >> >> >> time-nuts mailing list -- time-nuts@lists.febo.com >> >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> >> and follow the instructions there. >> > >> > >> > >> > _______________________________________________ >> > time-nuts mailing list -- time-nuts@lists.febo.com >> > To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> > and follow the instructions there. >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. >> > _______________________________________________ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.