Re: [time-nuts] once again timenuts in the news

[Steven Sommars]

 Usenix paper:
https://www.usenix.org/system/files/conference/nsdi18/nsdi18-geng.pdf
Usenix talk:  https://www.usenix.org/conference/nsdi18/presentation/geng
   At the end of the talk the presenter mentions WAN sync between labs at
Utah, Wisconsin and Clemson "under 10 microseconds"

I'd like to see an error analysis and a complete list of prerequisites.
How does RTT/2 disappear?








On Mon, Jul 2, 2018 at 12:42 PM, jimlux  wrote:

> https://news.slashdot.org/story/18/07/01/2022232/google-and-
> nasdaq-pursuing-nano-second-precision-in-network-time-protocol
>
> https://www.nytimes.com/2018/06/29/technology/computer-netwo
> rks-speed-nasdaq.html
>
> 100 ns... Doesn't seem particularly challenging if you have something like
> PTP.
>
> But there's this:"The new synchronization system will make it possible for
> Nasdaq to offer “pop-up” electronic markets on short notice anywhere in the
> world, Mr. Prabhakar said"
>
>
> OK, 100ns world wide is a trickier proposition.
>
>
> ___
> 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.

Re: [time-nuts] NIST

[Steven Sommars]

I found the public comments from Microsemi
,
but couldn't locate my response.   At one time the full set of RFI public
responses was on-line.

The NIST 60 kHz time service is widely used by inexpensive clocks, but I
find little use by public NTP servers.




On Fri, Aug 10, 2018 at 6:56 PM, Larry Sampas  wrote:

> My favorite RFI (Request for Information):
> https://www.fbo.gov/index?s=opportunity=form=
> 4f5c8b176af03d89abb1a318624c944b=core&_cview=0
>
> The public comments should be around someplace.
>
> Larry Sampas
>
> On Fri, Aug 10, 2018 at 5:05 PM, Andy Backus  wrote:
>
> > I have a very simple circuit for a (microwatt) 60 kHz transmitter that
> > takes a digital input (only needs someone to calculate out the WWVB code
> > from a GPS clock).  The biggest problem I find with my WWVB clocks is
> > getting a good signal, which is highly depend on location in the house
> and
> > orientation of the device's antenna.  So I have one WWVB receiver in a
> good
> > place and key my little transmitter as a "translator" elsewhere in the
> > house.
> >
> >
> > Andy Backus
> >
> >
> > 
> > From: time-nuts  on behalf of Dana
> > Whitlow 
> > Sent: Friday, August 10, 2018 1:34 PM
> > To: Discussion of precise time and frequency measurement
> > Subject: Re: [time-nuts] NIST
> >
> > I wonder if anybody will market a GPS-to-WWVB translator?
> >
> > Dana
> >
> >
> > On Fri, Aug 10, 2018 at 2:45 PM, Robert LaJeunesse 
> > wrote:
> >
> > > I'd say it does get more detailed, with the $49M in cuts described
> > > generally in groups here:
> > >
> > > https://www.nist.gov/director/fy-2019-presidential-budget-
> > > request-summary/fundamental-measurement-quantum-science-and
> > >
> > > One item: "-$6.3 million supporting fundamental measurement
> > dissemination,
> > > including the shutdown of NIST radio stations in Colorado and Hawaii"
> > >
> > > Looks like some of your friends might be looking for work. Not good.
> > >
> > > Bob L.
> > >
> > >
> > > > Sent: Friday, August 10, 2018 at 3:11 PM
> > > > From: "Magnus Danielson" 
> > > > To: time-nuts@lists.febo.com
> > > > Cc: mag...@rubidium.se
> > > > Subject: Re: [time-nuts] NIST
> > > >
> > > > Bert,
> > > >
> > > > The closes I come is this, burried in the line of Funamental
> > > Measurements:
> > > > https://www.nist.gov/fy-2019-presidential-budget-request-
> > > summary/budget-tables
> > > >
> > > > It doesn't get more detailed than that.
> > > >
> > > > The T work is relatively small group in the big NIST.
> > > >
> > > > Cheers,
> > > > Magnus
> > > >
> > > > On 08/10/2018 08:29 PM, ew via time-nuts wrote:
> > > > >
> > > > > NIST total budget for 2017 was close to 965 Million, I was curios
> > > trying to find out what the Time and Frequency Division  portion was.
> No
> > > Luck. Does any one know?Thanks   Bert Kehren
> > > > > ___
> > > > > 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.

Re: [time-nuts] Network Time Puzzle

[Steven Sommars]

See figures 7 & 8 in
http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf

When a router forwards an NTP packet multiple potential egress links may
have equal cost.  In order to distribute the traffic across the egress
links the router can use the IP addresses and UDP source/destination port
numbers to select a link.  Doing this reduces the likelihood of
out-of-sequence packets.

Instead of having N x 1 Gbps links between two adjacent routers it is
preferable to have a single N Gbps link.  The latter may not be available
or cost effective.

Similar behavior can be found at network layer 2 for link aggregation
groups, see https://en.wikipedia.org/wiki/Link_aggregation .

Steve Sommars


On Sun, May 26, 2019 at 7:16 AM Peter Martinez via time-nuts <
time-nuts@lists.febo.com> wrote:

> Greetings, Time Nuts, from a new member.
>
> I have two old Windows XP laptops on which I can lock the timing to GPS,
> which means I can read the time at which things happen to a few
> microseconds.  I thought I would modify some of my old NTP software, both
> client and server, to make use of this and see how well the ntp system
> performs.
>
> It's all working fine, but in the course of trying to decide what to set
> for
> the "local port address", I discovered a strange effect.  If I set the
> local
> port address of my ntp client to one value (somewhere between 49152 and
> 65535 for example), then query an ntp server on the internet, then change
> the local port to another value and do it again, the Time Offset and Round
> Trip Delay readings come back different. Change the port back and the
> offset/delay values go back to the original.  Same on the other PC.  But
> ONLY on some distant servers.  Most of them don't show the effect.
>
> I have seen jumps of about 6.2msec in delay and 3.1msec in offset, but the
> offset might be positive or negative.  This leads me to think that this
> wierd effect is a propagation delay occuring in one of the two paths,
> either
> the path from me to the server or from the server back to me.  On some
> servers I have seen the delay jump by 12.4msec with no jump in the offset.
> This must be a 6.2 msec. delay in BOTH propagation delays.  In this case,
> four different values of local port address can give rise to 4 different
> delay/offset combinations.  A scatter plot of delay versus offset, with
> random port address, shows four dots in a diamond shape.  Different delay
> values give different-sized diamonds.  Routes with more than one such
> effect
> show even prettier patterns of superimposed diamonds.  The effect is
> stable
> over time, at least for the length of time (weeks) I have been studying it.
>
> If this is real (and I am fairly sure it's not a bug at my end or at the
> servers), then it will impact on the accuracy which can be achieved with
> NTP.  I ask myself "Why does the network do this?".  Is there a valid
> reason
> for it, or is it a side-effect of something else?  Has anyone else seen
> this
> effect?  Is there anyone out there reading this who could modify an NTP
> client program so that the loal port address can be changed manually, and
> see if this is a widespread feature of the internet.  If this effect
> didn't
> occur, NTP could be a lot better than it is now.
>
> Regards
> Peter Martinez G3PLX
>
>
> ___
> 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] PTTI 2020 Keynote

[Steven Sommars]

FYI

https://www.ion.org/ptti/call-for-abstracts.cfm

PTTI Keynote Address
"Atomic Timekeeping as a Hobby"
Tom Van Baak, Leapsecond.com
___
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.

Re: [time-nuts] Noob question, NTP stratum 1.

[Steven Sommars]

US operators are planning to shut down their CDMA networks.  See for example
https://www.fiercewireless.com/wireless/verizon-to-shut-down-2g-cdma-1x-network-by-end-2019

I wouldn't be surprised to see this date get pushed back though.



On Mon, Jul 22, 2019 at 8:05 PM K5ROE Mike  wrote:

