[time-nuts] Serial or other simple protocols for exchanging time

Tim Shoppa tshoppa at gmail.com
Thu Aug 15 15:35:42 UTC 2019


Bob, ntpd for ages has supported broadcast/multicast UDP.
https://www.eecis.udel.edu/~mills/ntp/html/assoc.html#broad

If you care about security it's like a bag of angry cats. And the
one-way-ness removes the ability to measure round-trip delay. So it's
pretty rare to see it being used well.

Tim N3QE

On Thu, Aug 15, 2019 at 11:08 AM Bob kb8tq <kb8tq at n1k.org> wrote:

> Hi
>
> Which all sort of begs the question:
>
> Why not a simple “broadcast UDP” once a second time packet approach for a
> home LAN?
>
> Unless you get really crazy, it’s not going to be a very big packet.
> Seconds since some
> arbitrary point in time. Time zone offset. Maybe a leap second count.
> Server ID maybe.
> Less than 100 bytes not including the overhead.
>
> Bob
>
> > On Aug 15, 2019, at 5:36 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
> >
> >
> > ausserirdischesindgesund at gmail.com said:
> >> I am a newbie and am wondering what options there are for exchanging
> time
> >> on a more basic level than NTP or PTP (that is for situations when a
> >> full network stack is too complex).
> >
> > You haven't described your problem fully yet.
> >
> > Are you interested in client side or server side?  (or both)
> >
> > What sort of environment are you working in?  What sort of hardware do
> you
> > have available?
> >
> > NMEA over a serial port is probably what you want, but...
> >
> >
> > Raspberry Pi and similar are not very expensive.  They come with
> networking
> > software.  The Pi isn't very nice for time-nut work over the net because
> the
> > Ethernet is on USB which adds jitter and/or hanging bridges.  It does
> have
> > GPIO.
> >
> >
> > There is a lot of things you can do without a "full network stack".
> >
> > What level of hacking is reasonable depends on your environment.  For a
> setup
> > at home, you are unlikely to annoy anybody else.
> >
> > The Alto firmware could boot over the (3 MB) Ethernet.  The boot servers
> would
> > periodically send a boot-loader packet to a reserved hardware address.
> The
> > firmware only had to setup the hardware to receive a packet, wait for
> one,
> > sanity check things, and jump to it.
> >
> > If you use UDP rather than TCP, the "stack" level packet format is much
> > simpler.  Retransmission becomes trivial if you only have one un-ACKed
> packet
> > to consider.  Performance on a LAN is OK most of the time.
> >
> > For something like a NTP server, you can avoid routing and ARP by
> sending the
> > reply back where it came from.
> >
> > For the client side, the normal problem is finding the server.  If you
> only
> > have one server, you can wire in the address.
> >
> >
> >
> >
> > --
> > These are my opinions.  I hate spam.
> >
> >
> >
> >
> > _______________________________________________
> > 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.
>



More information about the Time-nuts_lists.febo.com mailing list