3 ms·
>>technically just as practical What makes you think that? My experience has been that getting closer to perfection requires increasingly more effort as you ap
by RyanHamilton 6y ago
>>technically just as practical
What makes you think that?
My experience has been that getting closer to perfection requires increasingly more effort as you approach it. In this case, having a larger limit would allow monitoring and correction in case of an error without any kind of "trip" being triggered.
- lucaspauker 6y agoYou're right. The more fine-tuned it becomes, the more you have to consider low-level protocols. This paper https://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf https://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf suggests with current systems, time uncertainty can be decreased to about 1-10 us from NIST.
- jeffbee 6y agoIt doesn't really matter if the last three digits are just noise for the time being. It's just as practical, from the programmer's standpoint. 64 bits worth of nanoseconds gives abundant range (±292 years from the origin) and microsecond times already necessitate a 64-bit representation (2^31 microseconds only gets you half an hour). So you can build all your protocols around signed 64-bit nanos from a defined origin and never need to change it again.
- andylynch 6y agoThis has already happens. OUCH and other binary protocols have carried nanoseconds for years. FIX now specifies microseconds be supported in all time stamps but also lets you use nanos or even picos if you and your counterparty really want to.
- guenthert 6y agoThe protocols might had ns resolution, but that doesn't say anything about the accuracy of the time information in there. The PPS output of GPS receivers typically has a jitter of a few ns. And how well is the position of the antenna known?
- dmurray 6y agoNanosecond precision, for future proofing, but millisecond accuracy.