> You may want to look at something an Endrun CDMA ntpserver for the
> datacenter; don't need view of the sky. Available on the used market sub
> $1k
>
> Standard solution for this scenario.
>
>
> K5ROE Mike
>
> On 7/22/19 10:50 AM, wildylion via time-nuts wrote:
> > Yeah, of course I will NOT do anything home-grown for the datacenter.
> >
> > But currently it uses 3 Stratum 2 NTP servers, one per DC, with them
> referencing a list of 4 close-by Stratum 1 sources.
> >
> > ntpstat generally says that time is correct within ~50 ms, while jitter
> and offset generally don't exceed 1ms, the root dispersion is quite large.
> > Also these Stratum 2 NTPs are run from Cisco routers, which I doubt are
> very good at timekeeping.
> >
> > When I implemented this scheme, I offered to have S2 on a set of x86
> servers, but was overruled by management who said it'll be better if we run
> S2's off Cisco gear.
> >
> > So what if we add a couple GPSDO's into the mix, using them as primary
> time sources alongside public Stratum1 NTP servers for sanity check? And of
> course moving the S2's to something more stable.
> >
> > My own, homegrown S1 pool NTP is another matter entirely - I think just
> a tuned Raspi with a M8N will be enough?
> >
> > Sent with [ProtonMail](https://protonmail.com) Secure Email.
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, 22 July 2019 г., 17:38, Taka Kamiya 
> wrote:
> >
> >> If you have 100 production servers with database, I am going to
> strongly discourage you from taking a "home grown" route.  You will need
> multiple redundant implementation with fail-over.  You mentioned budget.
> How much are your bosses willing to pay for consultation fees for failed or
> corrupted data?  I am assuming you are talking about Oracle RDBMS with
> minimum of 2 way RAC.
> >>
> >> If you are using collocation services, doesn't the center itself offer
> ntp service for fee?
> >>
> >> If you need 24 hour hold-over, I will take nothing less than multiple
> ovenized crystal OSC GPSDO with redundancy per center.  Then feed that into
> ntp server with multi-location fail over.
> >>
> >> If I were responsible for managing such system and if my boss will want
> me to go cheap route, I will seriously fight it.  If it's successful, your
> boss will get credit for spending little and getting a big benefit.  WHEN
> it fails, it's going to be your fault for not mitigating risk
> sufficiently.  Try pricing out 2 days of consulting fees
> >>
> >> ---
> >> (Mr.) Taka Kamiya
> >> KB4EMF / ex JF2DKG
> >>
> >> On Monday, July 22, 2019, 10:05:56 AM EDT, wildylion via time-nuts <
> time-nuts@lists.febo.com> wrote:
> >>
> >> Hello there,
> >>
> >> I wanted to ask for advice regarding NTP
> >>
> >> Situation 1:
> >> What I currently have is a uBlox M8N GPS puck I'm planning to use with
> the Raspberry PI. Seems like it should work almost out of the box with some
> kernel tuning, but I have a question about short term stability in the
> event of GPS loss - how well will the board hold over if it's lost GPS for,
> say, 24 hours?
> >>
> >> Situation 2:
> >> Also, there's a need for more dependable NTP time sources for our
> colocated spaces.
> >>
> >> What we have is about 100 servers, some of them running DBMS that
> wouldn't like clock drift at all. After a recent incident involving NTP
> I've got an idea to install GPSDO time servers in each datacenter and slave
> them to stratum2's that will be actually distributing time to clients.
> >>
> >> All the certified GNSS disciplined clocks are really expensive (way
> more than the management would approve), so what I'm planning to do is
> possibly getting a couple LeoNTP units and using them as the root time
> sources, would this be a good plan? Of course, all the NTP infrastructure
> will be monitored, and possibly we'll use Stratum 2 servers which would be
> slaved to GPSDO S1's AND the public NTP pool for sanity checks.
> >>
> >> Maybe BG7TBL's units instead of LeoNTP?
> >> Is that a good idea?
> >>
> >> Sent with [ProtonMail](https://protonmail.com) Secure Email.
> >> ___
> >> 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 

Re: [time-nuts] can of worms: time-of-day in a community radio station

[Steven Sommars]

Each NTP Pool server's real-time status can be seen at
https://www.ntppool.org/scores/*ip_address*
I can't answer questions about the monitor's source code


NTP server timestamp errors happen occasionally.  Internet delays and
losses are unpredictable. My paper
 discusses such
NTP time transfer issues (thanks Tom).
A diverse set of servers may be desirable:  Using eleven stratum 2 servers
with common stratum 1 sources may not meet your requirements.
If the bad guys can intercept NTP traffic timestamps can be altered, unless
NTP authentication is used.  [This rarely happens.]





On Mon, Nov 4, 2019 at 2:51 PM Bob kb8tq  wrote:

> Hi
>
> Since “rogue” servers are rare, bumping up the number of servers fairly
> quickly
> gets you to a very high degree of confidence. Is that 5, 7, 9, or 11? It
> sounds like
> a wonderful topic for somebody’s thesis or dissertation :)  Given that
> this is a free
> resource and that the network usage is negligible even with a dozen
> servers, the only
> real downside is being tagged as a resource hog.
>
> Bob
>
> > On Nov 4, 2019, at 7:05 AM, Hal Murray  wrote:
> >
> >
> > att...@kinali.ch said:
> >> This is a pretty baseless fear. The servers in the ntp pool are
> constantly
> >> monitored and those that are off by more than 100ms are quickly removed
> >> (within 2-3 hours, IIRC). Of course, if you are already using one of
> those,
> >> then the removal will not help you. But you are most likely using 3-5
> servers
> >> anyways, which means ntp will remove the "rouge" server on its own.
> >
> > It's more complicated than that.
> >
> > It depends on what code you are using and how you configured things.
> >
> > If you are using  ntpd and you said in your ntp.conf
> >  server 
> > Then it grabs one and sticks with it until you restart ntpd.
> >
> > In the old days, it was common to use
> >  server 0.pool
> >  server 1.pool
> >  server 2.pool
> >  server 3.pool
> > That used the pool before the pool code in ntpd was working.  I'm pretty
> sure
> > some distros set things up that way and some systems are probably still
> using
> > an old config file.
> >
> > The pool code is supposed to drop bad servers and get replacements.  I'm
> not
> > sure of the details on what "bad" covers.  It could be not responding at
> all
> > or it could be time not good-enough.  I'll dig into the code if it
> matters.
> >
> >
> > If you aren't running ntpd (classic or ntpsec) then I don't know what
> happens.
> >
> >
> > --
> > These are my opinions.  I hate spam.
> >
> >
> >
> >
> > ___
> > 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.

Re: [time-nuts] can of worms: time-of-day in a community radio station

[Steven Sommars]

You can't test a server for smearieness.  It wouldn't surprise me if some
of them turn out to be getting time from google servers or something
similar.

The last time I checked over 50 of the NTP pool stratum 2 servers used
Google, based on the Reference ID.  The NTP pool folks are aware of the
issue.

Several other NTP pool servers make use of AWS NTP.   This too is smeared,
see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html.



On Sun, Oct 20, 2019 at 9:00 PM Hal Murray  wrote:

>
> themadbea...@gmail.com said:
> > In reference to using the NTP Pool, someone mentioned they don't trust
> them
> > and the possibility of a "rogue" server. The NTP Pool has a monitor that
> is
> > constantly querying every server in the pool, if the time drifts too far
> it
> > is removed from the DNS rotation.
>
> There is a catch.  The pool code in ntpd never goes back to check to see
> if a
> server has been kicked out of the pool or resigned.  As long as the server
> keeps responding, it will be used but subject to the usual filtering
> rules.
> If it stops responding, ntpd will drop it and do another DNS query to get
> a
> replacement.  (There may be some hysteresis on how-many.)
>
> Note that there are 2 ways to use the pool.  You can say
>   server pool.ntp.org (or us.pool.ntp.org or 0.us.pool.ntp.org)
> That will latch on to one of the servers in the pool.
> It won't do the replacement dance I described above.
> Next time you boot or otherwise restart ntpd you will probably get a
> different
> server.
>
> In the old says, before ntpd supported the pool command in ntp.conf, it
> was
> common to see things like:
>   server 0.pool.ntp.org
>   server 1.pool.ntp.org
>   server 2.pool.ntp.org
>   server 3.pool.ntp.org
> (Slot 2 also returns IPv6 addresses.)
>
> You can also say:
>   pool us.pool.ntp.org
> That will take several servers from the DNS response and try again later
> if it
> needs more.
>
>
> > Also, none of the servers in the pool
> > should be using leap-smearing (a requirement you mentioned).
>
> You can't test a server for smearieness.  It wouldn't surprise me if some
> of
> them turn out to be getting time from google servers or something similar.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> ___
> 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.

Re: [time-nuts] can of worms: time-of-day in a community radio station

[Steven Sommars]

I scanned the NTP pool last leap second and relayed the list of offenders
to Ask.
NTP pool servers may use a mixture of smeared and non-smeared upstream
servers.  Yuck.

While the NTP pool has limitations it is widely used (and abused).  NTP
servers outside of the NTP pool may also be imperfect.


On Mon, Oct 21, 2019 at 11:01 AM J.R.  wrote:

> > You can't test a server for smearieness.  It wouldn't surprise me if
> some of
> > them turn out to be getting time from google servers or something
> similar.
>
> True, but you *can* see which upstream time source has been selected
> for a NTP server. Ask went through the pool servers last leap-second
> and contacted all the owners that were returning a Google IP as their
> primary time source to get them to change their configuration.
> Likewise, said servers that weren't reconfigured in time were pulled
> out of rotation during the event to prevent any issues. So there
> *were* some preventative measures taken.
>
> AFAIK, the only *big* public time services that do leap-smearing are
> Google & Amazon.
>
> Yes, I know a person *can* configure their own NTP server to do
> smearing too But if that one second is mission critical, then you
> are probably taking a lot more care choosing upstream time sources.
>
> ___
> 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.

Re: [time-nuts] John Fluke test equipment tutorial

[Steven Sommars]

https://tycho.usno.navy.mil/ptti.html archived 2012 and earlier PTTI
papers.  That site seems to be unavailable now, but the Internet Archive
still holds copies.  Circa 2013 PTTI and ION merged, new papers are
paywalled.



On Wed, Nov 27, 2019 at 11:20 AM Bob kb8tq  wrote:

> Hi
>
> Both the Frequency Control Symposium and the PTTI proceedings are archived
> by their respective parent organizations. DVD’s are available with the old
> versions
> on them. The papers done by NIST are on the NIST website. Much of the rest
> is
> protected / restricted.
>
> Bob
>
> > On Nov 27, 2019, at 7:58 AM, ew via time-nuts 
> wrote:
> >
> > Looking through piles of manuals I found proceedings of frequency and
> time and frequency meetings I attended as part of my job, between 75 and
> 79. Each at least an inch thick. Is some one archiving the proceedings.
> Like them to find a home. Contact me off list
> >
> > Bert Kehren
> >
> >
> > In a message dated 11/26/2019 8:39:37 PM Eastern Standard Time,
> paulsw...@gmail.com writes:
> >
> > Azelio really just looking at what methods were used back then. That
> helps
> > me understand what I am looking at at a hamfest. Can I use it and how. I
> > have seen some very nice Gen Rad equipment at bargain prices.
> Unfortunately
> > I already had the same Z bridge. But it was a really tempting price and
> > unit was in mint condition.
> > But there are many bridges and dividers that show up at $20 or less.
> > So they just add to the test bench.
> > Regards
> > Paul.
> >
> > On Tue, Nov 26, 2019 at 3:00 PM Azelio Boriani  >
> > wrote:
> >
> >> Indeed, and the 1980 edition might be the better choice if you're
> >> looking for circuits you can build.
> >>
> >> On Tue, Nov 26, 2019 at 6:00 PM paul swed  wrote:
> >>>
> >>> Azelio
> >>> A good point you make. From a slightly different perspective. The
> >>> technologies that are in the document show up at Hamfests around the
> east
> >>> coast of the US and with this book they make sense as to what they are
> >> and
> >>> how they are used. It also turns out that many of the devices have very
> >>> accurate resistors in them and somehow they have held tolerance over 60
> >>> years according to 5.5 digit HP meter.
> >>> Some of the devices are obvious in function others are not so clear.
> But
> >>> still a good read.
> >>> Regards
> >>> Paul
> >>>
> >>> On Tue, Nov 26, 2019 at 3:30 AM Azelio Boriani <
> azelio.bori...@gmail.com
> >>>
> >>> wrote:
> >>>
>  It is available here:
>  
>  This is the first edition (1980) and is almost completely out of date
>  regarding current metrology techniques. The time and frequency chapter
>  (17) is only 5 pages long and dedicated to the time transfer using the
>  Fluke VLF receiver/comparator. The second edition (1994) is a bit more
>  theoretical.
> 
>  On Tue, Nov 26, 2019 at 2:43 AM paul swed 
> wrote:
> >
> > Perry kindly shared it with me a week or so ago. Its a really good
> >> read.
> > Enjoy and thanks Perry.
> > Regards
> > Paul
> >
> > On Mon, Nov 25, 2019 at 6:00 PM Perry Sandeen via time-nuts <
> > time-nuts@lists.febo.com> wrote:
> >
> >> Yo Bubba Dudes!,
> >> I've re-published the John Fluketutorial *Calibration Philosophy
> >> and
> >> Practice*  Circa 1980.
> >>
> >>   It describes how all the basicelectrical standards are derived and
> >> measured.  It is a 14 MbytePDF.  If anyone is interested in a copy
>  please
> >> send me an *original* emailoff list for a copy
> >>
> >> Regards,
> >> Perrier
> >> ___
> >> 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.
> >>
> > 

Re: [time-nuts] NTP pool reliability

[Steven Sommars]

NTP pool performance depends on several factors.  The primary pool monitor,
located in Newark, New Jersey, periodically polls each NTP server.   Based
on reachability and calculated offset each server is assigned a score.
See  https://www.ntppool.org/scores/192.36.143.151 for example.  If a
server's score is too low, it is excluded from  DNS responses to
N.pool.centos.pool.ntp.org  etc.  [I
can't provided details on the pool's DNS implementation .]

Many NTP clients do a DNS lookup only at startup and hence will not learn
that a particular server is no longer being advertised by the NTP pool.
The "pool" directive supported by some recent NTP clients may help.  See
https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_pool_usage#pool_directive_vs_server_lines


ISPs/IXPs have implementing "NTP filtering" in some (many?) network paths.
Filtering consists of rate limits and/or NTP size limits.  It seems that
the filtering was done in response to DDoS attacks in the mid 2010's that
used the mode 7 (private) NTP directive: monlist.  Monlist was used in UDP
port 123 for amplification attacks.

NTP filtering continues to cause problems for the NTP pool administrators
and the people who volunteer their servers.   The rate limits cause some
pool monitor periodic polls to fail which in turn lowers the scores of
those NTP servers.  The servers may be temporarily dropped from the active
pool list.   In troubleshooting issues with some European NTP servers I've
found that Telia is among those doing the filtering.The forum
https://community.ntppool.org/ can be used for pool questions and has some
details of the filtering (timeout) problems.

NTP filtering can affect clients, of course.  60-80% of the NTP polls from
one of my Chicago-based clients towards the NIST Gaithersburg, Md NTP
servers fail.
CenturyLink is doing in the filtering in this case.

The ISP/IXP NTP filtering was implemented as a DDoS defense and viewed by
at least some of that community as still being necessary.



On Sat, Feb 15, 2020 at 12:01 PM paul swed  wrote:

> Yes. Not scientific but I noticed one of my servers drifting in time.
> Changed to another NTP source seems fine.
> Regards
> Paul
> WB8TSL
>
> On Sat, Feb 15, 2020 at 12:09 PM Steve Allen  wrote:
>
> > During the past week my monitors on several of our telescope control
> > machines started alerting me that their NTP quality was degrading.
> > The unhappy ones were using out of the box configurations of
> > N.pool.centos.pool.ntp.org
> > We surmised that the NTP packets were not reliably traversing the WAN,
> > and we have reconfigured the critical machines to use local servers.
> >
> > Has anyone else seen a degradation of reachability and delay to NTP pool?
> >
> > --
> > Steve Allen  WGS-84
> (GPS)
> > UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat
> > +36.99855
> > 1156 High Street   Voice: +1 831 459 3046 Lng
> > -122.06015
> > Santa Cruz, CA 95064   https://www.ucolick.org/~sla/  Hgt +250 m
> >
> > ___
> > 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.

Re: [time-nuts] Any (relatively) cheap TSIP GPS receivers without WNRO out there?

[Steven Sommars]

ntpsec, a fork of the classic NTP distribution, supports an option to
compensate for the 1024 week rollover:
https://docs.ntpsec.org/latest/ntp_conf.html

 time1 sec
Specifies a constant to be added to the time offset produced by the driver,
a fixed-point decimal number in seconds. Each "g" on the end of the
constant adds the number of seconds in a 10-bit GPS era; each "G" adds the
number of seconds in a 13-bit GPS era.


On Sun, Jan 12, 2020 at 3:10 AM Björn  wrote:

> Hi Skip,
>
> Are your NTP-server using the Palisade ref clock driver?
>
> http://doc.ntp.org/current-stable/drivers/driver29.html
>
> If it’s using the event-poll mode you might need a receiver supporting
> that. I have not seen that outside the Palisade/Accutime family.
>
> Can you fudge the time1 all the way up to 1024wk (translated into seconds)
> to compensate for the wnro with your current receiver?
>
> # Set packet delay
> fudge 127.127.29.0 time1 0.020
>
> -
>
>  Björn
>
> Sent from my iPhone
>
> > On 12 Jan 2020, at 04:55, Skip Withrow  wrote:
> >
> > I have an NTP server  that uses a Trimble GPS receiver (Accutime 2000,
> > p/n - 39091-00, ROM 3.06) that has fallen prey to WNRO.  Just
> > wondering if there are any Trimble (or other brand) receivers that
> > have TSIP serial comms that are available for a reasonable price?  Any
> > help appreciated.
> >
> > Skip Withrow
> >
> > ___
> > 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.

Re: [time-nuts] an interesting timing problem

[Steven Sommars]

This discussion focuses on interactive audio/data streams.  One-way streams
are treated differently, since delay is less important.

Media transport typically uses IPv4/6 networks and can often be captured at
one of the endpoints or somewhere in the network path. E.g., I captured a
Skype call today on my PC using Wireshark.  Whether this IP capture can be
converted back to audio/video depends on whether the packets have been
encrypted and requires detailed knowledge of the encoding used.  It is
common to digitize audio using a standard vocoder (for wireless, these
include EVRC, AMR, AMR-WB) and then transport it using RTP headers and
UDP/IP.   I'll describe 4G voice (voice over LTE or VoLTE), as I'm most
familiar with that technology.

There are several delay contributors in the end-to-end path:

   - (source) Collecting digitized voice for an interval.  In 2G/3G/4G
   wireless 20 msec is commonly used.
   - (source) Compressing the 20 msec of data .   This data is stuffed into
   an RTP/UDP/IP packet
   - IP transport of the compressed voice to the receiver.   This is
   unreliable: RTP packets can be dropped, duplicated, missequenced or
   corrupted.
   - (Receiver) Dejitter buffer (or jitter compensation buffer ...)
   - (Receiver) Error concealment

The dejitter buffer adds variable delay dependent on the network and
network conditions.   I've seen it add 10's to 100's msec delay in VoLTE.

One-way latency is sometimes called "mouth to ear delay" and can be
measured in the analog domain with commercial gear; we used equipment from
GL Communications.
Time-stamped IP packet captures can also be helpful, but doesn't show what
happens within the receiver.








On Wed, May 6, 2020 at 2:44 PM jimlux  wrote:

> On 5/6/20 7:33 AM, Chris Howard wrote:
> >
> > At my current job we were looking into delay timings of video systems.
> >
> > We were doing end-to-end measurement by putting a time display in front
> > of a monitor
> > and have the camera show both the time display and the monitor.
> > It looks a bit like the old infinite mirror.
> > If you arrange things right it shows two images of the time display
> > one that lags the other.  And the difference is the round-trip delay.
> >
> > When I'm on Skype and my co-worker shares his screen, I can see my own
> > camera image come back to me in a similar way.
> >
> > So if I were to point my camera at a rolling time display, he shares
> > that image back to me, I could take video (with a second camera)
> > of both the live time display and the delayed.
> >
> >
>
> OK, but this is sort of a manual measurement.
> Ditto for looping back a tone and using an oscilloscope.
>
> What I was wondering about whether there's a way to do it in an
> automated way - fire up N webex/zoom/skype "conferences" solely for the
> purpose of testing.
> For instance, this morning was a "very bad day" for Cisco's webex, and
> it would be interesting to collect performance statistics over time.
>
> And to explore the nature of the anomalies - are they "packet drops",
> "resends", random delays, etc.
>
> Much like the folks did in the early days of NTP development.
>
>
>
> Some others had suggested ways of doing it "during a call" which is
> interesting.  I wonder if there is a way to intercept the video and
> audio traffic within the OS and "tee" it off to a analyzer.
>
> Last time I looked at doing that kind of thing, I was foiled at every
> turn with Windows, because of their sensitivity to digital rights
> management - you don't want someone "tee"-ing copyrighted material to
> storage and redistributing.  I would expect that Mac OS X is no
> different.  It may well be that the conferencing applications don't
> bother to use the "protected content" capability. I know that folks at
> work have found ways to chromakey their webcam feed before feeding it
> into the Webex video input.
>
>
> ___
> 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] CDMA NTP servers beginning to fail

