Re: [time-nuts] Time stamping with a PICPET
tvb@LeapSecond.com said:
As far as NTP is concerned, I wonder if you've ever considered turning the
tables on how it works. AFAIK, NTP gets an external time reference (e.g.,
1PPS) as an interrupt. With modern computers, this is horrible. There are
far too may layers of h/w jitter (pipelines, multiple levels of cache, TLB
misses, etc.) and s/w jitter (interrupt handling, spinlocks, interrupt
masking, priority levels, etc.).
You have to have your time-nut hat on before that makes a difference.
Has anybody measured it? It should be easy to hack the kernel PPS interrupt
routine to flap a printer port signal and measure the delay between the PPS
signal and printer port.
For best timing, perhaps a better solution is not to have NTP receive a 1PPS
as input and try to pretend to measure it internally in s/w but for NTP to
output a 1PPS and measure that externally with sub-microsecond h/w (like a
picPET).
The Trimble Palisade and Acutime work that way.
--
These are my opinions. I hate spam.
Yes this gets measured all the time. But not this way. In the usual case
the PPS causes the nanosecond clock to be trapped and logged. The clock
has good enough stably for this that it is not a major error source.
If the system were to try and create a PPS then it would have to be based
on the nanosecond clock or a hardware count down register based on it. I
just cannot see how a count down timer interrupt can have less jitter than
a DCD line interrupt.
A few people have gotten around this by moving the computer's timing clock
off the CPU chip. Then you can use hardware latches and such that have
very predictable timing. I think this is the only way to improve the
current system. You have t remember that there is a large and active
community of researchers who have been working on this for just over 30
years now in the latest development version that are talking about
nanosecond level time keeping.
The answer to measuring is "a few microseconds" In fact if you need to
measure a time interval at that level of accurately all you need is a
standard computer with some serial ports. There is an interesting
project to monist the AC mains line frequency and the sensor is just an AC
transformer connected the the DCD pin of a serial port.
On Sat, Oct 26, 2013 at 2:47 PM, Hal Murray hmurray@megapathdsl.net wrote:
You have to have your time-nut hat on before that makes a difference.
Has anybody measured it? It should be easy to hack the kernel PPS
interrupt
routine to flap a printer port signal and measure the delay between the PPS
signal and printer port.
--
Chris Albertson
Redondo Beach, California
If the system were to try and create a PPS then it would have to be based
on the nanosecond clock or a hardware count down register based on it. I
just cannot see how a count down timer interrupt can have less jitter than
a DCD line interrupt.
Right. The key is not to use count-down timers and interrupts at all. The key is no interrupts; nothing asynchronous. What you do is:
-
About once a second (it doesn't really matter), with hot cache and interrupts disabled, record the s/w time before and after you output a pulse. If your PC/SBC has a low-latency DTR or GPIO pin code path, you're golden.
-
Then use external h/w to timestamp that pulse at the sub-microsecond level.
-
And then you compare the s/w timestamp of when the pulse was thought to be generated against the h/timestamp of when the pulse was known to be actually received. This allows you to compare s/w "pretend" time against "actual" h/w time. This jitter-free delta is what NTP can use for its discipline algorithm, to smoothly bend s/w virtual time to match real h/w time.
A few people have gotten around this by moving the computer's timing clock
off the CPU chip. Then you can use hardware latches and such that have
very predictable timing. I think this is the only way to improve the
current system. You have t remember that there is a large and active
community of researchers who have been working on this for just over 30
years now in the latest development version that are talking about
nanosecond level time keeping.
If the CPU/PC/SBC has h/w counter/capture latches, you're all set. Then there's no jitter and NTP should be as accurate as the ADEV(tau 1s) of the LO that clocks the CPU and the ADEV(tau) of the external (GPS) 1PPS source.
But h/w counter/capture is something no legacy PC has had AFAIK. If the new breed of SBC have this capability, NTP should show a one or two orders of magnitude jump in precision on those platforms.
/tvb
On 26 Oct, 2013, at 18:21 , Tom Van Baak tvb@leapsecond.com wrote:
Right. The key is not to use count-down timers and interrupts at all. The key is no interrupts; nothing asynchronous. What you do is:
- About once a second (it doesn't really matter), with hot cache and interrupts disabled, record the s/w time before and after you output a pulse. If your PC/SBC has a low-latency DTR or GPIO pin code path, you're golden.
That's perfect if it works like it seems it should. The problem with modern CPUs is
finding an instruction sequence that does the read-write-read in that order, allowing
each to complete before doing the next. The write is the biggest problem. Writes are
often buffered, and even when you can find an instruction which stalls until it clears
the buffer the write will also often be posted across the interconnect bus so there's
no way for the CPU to know when the write makes it to the device, let alone make it
wait until that happens.
When using the CPU cycle counter as a system clock source it is common to find that
the two reads in a read-write-read sequence are only a cycle or two different even
when you know the write is crossing an interconnect with 10's of nanoseconds of latency
(not that 10's of nanoseconds is bad...).
It is usually easier to find the magic instructions to make a read-read-read work
the way one expects, though even that can be a challenge. It is possible to do
the same output pulse thing with a read-read-read if there is a PWM peripheral to
generate the pulses. The PWM is programmed to output pulses at whatever frequency
is convenient while the read-read-read sampling is used to determine the relationship
between the PWM counter and the system clock. Of course, this requires a peripheral
which legacy PCs often don't have.
If the CPU/PC/SBC has h/w counter/capture latches, you're all set. Then there's no jitter and NTP should be as accurate as the ADEV(tau 1s) of the LO that clocks the CPU and the ADEV(tau) of the external (GPS) 1PPS source.
But h/w counter/capture is something no legacy PC has had AFAIK. If the new breed of SBC have this capability, NTP should show a one or two orders of magnitude jump in precision on those platforms.
The TI CPU used for the Beaglebone (Black) has three. The counter being sampled
is 100 MHz.
Dennis Ferguson
So basically what you are proposing is an NTP reference clock that queries
a known good external clock at semi-random intervals. The query method is
to send a pulse then read the time from the external clock.
GPS is a "push" device. It just sends data forever. What you are wanting
is a "pull" device, one that will tell you the absolute time of a pulse.
It would not be hard to build. Get a 32 bit counter that is driven by a
10MHz GPSDO. then a pulse will latch the counter. You'd need a very fast
logic family if you plan to count nanoseconds.
The query would not be once per second. NTP would use its normal method to
determine the interval, usually it is much longer than one second.
I bet there must already be an NTP ref clock that is based on query. that
could be a starting place.
the typical HP counter could work as the clock. On one channel you feed it
a PPS from your GPS the pulse from the computer goes to the other channel.
the HP buss sends back the time after the last full second. This could
be pico seconds if you have the right counter. So you could implement
this with no solder.
On Sat, Oct 26, 2013 at 4:21 PM, Tom Van Baak tvb@leapsecond.com wrote:
If the system were to try and create a PPS then it would have to be based
on the nanosecond clock or a hardware count down register based on it.
I
just cannot see how a count down timer interrupt can have less jitter
than
a DCD line interrupt.
Right. The key is not to use count-down timers and interrupts at all. The
key is no interrupts; nothing asynchronous. What you do is:
-
About once a second (it doesn't really matter), with hot cache and
interrupts disabled, record the s/w time before and after you output a
pulse. If your PC/SBC has a low-latency DTR or GPIO pin code path, you're
golden. -
Then use external h/w to timestamp that pulse at the sub-microsecond
level. -
And then you compare the s/w timestamp of when the pulse was thought to
be generated against the h/timestamp of when the pulse was known to be
actually received. This allows you to compare s/w "pretend" time against
"actual" h/w time. This jitter-free delta is what NTP can use for its
discipline algorithm, to smoothly bend s/w virtual time to match real h/w
time.
A few people have gotten around this by moving the computer's timing
clock
off the CPU chip. Then you can use hardware latches and such that have
very predictable timing. I think this is the only way to improve the
current system. You have t remember that there is a large and active
community of researchers who have been working on this for just over 30
years now in the latest development version that are talking about
nanosecond level time keeping.
If the CPU/PC/SBC has h/w counter/capture latches, you're all set. Then
there's no jitter and NTP should be as accurate as the ADEV(tau 1s) of the
LO that clocks the CPU and the ADEV(tau) of the external (GPS) 1PPS source.
But h/w counter/capture is something no legacy PC has had AFAIK. If the
new breed of SBC have this capability, NTP should show a one or two orders
of magnitude jump in precision on those platforms.
/tvb
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Yes that is right. CPUs can execute instruction out of order. So you
might write Read, Write, Read but the CPU might decide to do the second
read before the write. You can ever know. Even if you use some clever
trick it will only work on the one exact model CPU you tested it with.
This is not now the CDC 6400 built in the 1960's could start on e
instruction then start up to nine more before the first one finished. As
long as some future instruction did not use the result of a previous one
the CPU would not wait for the result. You could have up to 10
instructions being executed at the same time. We tried for that but it was
hard to do. Four at once was easy.
Modern CPUs are MUCH more complex and will even do speculative executions.
and brach prediction which means they need a way to "back up", and toss out
results from wrong predictions. It is impossible to know the timing in
advance. I think hyper threading (hardware level multitasking) adds even
one more layer.
On Sat, Oct 26, 2013 at 6:49 PM, Dennis Ferguson <
dennis.c.ferguson@gmail.com> wrote:
That's perfect if it works like it seems it should. The problem with
modern CPUs is
finding an instruction sequence that does the read-write-read in that
order, allowing
each to complete before doing the next.--
Chris Albertson
Redondo Beach, California
Chris,
So basically what you are proposing is an NTP reference clock that queries
a known good external clock at semi-random intervals. The query method is
to send a pulse then read the time from the external clock.
GPS is a "push" device. It just sends data forever. What you are wanting
is a "pull" device, one that will tell you the absolute time of a pulse.
It would not be hard to build. Get a 32 bit counter that is driven by a
10MHz GPSDO. then a pulse will latch the counter. You'd need a very
fast logic family if you plan to count nanoseconds.
This is already available even in some small mass market receivers. See
the uBlox Lea-6T and other uBlox receivers.
"Time mark of external event inputs"
This has also been available in high quality L1 receivers and L1/L2
receivers used for airborne photogrammetry.
Read the text on page 40 and onwards of the Ashtech G12 manual
http://goo.gl/Oc1htQ
The same feature is also available in all(?) the bus interface T/F cards
from Bancomm/Datum/Symmetricom/Truetime/Spectracom/KSI/Odetics etc.
"Event Time Capture. An Event Time Capture feature provides a means of
latching time for an external event input."
from
http://www.symmetricom.com/products/bus-level-timing/legacy-pci/bc635PCI-U-IRIG/
The query would not be once per second. NTP would use its normal method
to
determine the interval, usually it is much longer than one second.
I bet there must already be an NTP ref clock that is based on query. that
could be a starting place.
See the Palisade refclock driver
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver29.html
kind regards,
Björn
So now we can know if this works better. Does the Palisade ref clock work
better then the Atom ref clock?
On Sun, Oct 27, 2013 at 12:51 AM, "Björn" bg@lysator.liu.se wrote:
Chris,
So basically what you are proposing is an NTP reference clock that
queries
a known good external clock at semi-random intervals....
See the Palisade refclock driver
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver29.html
kind regards,
Björn
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California