1. Home
  2. Electronics Design
  3. PC timer

PC timer

You can probably get that - tcpdump (well, windump) reports packet times in microseconds. All the digits change but no idea what the increment or accuracy actually is.

The old 8253 chip in the PC is clocked at 4.77 mhz / 4 or 1.193 MHz giving a theoretical resolution of a bit less than a microsecond (or perhaps half that rate, depending on the minimum count), if you either reprogram the interrupt to happen that fast or figure out how to read out the running count. Usually the interrupt was at the maximum 16 bit divisor of that - 18.2 Hz, but many programs sped it up.

There may be other clocks in more modern designs?

Reply to
cs_posting
Loading thread data ...

To do this at ring-3 without ASM you might want to try QueryPerformanceCounter() and QueryPerformanceFrequency().

formatting link
formatting link

Regards,

-Le Chaud Lapin-

Reply to
Le Chaud Lapin

On a modern PC what is the best resolution I can get from reading the clock? I need to timestamp data packets. Ideally I need sub millisecond res.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

The processor has a 64-bit counter, clocked by the CPU clock, which can be transferred into the EDX:EAX registers using the RDTSC machine instruction. This has nanosecond resolution on a 1 GHz processor.

Reply to
Andrew Holme

Probably. I'll leave the details for now and assume it can be done.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

Thanks. Now I know it can be done I can proceed with a bit more confidence.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

While it is true that the hardware of the PC is capable of sub-millisecond resolution, either with the Pentium RDTSC instruction or the 8254 clock, the usefulness of that resolution in an application depends on the operating system. If you are running Windows, then you cannot guarantee that there won't be a multi-millisecond gap between the data packet and the reading of the timestamp, due to multitasking. If you are running DOS, then perhaps you can form a reliable timestamp. If you are only interested in accurate timestamps 99.9% of the time, then Windows is fine.

-Robert Scott Ypsilanti, Michigan

Reply to
Robert Scott

I'm interested in maintaining relative timing accuracy of the packets. I guess I'll have to live with what I get.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

I'm going to "me too" this post. In a non-real-time OS with non-kernel code, there is just no way to GUARANTEE sub-millisecond timing, although it will probably work most of the time if the system is not bogged down with tasks.

If your code will be executing as a device driver, you may be able to take advantage of precise timing that you can trust, but I don't know enough about windows internals to tell you this for sure.

Same goes for linux (unless you are using some RTOS variant of linux).

--Mac

Reply to
Mac

clock?

You need to do it in Kernel Space. In Linux, that would be "easy" - in Windows, I do not know.

Your next problem will be how to synchronise the timestamps across a network .... more interesting, with the sub-millis and all ;-)

Reply to
Frithiof Andreas Jensen

I will have almost no control over the PC end of things since the code will be running inside a game.

FFF Dirk

The Consensus:- The political party for the new millenium

formatting link

Reply to
Dirk Bruere at Neopax

formatting link

formatting link

Thanks, I'll check it out.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

modern PCs (since pentium 3 I think) a a cycle counter in the CPU so the resolution is the system's clock period, (sub-nanosecond) Older PCs (back to PC/XT) have the system timer chip which can be read with

1 cycle precision (and its clock rate is 1.18Mhz IIRC) (so sub microsecond precision)

Milisecond resolution is easily possible if your application is the only process running, or has correct operating system suupport.

Bye. Jasen

Reply to
Jasen Betts

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.