[ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
gdmr at inf.ed.ac.uk
Tue Jan 20 14:53:28 UTC 2015
> It is not the resolution of the time tag that matters, but the accuracy
> at which it can be received by an asynchronous serial port.
Ah, no, the timeousness of reading the timestamp isn't relevant, provided
only that the driver doesn't hammer on the clock unit too hard (which it
doesn't; once a second would be absolutely fine, and polling is less
frequent than that). All that matters is that the kernel can toggle the
leading edge of the timestamp-request data line reliably enough, and that
the driver's timestamps taken before and after the ioctl() don't have much
jitter. We regularly see our unit's jitter around 0.001, and the offsets to
other timeservers in the low numbers of microseconds.
> You will probably require fudge configuration to calibrate it to an
> existing known-good source to get within 1ms of true time.
The only fudge we should really apply is to the clock unit itself to
account for the cable length. But we don't need to be accurate to the
nanosecond, so we haven't bothered. The default value, which I don't have
easily to hand, was good enough.
> I don't know what your requirements are, so it is difficult to judge
> if what you have now is good enough.
It's way more than good enough for us, out of the box. The original poster
to this thread will have to decide for their own situation.
George D M Ross MSc PhD CEng MBCS CITP, University of Edinburgh,
School of Informatics, 10 Crichton Street, Edinburgh, Scotland, EH8 9AB
Mail: gdmr at inf.ed.ac.uk Voice: 0131 650 5147 Fax: 0131 650 6899
PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 237 bytes
Desc: not available
More information about the questions