Timer Resolution

0 views

Skip to first unread message

Jeanmarie Morock

unread,

Jan 20, 2024, 7:11:49 AM1/20/24

to bansecombots

Just wanted to ask what ppl's experience with timer resolution is. For me, personally used it today and the game definitely felt more responsive personally, but I don't know if it's just a placebo or not so just wanted to ask around to see what people's opinion of it is.

timer resolution

Download File » https://t.co/SEFT2f7S1g

Some process must be calling NtSetTimerResolution with a value of 5000 (0.5ms), but how can I determine which one? I saw Intel has a tool called Battery Life Analyzer that shows the current timer resolution per process, but that tool is only available to Intel partners. Is there another tool or a way to see it via WinDbg? Note: It seems to happen at boot time as setting a breakpoint isn't working (the resolution is already high when the debugger starts).

The only way I know and have used so far is injecting into each of running processes and inside that process calling timeEndPeriod for each increased resolution (values 1-15) in a loop over these resolutions and checking whether the timeEndPeriod call for a current resolution returns TIMERR_NOCANDO or TIMERR_NOERROR (note: these return values are NOT correspondingly false and true). And if it returns TIMERR_NOERROR then concluding that the program is using that frequency, and then calling again timeBeginPeriod to restore the original resolution requested by the program.

If you want to continuously monitor the new timer resolutions then hooking calls to undocumented NtSetTimerResolution function in ntdll.dll is the way I use currently (the function's signature can be taken for example from here).

Unfortunately hooking does not detect timer resolutions that were requested before the hook was installed, so you need to combine it with the above timeEndPeriod trick and note also that the 0.5 ms resolution requests before the hooking stay undetected.

Note that I copied and pasted some code and played around with the parameters. I guessed that TCCR2B = 0x1 makes the prescaler 1. For the most part, I only know approximately what the code does: The arduino's timer2 increments the value in an 8 bit register, when this overflows an interrupt is fired. Setting the prescaler to 1 and the value in the register to 255 (leaving only one incrementation until overflow) theoretically makes the register overflow every 62.5ns.

I used this code to flash an LED, and determined that I had a resolution of around 500ns; an order of magnitude worse than my target! Is my code incorrect? Is it just less efficient than it could be? Or am I flogging a dead horse; am I ever going to get down to 62.5ns?

Use the Input Capture feature of Timer1. That will look for an edge on the ICP1 pin (Pin 8) and saves the current value of Timer1 in the ICR1 register. Use the ICR interrupt (which happens AFTER the data is safely stored) to save ICR1 in a variable. Then you can compare that to a future input capture. This will give you intervals with 62.5nS resolution, assuming you are running Timer1 with a prescale of 1. The timer will overflow at 244+ Hz so any interval longer than a couple of milliseconds you will want to track timer overflows as well.

A modern computer has many time sources. Some on the CPU die, some elsewhere. Typically these have different resolutions and different abilities (e.g. fire once, fire every X seconds, ...). Some of them stop when a CPU is suspended (e.g. in C states), some do not.

Timer resolution is the smallest unit of time that can be accurately measured by that timer. Timer resolution for the CPU (which is the RTC or Real Time Clock resolution) differs from that of the API made available to the programmer by the operating system. Check this.

Hi,
We tried with nanosleep on HiFive Unleashed u540 of 1ns and got delay of approx 100-130usec.What could be the cause for this delay?
2) What is the lowest clock resolution that can be achieved?
3)What is the lowest sleep time that can be set?

The following example calls the timeGetDevCaps function to determine the minimum and maximum timer resolutions supported by the timer services. Before it sets up any timer events, the example establishes the minimum timer resolution by using the timeBeginPeriod function.

I have an 8Mhz ATM32u4 that is able to read external pulse inputs at 125ns ticks using InputCapture3 (PC7) on its 16-bit timer. Is there a magical way (bitbanging?) to get around 10ns tick resolution to read pulses? Edit: like ADC conversions to allow 16-bit systems 24-bit accuracy via creative coding, etc.

The shortest expected pulse would be about 70us which needs to be measured at (around) a resolution of 18ns for the accuracy I need. So I went with 10ns for design to allow for some accuracy "overhead". That is between 4000-7000 counts/ticks (18ns-10ns ticks) for the 70us signal.

Running at 16 MHz each clock pulse is 62.5 ns which means that is the absolute most resolution it could count. I don't see why you can't count at the rate of 62.5 ns (rather than 125 ns), however that isn't 10 ns resolution.

1 ns is a billionth of a second. A 1 gHz clock has a cycle time of 1 ns. If you have a timer that's able to count single clock pulses you'd need a 1 gHz clock to get to 1 ns resolution. for 10 ns, you'd need a 100 mHz clock.

As can be seen above, on the first execution of ClockRes the Current timer interval was 1.001 ms, while on the second execution of the ClockRes program the Current timer interval was 15.626 ms. There is an odd similarity between that 15.626ms time (which oddly exceeds the reported Maximum timer interval of 15.625ms) and the c=15600 reported in the Oracle 10046 extended SQL trace file. So, what change did I make to the server between the first execution of ClockRes utility and the second execution? For now I will just say that I stopped one of the background services on the server (more later).

I recall performing an experiment a couple of years ago with Oracle Database. I downloaded a utility that offered to change the Windows default timer resolution from 15.625ms to 1.0ms. That utility did in fact change the Windows timer resolution, resulting in Oracle Database outputting c= values in increments of 1000, rather than in increments of 15600. If I am remembering correctly, a second outcome of the experiment was a decrease in performance of the test Oracle database on the computer due to the higher resolution of the Windows timer.

Modern processors and chipsets, particularly in portable platforms, use the idle time between system timer intervals to reduce system power consumption. Various processor and chipset components are placed into low-power idle states between timer intervals. However, these low-power idle states are often ineffective at lowering system power consumption when the system timer interval is less than the default.

Platform Timer Resolution:Platform Timer Resolution
The default platform timer resolution is 15.6ms (15625000ns) and should be used whenever the system is idle. If the timer resolution is increased, processor power management technologies may not be effective. The timer resolution may be increased due to multimedia playback or graphical animations.
Current Timer Resolution (100ns units) 10009
Maximum Timer Period (100ns units) 156250

AN electronic digital timer was developed for measuring the velocity of a high speed (30 m/s) projectile used in a recently invented edible nut cracker. Tests showed that two retroflective type PIN photodiode sensors located 7.62 cm apart could consistantly start and stop the timer at velocities up to 45.9 m/s (102.7 mph). Sufficient details are given for others to build similar systems. An oscilloscope was attached to both diodes to enable evaluation of the timer accuracy. Thirty replications of thirteen combinations of projectile mass and nominal velocity showed there were no differences between velocities calculated from time data obtained from: diodes 1 and 2, timer display and oscilliscope, or diodes and timer display. Agreement between diodes 1 and 2 indicated the projectile did not change velocity in the 7.62 cm distance between diodes.