[time-nuts] Lowest Power NTP Server

Tue Dec 3 03:02:45 UTC 2019

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 <tshoppa at 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 <kb8tq at 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 <david at 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 <shalimr9 at 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 tshoppa at 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 shalimr9 at 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 david at 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 phk at 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
>> >>>>>>> phk at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.febo.com
>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
>>
>