"Ron Frazier (NTP)" <timekeepingntpl...@c3energy.com> wrote in message
news:4f6dda72.30...@c3energy.com...
[]
Hi David,
You appear to be up early. I'm curious to know what time this email
says it arrived. If it says it arrived at about 1030, then that's my
time. If it says it arrived at about 14:30, then that's your time.
I am on UTC here, and the posting was made in the (very) early hours.
Since I wrote that, it seems to have centered itself around zero. I now
have a very nice + 1.2 ms / - 1.2 ms offset pattern. Since I've been
struggling to get anything under 50 ms with other technology, this looks
really sweet to me.
http://dl.dropbox.com/u/9879631/Sure%20board%20first%20night%20pt1.jpg
http://dl.dropbox.com/u/9879631/Sure%20board%20first%20night%20pt2.jpg
Conversion of these images to jpeg reduced the clarity a bit, but you
can still see what's happening.
I vaguely recall that USB has a polling interval of ~1 millisecond.
Additionally, unless you use interpolation, Windows timestamping
introduces a further 1 millisecond quantisation in its timestamps of the
USB data (that 0.977 ms jitter is the signature of plain Windows
timestamps), so your +/- 2 milliseconds max seems to be of the correct
order
MICROSECONDS, did you say? I'm nowhere near that territory with
everything going through a serial - USB converter. However, I'm quite
happy with 1.2 ms under the circumstances.
That millisecond polling is the limiting factor, go for a hardware serial
port and the kernel-mode timestamping and you're an order or two better
again.
I am NOW assuming that my clock is more accurate than the internet
clocks. I am NOW hoping that neither will appear to be drifting away
and that nothing in the system will be having routine heart attacks.
Fingers crossed. For the reasons mentioned above you could be up to a
couple of milliseconds out in absolute terms.
I notice there is a difference between my clock and the average internet
clock reading. Hypothetically, even though mine is probably closer to
UTC than those readings, if I wanted to shift my offset to match them,
so NTP won't clockhop, how as long as the GPS is working, how would I do
that?
Here are my config lines:
# COM5 57600 windows lines for testing gps selected as main source -
gpgga 57600 baud
server 127.127.22.5 minpoll 3 maxpoll 3
# PPS
fudge 127.127.22.5 flag2 0 refid PPS
# PPS standard polarity
server 127.127.20.5 prefer minpoll 3 maxpoll 3 mode 66
# NMEA
fudge 127.127.20.5 time2 0.0000 refid GPS1
# use WITH PPS
Also, why doesn't the PPS show up in my status screen anywhere? I know
it's working, based on the graphs.
Sincerely,
Ron
Check the driver configuration.
PPS requires the kernel-mode timestamping of the DCD line going active,
and that's only available in Dave Hart's serial-pps driver/DLL. For the
same PPS timesamps in other drivers would require e.g. USB providers to
update their drivers as well, which isn't at all likely to happen. If you
knew that the average delay between true start-of-second and your PC
timestamping the USB/serial packet was 1.5 milliseconds, you could
probably use something like:
fudge 127.127.20.5 time2 0.0015 refid GPS1
Looking at your plot of peer offset, though, that might bring the best
Internet server /nearer/ to zero offset.
BTW: you may find that PNG is a better format for saving graphics - except
for the lines which are very "noisy" and would increase the file size.
PNG is lossless, and can produce quite small files of plots. That's one
reason my program saves data in that format.
I'm delighted with your results so far.
Cheers,
David
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