[Steven Sommars]

In the past few months I've noticed problems on multiple US-based public
NTP stratum 1 servers that use CDMA as their stratum 0 clock..  EndRun
Technologies Tempus LX (
https://endruntechnologies.com/pdf/USM3014--000.pdf) is an example.

This is not a surprise. In the US Verizon has announced plans to shut down
its legacy CDMA service though the end-date keeps changing (
https://usatcorp.com/verizon-extends-cdma-network-date/).  As the number of
CDMA channels and base stations drops the NTP servers have difficulty
finding an acceptable signal.

Failure modes include:  rapidly increasing root dispersion, reported time
drifting over the course of many weeks, 1024-week rollover(!), and complete
failure.

I don't know how users will adapt.  Other radio-based technologies have
poorer in-building coverage.

Steve Sommars
___
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.

Re: [time-nuts] Raspberry Pi NTP server

[Steven Sommars]

Driving the NTP software from a GPS w/PPS requires 1) bringing the NMEA
(typically) bytes to the computer.
Timing is not critical, USB polling at 1 msec is fine.   2) bringing the
PPS signal into the computer *is *timing critical.   There's only one bit
of information.

If the PPS is brought to a RPi GPIO pin, then PPS timing involves interrupt
latency/jitter.   This is in the microsecond range on an RPi, I'm told.

