libsodium mess

[Gary E. Miller]

Yo Kurt!

On Thu, 19 Jan 2017 23:11:18 +0100
Kurt Roeckx <kurt at roeckx.be> wrote:

> > In my GR-601W experiments I can show it would be bad.  
> 
> I really have no idea what kind of experiment that was, but I
> doubt that it somehow has an ADC.

That is getting the most accurate time possible onto an NTP server
that only has a USB bus.

> > I'm worried about 1 micro Second or less.  And one should not
> > confuse accuracy with resolution.  A PPS signal only has a
> > resolution of one Second, but can eaaily have an accuracy of 10
> > nano seconds.  
> 
> Please don't confuse accuracy with precision. I'm not sure your 10
> nano seconds is the accuracy or precision, both are possible, but
> I think you're talking about precision. The accuracy is probably
> not that easy to measure.

You are right, I probably should have said the resolution of the PPS is
just one second That PPS just fires once a second.  There is no way to
tall anything about anything, except that one moment in time at the top
of the second.

I tend to use precision interchangeabley with resolution.

The number of significant digits past the second is zero.

If you doubt a PPS is accurate to 10 nano Seconds then head over to
time-nuts.  They'll give you an earfull.  I'm happy just to know that
the ACCURACY of when the PPS pulse happens is quoted as 10 nano Seconds
on the data sheets of many GPS.  Other GPS only claim 1 micro Second.

By accurate I mean that you can sompare it to an atomic clock that
is NIST traceable and get an offset less than that number.


> > A signal on a USB 2.0 bus can only have a resolution of about 1
> > micro Second, but that can be locked to a PPS to 100 micro Seconds
> > jitter.  
> 
> I'm not sure what you're trying to say.

Each USB 2.0 device is polled 1024 times a second.  So you would think
you could only sync time over a USB 2.0 bus to 1/1024th of a second.
About 1 micro Second.  But that is not true, you can sync time over USB
2.0 to 100 microseconds.

If you said the resolution is only 1 micro second, and you added
500 micro Seccond of jitter, you would make the sync 5 times worse,
not better.

> But if you're talking about jitter, you're really talking about
> the precision.

NTP uses yet another definition for precision, so it is confusing.  NTP
calculates precision from jitter.  NTP precision (not accuracy) is
assumed to be slightly worse than the jitter.  The NTP precision can be
no better than the jitter.  Conversly the NTP jitter is better than
the precision.

In my experiments the NTP precision and the NTP jitter are about 100
micro Seconds, but the accuracy (NTP offset) does wander, slowly, the
expected 1 micro Second.  So the top of the scond on the system clock
may not be at the right place, but the length of a second is held to 10x
better.

Maybe the raw data and graphs will help:

    https://pi.rellim.com/day/

That is a GR-610W on a RasPi version 1, so not the best test bed, but what
I have running right now.

> > > But I'm currently not really sure that it either improves
> > > things, make things worse, or has no effect at all.  
> > 
> > Hal does not think it is in the measurement path at all.  If it is
> > then it will be eauy to do some testing.  
> 
> As far as I understood, the packets that go out have their
> timestamp adjusted to add a random value.

Well then, there is a lack of consensus on where the randomness is used.
Further investigation required.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170119/3d759170/attachment.bin>