> 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: g...@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.
pgpPSzNn_UlMQ.pgp
Description: PGP signature
_______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