If the PPS is connected to RS232 DCD pin (this is common) and connected to
a computer with a native RS232 connection, we're again dealing with
interrupt latency/jitter.
See David Taylor's  GPS wiring diagram
https://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm

If the PPS is  connected to RS232 DCD pin, and then that RS232 signal is
fed to the computer (e.g., RPi) via RS232-USB conversion, the PPS accuracy
is dominated by the USB polling time.

Note:  The typical GPS PPS signal level isn't a direct match for RS232.  In
practice it works well.



On Thu, Jul 9, 2020 at 1:33 PM jimlux  wrote:

> On 7/9/20 2:14 AM, Petr Titěra wrote:
> > Just one note. Most USB to serial chip claim USB2.0 support but they
> > only provide Full-Speed data transfers. That is data communication
> > protocol based on USB1.1 parameters with 1ms polling interval. You have
> > to specifically look for High-Speed (i.e 480mbps) transfers when going
> > trough chip specification. Not all manufacturers have such chips and no
> > all chips from manufacturers who provide them have such capability.
> >
> > To this day I was able to find only one such chip family and that is
> > FTDI FT232H (that H suffix specifies High-Transfer rate).
> >
> > Petr Titera
>
>
> I suspect the 1ms is not limited by the chip (after all, they all have
> to support 8kHz schedules for isochronous audio, even if the serial port
> doesn't use it).
>
> I suspect it's more an artifact of how Linux (or whatever) OS deals with
> the interrupt handling.  Linux isn't designed as a "real time fast
> response" operating system. It depends on devices doing big transfers,
> so a 1 ms response time is fine.
>
> That is, you set up a DMA transfer to a disk drive at 100 Mbps, but
> since you're transferring 100 kByte buffers, you only need to service
> the event 125 times/second.
>
> You'll easily see this on high speed serial links through USB if you do
> "character at a time" operations. You cannot get 50kbps with character
> at a time with buffer flushes between characters.
>
> Try it with a USB serial dongle and a loopback from TxD to RxD.
>
>
> Most serial software that runs at high speed (>9600 bps) assumes a
> slightly smarter device (maybe a 16550 style) with a FIFO, so it
> "bursts" bytes to/from the device. Rather than hang a "read one
> character" io call, they'll do a "read up to N characters, with a
> timeout of 10 milliseconds" and put that in the loop instead.
> Similarly, they'll accumulate characters to be sent, and do the io_write
> call with all the characters in the buffer.
>
> I've done a fair amount of high speed USB serial stuff between arduinos
> and PCs, and you always wind up with some scheme for buffering on both
> sides.
>
>
> Since you're not going to be transferring (batches of) bytes any more
> frequently than 1 millisecond, there's not much point in sending the
> "modem control" signals (RTS/CTS) through faster.   Any high speed
> protocol handler has to account for the fact that if RTS/CTS handshaking
> is implemented, you can't overrun the transmit FIFO - That is, if the
> far end drops CTS, the near end doesn't send, and bytes pile up in the
> FIFO. So you just need to tell the device driver to stop sending soon
> enough that the FIFO doesn't overflow.  If the FIFO is, e.g., 16 deep,
> and you're sending at 56 kbps (7 kBytes/sec), the FIFO will overflow in
> about 2 milliseconds.  So a 1 millisecond response time to the CTS
> changing state is fine.
>
> For the other modem control signals (RI, CD, DSR, DTR) they're even
> slower. DSR and DTR are basically "my power is on" and don't change
> state. RI is "seconds" - the signal the modem is detecting is a 20Hz
> audio tone. CD is likewise "many milliseconds" depending on the
> modulation being used. A Bell 103 or 202 is a hundreds of bits/second
> device, so carrier acquisition/detect is typically 10s of bit times. For
> fancier modems with multitone signalling and coding, it could be many
> seconds for the speed negotiation to complete.
>
> TL;DR - there's no reason for a USB-Serial adapter manufacturer to have
> a faster than 1ms response time, nor for an operating system to be
> faster than 1ms.
>
>
>
>
> >
> > On 08.07.20

Re: [time-nuts] Raspberry Pi NTP server

[Steven Sommars]

Petr,

Is the variance plot based on PPS timestamps, or on NTP's smoothing of the
timestamps?

Have you measured the offset?


On Mon, Jul 13, 2020 at 10:54 AM Petr Titěra  wrote:

> On 12.07.2020 3:57, jimlux wrote:
> > On 7/11/20 1:30 PM, Steven Sommars wrote:
> >> Using GPIO with an RPi is a good direction, of course.   That wasn't my
> >> question.   Some data may help explain.
> >> Configuration =
> >>  RPi4 (raspbian buster)
> >>  Uputronics RPi GPS board (includes PPS) connected to GPIO pins.
> >> This
> >> is the time of day source for the RPi4.  (via GPSD+chrony).
> >>  Navisys USB GR701 (includes PPS and   Integrated serial->USB
> >> conversion). Contains integrated Prolific Technology, Inc. PL2303
> >>
> >> The observed PPS variation on the Uputronics PPS is a few microseconds.
> >> (ppstest was used for measurements).  Using a PPS to drive NTP's
> computer
> >> clock disciplining, which is in turn used to measure the same PPS
> >> makes for
> >> a dubious circular measurement.It is comforting though to see that
> >> the
> >> variance is in the ~1-3 microsecond range.   One must also add Trent's
> >> interrupt latency measurement (3 microseconds).   With the GPIO
> >> connection
> >> the RPi time base should be within say 10 microseconds of UTC.
> >>
> >> The USB-connected Navisys fares worse.
> >> [image: image.png]
> >> By the time the PPS reaches the OS there is about 1 msec of variance
> with
> >> an average offset of a bit over 0.6 msec.
> >> I suspect the 1 msec USB polling is the largest latency contributor,
> >> though
> >> there are other sources as mentioned by Tim.
> >> I'd like to reduce the USB polling contribution by polling at 125
> >> microseconds as the Linux PPS folks suggest
> >> (http://linuxpps.org/doku.php/technical_information)Would an
> >> FTDI-based
> >> USB convertor do the trick?
> >>
> >> Why bother with GPS/USB?  Sometimes I use laptops.  Few laptops today
> >> directly support PPS/serial.
> >> I just checked with Dell and found zero laptops with native RS232.
> >>
> >>
> >
> > I would not expect another kind of USB to serial converter to do better.
> > The problem is higher up in the way that Linux handles USB devices. The
> > USB hardware can certainly handle higher rates (and does), but the
> > "software interrupts" as the event travels up the stack limits the
> > timing resolution.
> >
>
> I beg to differ. With correct USB convertor I achieve sub millisecond
> variance (see attached screenshot fro FTDI232RL chip). I get similar
> results on other computers too.
>
> All Prolific  chips I saw claimed to be USB 2.0 Full-speed. That means
> they are polled only once in 1ms and there is no way how to change it
> (poll rate is selected at hardware level).
>
> Petr Titera
>
> > You might want to look into one of the "real time" linux kernels or
> > other similar implementations - they might have "turned some of the
> > knobs" to improve the handling of device data.
> >
> > USB device handling in Linux (and Windows, and Mac OSX) is quite
> > complex, if only because USB itself is quite complex in that it has to
> > support multiple "kinds" of devices with wildly varying properties (HID,
> > Mass Storage, Isochronous data, etc.) - Not to mention all the
> > complexities associated with hot plugging and unplugging and
> > "enumeration" and "power control".
> >
> >
> > You might also want to delve into the handling of USB request Blocks
> > (URBs) which is how Linux handles USB related events.
> >
> >
> https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch13.html
> >
> >
> > https://www.kernel.org/doc/html/v4.12/driver-api/usb/index.html
> >
> > The above document describes a variety of ways to get at USB devices in
> > non-standard ways, through the USB API.
> >
> >
> > Another interesting alternative might be to modify the low level
> > interrupt handler for your Prolific chip (or whatever you're using) -
> > you could probably snapshot the system timer in the IRQ. But then you're
> > faced with the challenge of propagating that time to where you need it,
> > and hopefully in a way that doesn't break Linux.
> >
> >
> > In any case, your problem is not that it's USB. Your problem is that
> > Linux has some compromises in how it handl

Re: [time-nuts] Raspberry Pi NTP server

[Steven Sommars]

My RPi4 (Raspbian Buster) has a GPS+PPS/USB.  Serial->USB uses Prolific
PL2303, which supports USB 2.0
The PPS jitter is 1 msec (e.g., using ppstest).  lsusb -v shows:

Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
Port
bInterval   1

which means 1 msec polling of the PPS signal.   I've been unable to poll
more frequently, that seems to require driver changes.
Petr, what polling rate do you see?Has anyone been able to poll USB @
125  µsec on a stock RPi?

With the 1 ms polling the PPS reaches the OS between 0 and 1 ms late, in an
unpredictable pattern.Although the PPS jitter is 1 msec, ntpd/chrony on
my RPi4 typically reports low dispersion:  50-150  µsec.  The zero-mean
assumption Achim mentioned is unlikely to be valid. Running chrony +
GPS+PPS/USB I see a ~640µsec offset compared to a GPS+PPS directly
connected to the GPIO pins.  That offset will fluctuate, of course.

Steve Sommars





On Wed, Jul 8, 2020 at 12:57 PM ASSI  wrote:

> On Dienstag, 7. Juli 2020 18:27:01 CEST Petr Titěra wrote:
> > Timing on USB need not to be so horrible. Below is stats from my server
> > with GPS connected using FT232H chip (supporting high speed transfers on
> > USB). Yes, the jitter is far greater than on other computer where PPS is
> > connected directly but it is a lot less than that 500microseconds you
> > get with common USB convertors.
> >
> >   remote  refid st t when poll reach delay offset jitter
> > ===
> > o127.127.22.0   .PPS.   0 u7   16  377  0.000 -0.019  0.033
> > *192.168.3.240  .GPSD.  1 u   24   64  377  0.377  0.187  0.026
> > +192.168.3.246  .PPS.   1 u   28   64  377  0.643  0.181  0.028
>
> The reason you're seeing this with the newer FTDI chips that support
> USB2.0
> highspeed rates is that the frame rate got increased 8x for highspeed USB,
> so
> the expected frame jitter is now 125µs when and if the interface as well
> as
> the full protocol stack support and enable it.  But you seem to have
> missed
> the point that Hal was trying to make: The jitter you are going to see has
> deterministic components and some of these can create bias when you try to
> filter with the usual assumption of a stationary zero-mean random
> sampling.
> In other words, you don't necessarily converge to the true time and where
> your
> filter tries to converge varies over time.
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> DIY Stuff:
> http://Synth.Stromeko.net/DIY.html
>
>
>
>
> ___
> 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.

Re: [time-nuts] Raspberry Pi NTP server

[Steven Sommars]

 I don't want to hijack Andrew's thread.  Just wanted to add to Achim's
comments about jitter and offset.

USB2 devices should accept polls every 125 microseconds.  [My USB knowledge
is limited.]

I have two devices.  One is the Navisys GR701 which I suspect you're
familiar with; it is an integrated GPS + Serial->USB.  The other is a
Garmin LVC18x connected to a Sabrent USB 2 to serial cable.
Both devices report having a PL2303.  Both poll at 1 msec.  The GR701 has a
thin cable.  The Sabrent USB->Serial has a thick cable.







On Wed, Jul 8, 2020 at 6:53 PM Hal Murray  wrote:

>
> stevesommars...@gmail.com said:
> > My RPi4 (Raspbian Buster) has a GPS+PPS/USB.  Serial->USB uses Prolific
> > PL2303, which supports USB 2.0
>
> > which means 1 msec polling of the PPS signal.   I've been unable to poll
> more
> > frequently
>
> As far as I know, the PL2303, 067b:2303, is an old/slow chip.  (I forget
> the
> right magic USB terms)  Why do you expect it to go faster than 1 ms?
>
> It and the FTDI chip(s) are popular and widely known to be well supported
> on
> Linux.  I'll be very surprised if it goes faster.
>
> What sort of device are you using?  One way to tell if it is likely to go
> faster than 1 ms is the thickness of the wire.  Faster speeds need more
> shielding for EMI reduction (or something like that) which turns into
> fatter
> cables.  It's pretty easy to tell if you have samples of both in front of
> you.
>  I think you can only use the thinner cable if t runs at 1 ms and you hard
> wire the chip to the end of the cable as is typical of a GPS mouse.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> ___
> 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.

Re: [time-nuts] Raspberry Pi NTP server

[Steven Sommars]

Using GPIO with an RPi is a good direction, of course.   That wasn't my
question.   Some data may help explain.
Configuration =
RPi4 (raspbian buster)
Uputronics RPi GPS board (includes PPS) connected to GPIO pins.   This
is the time of day source for the RPi4.  (via GPSD+chrony).
Navisys USB GR701 (includes PPS and   Integrated serial->USB
conversion). Contains integrated Prolific Technology, Inc. PL2303

The observed PPS variation on the Uputronics PPS is a few microseconds.
(ppstest was used for measurements).  Using a PPS to drive NTP's computer
clock disciplining, which is in turn used to measure the same PPS makes for
a dubious circular measurement.It is comforting though to see that the
variance is in the ~1-3 microsecond range.   One must also add Trent's
interrupt latency measurement (3 microseconds).   With the GPIO connection
the RPi time base should be within say 10 microseconds of UTC.

The USB-connected Navisys fares worse.
[image: image.png]
By the time the PPS reaches the OS there is about 1 msec of variance with
an average offset of a bit over 0.6 msec.
I suspect the 1 msec USB polling is the largest latency contributor, though
there are other sources as mentioned by Tim.
I'd like to reduce the USB polling contribution by polling at 125
microseconds as the Linux PPS folks suggest
(http://linuxpps.org/doku.php/technical_information)Would an FTDI-based
USB convertor do the trick?

Why bother with GPS/USB?  Sometimes I use laptops.  Few laptops today
directly support PPS/serial.
I just checked with Dell and found zero laptops with native RS232.


On Fri, Jul 10, 2020 at 2:17 PM Tim S  wrote:

> I believe the issue is arising from the understanding of "what" is being
> interrupted.
>
> When a UART or GPIO is triggering an interrupt - for the UART it's a FIFO
> notice that data is available to be pulled out, for the GPIO it's
> notification of a state change (and optionally, a specific state change:
> high-low/low-high).
>
> When a USB PHY trips an interrupt it's to indicate that carrier data is
> ready, or for a USB MAC that burst blocks over the link are being decoded.
> There is an intermediate step between the USB carrier data being
> received/decoded, and being interpreted by the driver as a specific type of
> data - and the time that it is made available to the host OS.  Because that
> is handled in the driver, it is subject to all of the other host OS
> interrupts - so timing is not deterministic for the USB driver.
>
> The differences here are key.
>
> A 1PPS wired to a GPIO interrupt for the specific pulse edge (rising) will
> be associated with a very precise correlation to an interrupt vs system
> tick value.
>
> A UART time edge (watching the seconds value increment) will be subject to
> the rate at which bytes are transferred out of the UART FIFO, then math is
> done to detect the second transition edge.
>
> A USB-to-Serial converter will first encode the bytes and status pin states
> into a payload compliant with USB trafic standards, transmit that data to a
> USB Host (PHY/MAC) device, which  triggers and interrupt for the driver
> to decode the data back into meaningful data for the host, then forwards
> virtual interrupt triggers to the tasks which are watching the states and
> bytes.  Everything on the host-side is subject to system overhead, USB
> driver optimization, etc. and is thus variable.  The host-side backend of
> the USB transfer is where your variability is coming from IMHO.
>
> This is why the recommendation is to use direct (not bridged/adapted)
> UART+GPIO from most RPi NTP server projects.  The timing is most critical
> to the 1PPS edge, so the most direct correlation possible to a tick value
> in the OS is the goal.  There is nothing saying that the NMEA messages must
> have such low latency however - in general they merely must arrive in time
> before the next 1PPS, so USB serial is fine for that traffic.
>
> -Tim
>
> On Thu, Jul 9, 2020 at 9:00 AM  wrote:
>
> > Message: 4
> > Date: Wed, 8 Jul 2020 15:02:49 -0500
> > From: Steven Sommars 
> > To: Discussion of precise time and frequency measurement
> > 
> > Subject: Re: [time-nuts] Raspberry Pi NTP server
> > Message-ID:
> >  > atz...@mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > My RPi4 (Raspbian Buster) has a GPS+PPS/USB.  Serial->USB uses Prolific
> > PL2303, which supports USB 2.0
> > The PPS jitter is 1 msec (e.g., using ppstest).  lsusb -v shows:
> >
> > Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
> > Port
> > bInterval   1
> >
> > which means 1 msec polling of the PPS signal.   I've been unable to poll
> &g

[time-nuts] ISS NTP operation problems.

[Steven Sommars]

At the end of November a question
was
posed to the ntp.org list concerning NTP problems on the International
Space Station.
With William's permission I'm following up on the time-nuts list.

I analyzed NTP/IP packet captures provided by William and reported on
external visible behaviors.  The much simplified diagram is
2 x Ground NTP(strat 1)  ---   ISS NTP server(strat 2)
-(gigastor)--- ISS NTP clients(strat 3)
There is a ~600-700 msec RTT between the ground NTP servers and the ISS NTP
server.

As William describes, the clients are having trouble synchronizing with the
stratum 2 ISS NTP server.
This server is not working well.   Here is the UTC time offset seen from an
external packet capture device (Gigastor)
[The Gigastor is only approximately sync'd to UTC, hence the 4 second
offset]
[image: image.png]
The y-axis scale is seconds.
Note also that after each step the initial error is about -500 ppm.  When
the server is in alarm the error stays at -500ppm.
When not in alarm the server's clock frequency is changing in the wrong
direction with a resulting error of up to ~ -1500ppm.
Could this be an example of the Integral Windup problem mentioned recently
by PHK and Magnus?
Have others seen this behavior in NTP?

Getting additional diagnostic information from the ISS is quite difficult.
 Even simple changes (e.g., remove ntp.drift) require much planning.

Steve Sommars
___
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.

Re: [time-nuts] ISS NTP operation problems.

[Steven Sommars]

Responses to several comments.

Opportunities to collect critical NTP debugging data on the ISS will be
limited.
Specific suggestions sent to me off-list would be appreciated.

Earth station to ISS delays: I inferred the 600-700 msec RTT using the
reported root distance
[I've seen much higher delays on some terrestrial NTP paths.  ]
To really understand RTT / RTT stability NTP server diagnostic data is
needed.

GPS/GNSS, PPS distribution: seems like a good idea, but this is outside
the area I'm helping with

NTP (4.2.8) algorithmic changes are probably out of scope for the near
future.
If a real-world PLL problem can be documented, the ntp daemon maintainers
might be motivated to investigate.

So far I haven't been able to reproduce on my home Rpi some key features of
the offset graph I showed.

   - pll error begins at -500 ppm
   - pll error grows to -1000 or even -1500 ppm
   - After step pll error is again -500 ppm
   - Does not self correct within 24 hours

By placing large positive or negative values into the NTP drift file I can
produce offset charts with a series of steps, but eventually the steps stop
and the offset is small.

Thanks for all the replies.
___
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] Re: NTP servers

[Steven Sommars]

LeoNTP note:I've seen these units infrequently return NTP responses
that are off by N-seconds (N is a small integer.)
I could not determine the root cause.

One other oddity.  The returned NTP root dispersion is always 0, even when
the unit runs in holdover mode.
The support people say that this is intentional; the NTP "precision" field
is varied instead.
This is the wrong approach.

Despite this I use my LeoNTP constantly.  It is small, convenient, simple
and can handle almost 100Mbps of NTP requests.



On Mon, Nov 22, 2021 at 12:11 PM Lester Veenstra via time-nuts <
time-nuts@lists.febo.com> wrote:

> Yupp
>
> Lester B Veenstra  K1YCM  MØYCM  W8YCM   6Y6Y (Reformed USNSG CTM1)
> les...@veenstras.com
>
> 452 Stable Ln
> Keyser WV 26726 USA
>
> GPS: 39.336826 N  78.982287 W (Google)
> GPS: 39.33682 N  78.9823741 W (GPSDO)
>
>
> Telephones:
> Home:+1-304-289-6057
> US cell  +1-304-790-9192
> Jamaica cell:+1-876-456-8898
>
>
> -Original Message-
> From: Denny Page via time-nuts [mailto:time-nuts@lists.febo.com]
> Sent: Monday, November 22, 2021 12:16 PM
> To: Discussion of precise time and frequency measurement
> Cc: Denny Page
> Subject: [time-nuts] Re: NTP servers
>
> Well, someone snatched that up quick.
>
>
> > On Nov 21, 2021, at 19:11, Denny Page via time-nuts
>  wrote:
> >
> > Highly recommend the LeoNTP. If you are in the US, there is still one in
> stock here:
> >
> > https://v3.airspy.us/product/upu-leontp/
> >
> > Denny
> >
> >> On Nov 21, 2021, at 18:52, W7SLS  wrote:
> >>
> >> Another option is the Leo Bodnar NTP device, though it appears to be out
> of stock at the moment
> > ___
> > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe
> send
> an email to time-nuts-le...@lists.febo.com
> > To unsubscribe, go to and follow the instructions there.
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send
> an
> email to time-nuts-le...@lists.febo.com
> To unsubscribe, go to and follow the instructions there.
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send
> an email to time-nuts-le...@lists.febo.com
> To unsubscribe, go to and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

[time-nuts] Re: Leap indicator set to 1 !

[Steven Sommars]

A number of the NTP servers are LeoNTP.   The 1.24 firmware release (
https://leontp.com/firmware/) seems to fix the problem.
(My local LeoNTP now sets leap=0).

There may be a common bug affecting multiple ntp server models.   The
incorrect leap indicator began 256 weeks + 1 days since the previous leap
second.

On Sat, Nov 27, 2021 at 9:22 AM Steven Sommars 
wrote:

> FYI.
>
> At 2021-11-27 00:00:00 UTC many public NTP servers began setting the leap
> indicator to 1.
> This may be gpsd related
>
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

[time-nuts] Re: Leap indicator set to 1 !

[Steven Sommars]

>>The incorrect leap indicator began 256 weeks + 1 days since the previous
leap second.
The incorrect leap indicator began 256 weeks - 1 day since the previous
leap second.
Sorry for sign error

On Sat, Nov 27, 2021 at 11:38 AM Steven Sommars 
wrote:

> A number of the NTP servers are LeoNTP.   The 1.24 firmware release (
> https://leontp.com/firmware/) seems to fix the problem.
> (My local LeoNTP now sets leap=0).
>
> There may be a common bug affecting multiple ntp server models.   The
> incorrect leap indicator began 256 weeks + 1 days since the previous leap
> second.
>
> On Sat, Nov 27, 2021 at 9:22 AM Steven Sommars 
> wrote:
>
>> FYI.
>>
>> At 2021-11-27 00:00:00 UTC many public NTP servers began setting the leap
>> indicator to 1.
>> This may be gpsd related
>>
>
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

[time-nuts] Leap indicator set to 1 !

[Steven Sommars]

FYI.

At 2021-11-27 00:00:00 UTC many public NTP servers began setting the leap
indicator to 1.
This may be gpsd related
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

[time-nuts] NTP Leap indicator set to 1 ! problems continue

[Steven Sommars]

This is written at 2021-11-30 15:45

2021-11-27 00:00:00   NTP servers start advertising leap=1.
2021-11-28 00:00:00   Many of these servers execute leap procedure.  Leap=0
no longer advertised (mostly)
2021-11-30 00:00:00   *Another set of NTP servers start advertising leap=1.*
2021-12-01 00:00:00   (predicted).  Many of the second set of NTP servers
execute leap procedure.
2021-12-01 00:00:00   (?)  Unknown number of clients will execute leap
procedure.

By convention NTP servers wait until the last day of the month before
advertising leap=1.   Beginning 2021-11-30 00:00:00 I've seen 81 public NTP
servers with the leap flag set.
The flag flips between 0 and 1 on some servers.

In older NTP implementations a single bad leap=1 indicator could propagate
to other NTP servers.  That may be happening now.
(Newer ntpd versions implement a majority rule).

I'm working with the NTP Pool folks.  Perhaps some of the bad flags can be
cleared.
However, it is likely that some NTP clients will execute a leap second
procedure in about 8 hours.

NOTE:  In past days this discussion would happen on the NTP mailing lists (
lists.ntp.org), but that mailing list is long dead.

Steve Sommars
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

[time-nuts] Re: NIST NTP servers way off for anyone else?

[Steven Sommars]

On Tue, Dec 14, 2021 at 11:40 AM Michael Rothwell 
wrote:

> I see some high offsets on my local monitoring (synced to time.google.com
> ).
> Especially time-e-b on ipv6.
>

This observation is correct and is caused by queuing delay on the NIST
server.  NIST NTP mode 3 requests
are apparently time-stamped at application level, rather than using
SO_TIMESTAMP or related techniques.
As an exercise, compare the NTP (UDP port 123) and TIME (UDP port 37)
delays.

Steve Sommars
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

[time-nuts] Re: NIST NTP servers way off for anyone else?

[Steven Sommars]

The Gaithersburg servers are accurate.  This plot shows Gaithersburg
time-e-g.nist.gov for the current month.
[image: image.png]
My monitoring client is located near Chicago and is Stratum-1 GPS sync'd.
Typical round-trip time to Gaithersburg is ~27 msec.
On 2021-12-07 a few monitoring polls saw RTT of ~100 msec.  This changes
the computed offset from
~0 msec to to ~40 msec (  (100-27)/2. ). Such transient increases are
often called  "popcorn spikes"
Many NTP clients including ntpd and chrony contain logic that identifies
and suppresses these outliers
Further, Gaithersburg is subject to fiber-cut outages and other planned &
unplanned network outages.
If you look carefully at the diagram, you can see a brief outage beginning
at about 2021-12-08 03:00 UTC.

I have other monitoring clients and can produce similar diagrams from other
locations.  A monitoring client
in Japan saw this for the same Gaithersburg server:
[image: image.png]
The delay spikes occur at different times and have different signs.  [The
2021-12-08 outage is still present]
See   http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf for a
discussion of why there are multiple
offset bands.  In the same paper there are examples of sustained high
delay, something that
popcorn spike suppressors cannot eliminate.

Magnus summarized the situation.  Either asymmetric network delay or a
misbehaving NTP server can
cause the computed offset to be non-zero.The former is very common.
NTP servers, even stratum 1's
driven by GPS, are sometimes in error.


Steve Sommars




On Tue, Dec 14, 2021 at 4:21 AM Magnus Danielson via time-nuts <
time-nuts@lists.febo.com> wrote:

> Hi,
>
> On 2021-12-14 02:26, Adam Space wrote:
> > I'm not sure if anyone else uses the NIST's NTP servers, but I've noticed
> > that the offsets I'm getting from Gaithersburg servers seem to be
> > really far off, like 40-50 ms off. This is pretty odd since they usually
> > have a 2 - 3 ms accuracy at worst.
> >
> > It is interesting to think about what is going on here. NIST has a
> secondary
> > time scale
> > <
> https://www.nist.gov/pml/time-and-frequency-division/time-services/utcnist-time-scale/secondary-utcnist-time-scales-and
> >
> > at Gaithersburg, maintained by a couple of caesium clocks that are
> > typically kept within 20ns of UTC(NIST), i.e. their primary time scale in
> > Boulder. They also host their remote time transfer calibration service
> and
> > their Internet Time Service (i.e. NTP servers) out of Gaithersburg.
> >
> > It seems highly unlikely that their time scale there is that far off. One
> > thing that immediately comes to mind is asymmetric network delays causing
> > this. I do think this has to be the reason for the large discrepancy, but
> > even so, it is an impressive feat of asymmetric path delays. The maximum
> > error in offset from a client to server due to asymmetric network delays
> is
> > one half of the delay. (This corresponds to one path being instantaneous
> > and the other path taking the entire delay time). When I query their
> > servers, I am getting about a 45ms offset, and a delay of around 100ms.
> > This would mean the maximum error due to asymmetric path delays is around
> > 50ms--and less even if we're being realistic (one of the delays can't
> > literally be zero). Basically, for the offset error to be accounted for
> > primarily by asymmetric network delays, the delays would have to be
> *very*
> > asymmetric.
>
> For the asymmetry to be 45 ms, the difference between forward and
> backward path would need to be 90 ms, since the time error will be the
> difference in delay divided by 2. The round trip time is instead the sum
> of the two delays.
>
> Now, as you observe this between two clocks with a time, difference, the
> time-difference add onto the TE, but does not show up on the RTT.
>
> So, 90 ms difference would fit, but delays would be 95 ms and 5 ms +/- 5
> ms, since we can trust the RTT to be unbiased. Now we come to what is
> physical possible, and 5 ms is 1000 km fiber delay. You can calculate
> yourself from your location the minimum distance and thus delay. In
> practice fiber is pulled not as straight as one would wish. I use at
> least square root of 2 as multiplier, but many agree that this is still
> optimistic and it can be far worse.
>
> What can cause such delay in a network? In IP/MPLS, the routing
> typically does not care about forward and backward direction being the
> same. Rather, they trim it to shed the load, i.e. Traffic Engineering.
> That means that for two pair of nodes in that network, it can be sent
> over a shorter path in one direction and longer in the other. In
> addition, buffer fill levels can be high on a path, meaning that you end
> up in the end of a buffer for each router hop due to traffic load. Delay
> is a means to throttle TCP down in rate. Random Early Discard (RED) is
> meant to spread that evenly between streams to cause throttle earlier
> than dropping packets due to full 

[time-nuts] Steering UK time station MSF

[Steven Sommars]

NIST steers the WWV/WWVB/WWVH radio stations using GPS common view.

Recent youtube piece on MSF
https://www.youtube.com/watch?v=yqciKS_N0K8
I was surprised that NPL (Teddington) steers MSF (Anthorn) based on the
signals received at NPL.   While  this steering seems less accurate than
GPS common view it does not require satellites.
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

[time-nuts] Re: NTP server source needed

[Steven Sommars]

Though I don't have a Time Machines NTP server I've monitored them for
several years and have seen a number of "off by N-seconds" errors.
The manufacturer reproduced the problem and released new firmware for the
TM2000B.  I don't know the status of other models.
I would be hesitant to trust the server when the GPS signal is marginal.

I have a local LeoNTP server.  Though it uses a different chipset than the
Time Machines TM, it also exhibits off by N-seconds.
I've seen similar errors for several other public LeoNTP servers, including
some of the ntpX.leontp.com servers.
When I degrade the GPS signal the N-second errors become more frequent.  A
typical NTP server will indicate potential loss of accuracy by setting the
alarm bit or increasing root dispersion.  The LeoNTP does neither, instead
it decreases the NTP "precision" field.  [The value itself is bogus.]
The machine's physical design is nice, the performance is excellent.  I
wish the timestamps were more trustworthy.

Steve Sommars





On Thu, Apr 21, 2022 at 8:20 PM Paul Watts  wrote:

> Thanks for the reply, Forrest.
>
> I do have a TM1000(model number?) but I thought they were out of stock.
> Their website currently claims otherwise and I'll probably get another.
>
> I do have systems at each site running NTP against my local LeoNTP devices
> and the US NTP pool.
>
> I just like to have a local source as well as remote.
>
> Recently, I learned about the Centerlclick NTP250. Anyone have any
> experience?
>
> On Thu, Apr 21, 2022 at 12:09 Forrest Christian (List Account) <
> li...@packetflux.com> wrote:
>
> > Time machines makes a similar box.
> >
> > However, one would expect that with that many devices at a site one could
> > find a couple of devices which could run a ntp server along with their
> > normal workload.
> >
> > On Thu, Apr 21, 2022, 2:23 AM Paul Watts  wrote:
> >
> > > Long time lurker, first time poster.
> > >
> > > In the past, I've purchased the LeoNTP server to act as a local time
> > server
> > > on my work network. Unfortunately, those NTP servers aren't available
> to
> > > order.
> > >
> > > I'm in need of two - three more NTP servers for various locations.
> > >
> > > Do any of you have an alternate NTP server recommendation?
> > >
> > > 1. I'd like to keep the price less than $1,000. The Leo's were a great,
> > > self contained choice at less than $400.
> > > 2. Support for IPv4 is required and IPv6 is desired. The main
> > shortcoming I
> > > have with the Leo's is no support for IPv6.
> > > 3. I'll serve about 150 clients per site from a given NTP server. My
> NTP
> > > clients are a combination of Windows and Linux computers along with
> > various
> > > types of network gear (Cisco, Palo Alto, Aruba, Juniper). The Leo's
> don't
> > > even breathe hard at that level.
> > > 4. No PTP support is required. My timing needs are IT related - log
> > > consistency, security protocol requirements, etc.
> > > 4. I'm not interested in building and using something like a Raspberry
> > Pi.
> > > I'll be sending these to remote sites and don't want to worry about
> > issues
> > > like memory card failures and the hobbyist feel of many Pi cases and
> > > cooling options. That's fine for my home but not for work.
> > > 5. Availability is important.
> > >
> > > Any suggestions are welcome.
> > >
> > > Thanks,
> > >
> > > Paul Watts.
> > > ___
> > > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe
> > send
> > > an email to time-nuts-le...@lists.febo.com
> > > To unsubscribe, go to and follow the instructions there.
> > >
> > ___
> > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe
> send
> > an email to time-nuts-le...@lists.febo.com
> > To unsubscribe, go to and follow the instructions there.
> >
> --
> Paul Watts.
> rpwa...@gmail.com
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send
> an email to time-nuts-le...@lists.febo.com
> To unsubscribe, go to and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.