I need to do some accurate time measurements and I need to have access to a affordable / cheap and somewhat more reliable timestamp/time source than what is built in Windows/CPU.

I need to read the timestamp values from Windows.

Can anyone give some hints on what to use to get a better timestamp?

I guess some kind of PCI-Express based hardware timer card?

I don't need super-high accuracy, but a resolution around 100ns would be good.

  • 3
    \$\begingroup\$ You might want to review the explanations at stackoverflow.com/questions/9040967/… and stackoverflow.com/questions/9041259/… \$\endgroup\$ – Ben Voigt Feb 21 '12 at 20:15
  • 1
    \$\begingroup\$ "resolution around 100ns" is not a precise specification. Do you want something with <100ns/second drift? Something that ticks once per 100ns? The relevant parameters are frequency stability, frequency tolerance, and frequency drift. \$\endgroup\$ – Kevin Vermeer Feb 21 '12 at 20:50
  • \$\begingroup\$ Also, this site is about electronics design - We can help you configure a toolchain or figure out a schematic capture program, but our sister site, stackoverflow, is the place you should go to figure out how to access this from Windows. I'll add that it won't be easy; see the excellent questions that Ben has linked to for more information on this problem, and look into real-time operating systems which will be required to use any timestamp source. \$\endgroup\$ – Kevin Vermeer Feb 21 '12 at 20:52
  • \$\begingroup\$ I know this is a electronics site, but what I am looking for is an affordable hardware clock sources that can give me a fairly accurate timestamp. The built in "stopwatch" in Windows/CPU is tied to the CPU frequency, but the frequency of the CPU can vary due to throttling or turbo boost featues, meaning that it will be impossible to figure out the true current frequency of that counter. So what I am looking for is a hardware solution to give me a timestamp that has a fixed frequency that I can have as reference. That I easilly can plug into a computer. (PCI express?) \$\endgroup\$ – user316 Feb 21 '12 at 21:44
  • \$\begingroup\$ So basically I need a fixed 5-10MHz hardware 32-64 bit counter that I can poll from Windows, with a decent stability/toleance/drift. A quartz crystal would be sufficient. I also asume a PCI/PCI-Express implementation is the move accurate way to implement this as USB/firewire is a bit to undeterministic? \$\endgroup\$ – user316 Feb 21 '12 at 21:50

Does your target machine have a High Precision Event Timer (HPET)? This seems like it would work, the resolution is within your requirements and they're common on recent hardware. Is there any reason you can't use it?

If you're reading from Windows I'd be wary about the precision you'll get. Since Windows offers no guarantee when a thread executes the time between you reading from the HPET (or other timestamp source) and the time it returns is non-deterministic. Your time source will probably be offering more granularity than you can reliably obtain when the scheduler is in your way.

  • \$\begingroup\$ But by reading twice in rapid succession you can determine whether Windows switched your thread. I'd be more worried about the context switches in between the occurrence of the event you want to timestamp and a read of the HPET, than between the HPET access and the return from the timer API. \$\endgroup\$ – Ben Voigt Feb 22 '12 at 23:37
  • \$\begingroup\$ Why I am dubious about the HPET or QueryPerformanceCounter is that according to documentation it says: "On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). ". So to verify the accuracy of various timer implementation it woul dbe useful to have a external known timer source, perhaps in the way of a PCI-express card? \$\endgroup\$ – user316 Feb 23 '12 at 14:16
  • \$\begingroup\$ Looking at the highly relevant StackOverflow question the responses reflect the same sentiment. The HAL and scheduler are still problems if you use a PCI-E source. The dubiousness about HAL is going to be there as long as you use Windows, and if you set the affinity of your timing thread to one CPU you can avoid BIOS bugs. I honestly think your best bet is to just do all you can to minimise the error you get out of the HPET. It'll be cheaper at the very least. \$\endgroup\$ – Mathew Hall Feb 24 '12 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.