On 18/03/14 09:59, Martin Burnicki wrote:
Magnus Danielson wrote:
On 17/03/14 09:48, Martin Burnicki wrote:
You'd need hardware (FPGA?) which can be clocked at 1 GHz, and even in
the hardware signal processing you'd need to account for a number of
signal propagation delays which you can eventually ignore at lower clock
rates.
So of course the effort becomes much higher if you want more accuracy,
but this is always the case, even if you compare NTP to the "time"
protocol, or PTP to NTP.
You don't need to count at 1 GHz, you can achieve the resolution with
*much* lower frequencies. One pair of counters I have achieve 2,7 ps
single-shot resolution using 90 MHz clock. Interpolators does the trick.
There is many ways to interpolate.
Agreed. I just thought the way to use a higher counter clock is more
obvious. All depends on how accurate and precise you can get your
timestamps, and this is probably easier with network packet timestampers
at both sides of a cable than with a wireless time transfer method like
GPS which usually suffers from delays which can't easily be measured,
like ionospheric delays. And yes, I know that this can be improved if
you receive 2 GPS frequencies instead of only the L1. ;-)
Indeed. If you read the right article from 1990 you also know you can do
it on L1 C/A only by monitoring both code and carrier phase, as their
ionospheric effect have opposite signs.
Carrier phase by the way is a good illustration that the frequency you
have (1,57542 GHz) is not the limiting factor, as you can make
observations to within 1/100 of the cycle, or about 2 mm. The precision
and accuracy needs *tons* of processing to get in that neighborhood,
especially since the tropospherical delay is hard to estimate and
compensate for in a single receiver.
Anway, resolution and counter frequency is and remains two different
things. Precision measurements can be made using two lower frequency
signals.
Achieving the necessary resolution then turns into the troublesome issue
of precision, which require calibrations and systematic studies.
I've seen some papers reporting tens to hundreds of nanoseconds
average
sync error, but for datasets that might have 100 points, and even then
there are many outliers.
I'm getting PTP questions on this from hopeful system designers.
These
systems already run NTP, and achieve millisecond level sync errors.
Uh, perhaps show them to achievement of microsecond level sync errors?
That is already a factor of 1000 better than they achieve.
One of the key problems is getting the packets onto the network (delays
withing the ethernet card) special hardware on teh cards which
timestamps the sending and receiveing of packets on both ends could do
better.a But it also depends on the routers and switches between the
two
systems.
Of course all involved network nodes needed to be able to timestamp at
this high resolution, otherwise the overall accuracy would be degraded.
And, it would probably be easier to achieve this accuracy with an
embedded device with dedicated hardware than with a a standard PC and a
NIC connected via the PCI bus.
There is a whole myriad of issues you end up with when you try to get
down that low.
Yep.
If there were a 1 GHz oscillator on the NIC used for timestamping then
you still have to provide a way to relate the timestamps from the NIC to
your local system time. If the only way to do this is via the (PCI?) bus
then the accuracy could suffer from bus latency, arbitration, etc.
No go.
On a dedicated hardware the same oscillator/high resolution counter
chain could be used for system timekeeping, and to timestamp network
packets, which makes things much easier.
You end up with quite dedicated hardware if you want to go there, yes.
Regardless of how you do it.
Standard PC hardware hasn't been designed for timekeeping at highest
accuracy, neither the cheap crystal oscillator usually assembled on the
mainboard, nor the missing "hard link" between hardware on a PCI card
and the CPU, nor the TSCs often used for timekeeping which may suffer
from changes of the CPU clock frequency (with older CPU types) or
changes of the front bus clock frequency (with newer CPU types).
Indeed. In the old days, you could accurately count your clock cycles in
your assembler and a single common clock for the full machine. No such
luck anymore.
Cheers,
Magnus
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
