Pondering 2038
Pondering 2038
Posted Aug 15, 2013 14:27 UTC (Thu) by rleigh (guest, #14622)In reply to: Pondering 2038 by eru
Parent article: Pondering 2038
Working with scientific/medical imaging, millisecond time resolution is common, but microsecond and nanosecond resolution are also used. One thing worth pointing out is that it doesn't matter that the CPU can't measure this accurately; external acquisition hardware can, and we want to be able to store and process such timing data. Being able to store the deltaT in between frames at a higher precision removes one source of variability due to decreased error. And this applies to timings from anything external to the CPU. Even on the CPU, the increased precision is useful, even if it isn't as accurate as we might like.
Regards,
Roger
Posted Aug 16, 2013 9:01 UTC (Fri)
by eru (subscriber, #2753)
[Link]
Certainly true, but your measurement application is likely to use its own data type for the times in this situation anyway, if only for portability: you cannot rely on the OS you are using to provide a suitable high-resolution time type (especially now that multiple slightly different solutions for the same Y2038 problem are likely to emerge among Unix variants).
One thing worth pointing out is that it doesn't matter that the CPU can't measure this accurately; external acquisition hardware can, and we want to be able to store and process such timing data.
Pondering 2038