libsodium mess

[Gary E. Miller]

Yo Kurt!

On Fri, 20 Jan 2017 01:51:23 +0100
Kurt Roeckx <kurt at roeckx.be> wrote:

> > 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.  
> 
> They're clearly different things.

Yes, but sadly NTP has not been consistent about what means what
up until now.  Feel free to float some solid definitions we can agree on
and convert the documentation to being consistent about.

> > 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.  
> 
> Please note that I say both precision and accuracy is possible.

Yes, and you can have one without the other.  It is possible to be
precisely wrong.

> But it's not because they have the time to such accuracy that they
> can output it with such accuracy, or that you can measure it with
> such an accuracy.

Yup, things can go wrong everywhere.

> I was under the impression that you said you could sync your clock
> to 10 ns using PPS, but I guess I misunderstood that.

Not with NTP!  Or at least not yet.  I can do a little better than
1 micro Second.  At least that is what ntpd tells me.


> 
> > > > 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.  
> 
> 1/1000 of a second would 1 millisecond, not microsecond.

Sorry typo.  But my conclusion, and my data, is unchanged.

> > 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.  
> 
> You seem to be confusing milli with micro again, I'm going to
> assume the first is milli.

Nope.  ntpd clearly tells me that my jitter is 100 micro Seconds.
I get the same results using chronyd.

> 
> I guess you're saying:
> - I can read about every 1 ms
> - But there is jitter on that 1 ms in the order of 0.002 to 0.1 ms

No, there is jitter on that of 1 mS to 0.1 mS.

> - You could add an other random 0.5 ms in software.

I'm trying to remove randomness, not add it!

> First, even though the PPS signal is only once per second, you're
> really measuring the pulse, and you could say you're measuring that
> with a resolution of 1 ms.

No, the resolutin of my measurement is the resolution of the system
clock.

> But your problem is that you probably have no idea what the
> distribution is of your 0.1 ms jitter, and if you have no idea what
> it is you can't properly correct for it, and you probably make
> things worse.

Yes, no way to improve on the 0.1mS jitter, but that is still 10x
better than the casual observer would expect.

> Adding the 0.5 to the 0.1 ms would probably give something in the
> order of 0.6 ms, and would probably end up better like a normal
> distribution, which is what you want. But in the end the you're not
> going to get much better than the 0.1 ms.

Yup, so pointless.  But feel free to experiment.

> Adding noise here after the measurment really doesn't make sense
> to me.

Good, we agree, but NTP does it.

> You would instead need to modify the output of the PPS
> signal to add random jitter to it, so that it doesn't always
> happen every 1024 polls.

That would be many mS of jitter.  Also not good.

> > > 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.  
> 
> NTP uses the smallest difference in time the program can see
> as precision, which is at least confusing. Precision is about how
> repeatable something is.

Uh, no.  The smallest difference in time it can see is about sys_fuzz.
Basically how fast the clock can be read and/or the smallest tick in the
clock that it can see.  Not to be confused with the LSB of the
read system clock.

The precision can be 10e6 worse than that sys_fuzz.

Once again, we really need an NTP specific dictionary because NTP defines
things in unusual ways.

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/61834f18/attachment.bin>