[time-nuts] Lowest Power NTP Server

[Didier Juges]

For a lot of IoT applications, 100mS might as well be instantaneous. These
things are used for data logging or remote control where it simply does not
matter.

On Mon, Dec 2, 2019, 7: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.
>