PPS undersampling

[Gary E. Miller]

Yo Hal!

On Tue, 23 Aug 2016 16:13:04 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

> > Yeah, been looking at that.  Since ntpd is undersampling the PPS it
> > can be either good, or real bad.  I'm tempted to get Eric to fix
> > the bug first, but maybe I'll need to data so he sees the bug
> > first.   
> 
> I don't know of any ntpd bug in this area.  Do you have a test case?
> Or data from a buggy run?

Not a formal bug, but a bug none the less.  Easy to reproduce: reboot
your host, with an intentional off swclock.  Then look at how many PPS
sample you get per poll period.  At the perverse end ntpd can miss
one in 12 samples.

I have proposed this simple test many times.  I have run it myself many
times.  Have you done that yet?  I have also proposed other simple tests.
For some reason no one ever comes back with data to show my tests show
no problem.

Misunderstandings in this area cause people to break the PPS code in
gpsd every few years.  I keep having to revert the changes and show
people the data that says their changes are bad

Having been there, done that, so many time in the PPS code I am not
prepared to take two weeks of my time to explain it again until
Eric is prepared to take 4 weeks of his time to fix it.

> There are/were glitches in some of the gpsd utilities.  I fixed one a
> long time ago and I think you fixed one recently.  But they are using
> a different mechanism.

Yes, totally unrelated.

> Your mention of Nyquist on IRC a few days ago makes me think that you
> don't understand this area or more likely are just grabbing a word in
> a related area for a similar problem.

Nyquist was a key part of my EE degree.  I worked for and consulted to
many test equipment companies for many years.  I reverse engineered
a lot of HP gear.  So yes, I'll put my knowledge of Nyquist up with
anyone's.

BUT, I do not expect anyone to care about the previous paragraph.  When
the timme is right, when NTPsec is prepared to understand and accept
improvements, I will dust off my test cses for one and all to see.

In tthe end the data will speak for itself.

> Nyquist refers to analog signals.  If your signal has a bandwidth of
> X Hz, you need 2*X samples per second in order to be able to
> reconstruct the signal.

Mostly correct, except for the word 'analog', and some gross over
simplification.

FWIW, note that Wikipedia agree with me:

https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem

You would do well to read and undertand that article, as a start.

I actually spent time in the dark ages creating UARTs out of TTL.  If
you are up for archeology I suggested you look at how that is done, and
how Nyquist-Shannon theory was such an important part.

> The gpsd code I fixed was doing something like:
>   while true {
>     if sampleready() then dosomething()
>     sleep 1 second
>   }

No, that is the gpsd code that broke it.  Since fixed.

> The code in ntpd doesn't work that way.  It runs off a timer that
> signals and resets itself.  That signal goes off every second, the
> same rate as the PPS.

Which is proveably wrong.

> But the ntpd clock is not unsynchronized.  It's running at exactly 1
> second per second in the long term.

And the long term is not the problem.  The problem is the positively 
aweful startup performance of ntpd.

> Actually, any fix should wait for a bigger cleanup in this area.


And in this we 100% agree.  When the time comes I have a number of
experiments for one and all to run that show the problems.


> We
> should get rid of the current every-second timer unless some refclock
> needs it.

Yes, but what drivers really need what is a huge discussion.  That is
for the long term todo list.

> But all that
> should wait until after TESTFRAME so we can test it.


And on that we also agree, so no further discussion needed until after
TESTFRAME.

BTW, did you do the soldering ron test I asked you to do?


RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160823/176f3c82/attachment.bin>