KeWaitForSingleObject vs busy loop

NTDEV
1

hello which one is more precise delay KeWaitForSingleObject 1 second or busy loop rdtsc ?

void WaitDelay()
{
	UINT64 Now, Then, FreqDelay;

	FreqDelay = ((0xFF & (__readmsr(0xCE) >> 8)) * 100000000LL);


	Now = __rdtsc();
	Then = Now + FreqDelay;

	do {
		Now = __rdtsc();
	} while (Now < Then);
}
  vs KeInitializeEvent(&Event, SynchronizationEvent, 0);
			Timeout.QuadPart = -10000000;
			KeWaitForSingleObject(&Event, Executive, KernelMode, FALSE, &Timeout);
2

KeWaitForSingleObject is not designed to be precise, so just about anything will be "more precise" than that.

Why don't you use KeStallExecutionProcessor instead of trying to "roll your own"??

What are you trying to accomplish? Do you really require such precision?

3

im trying to measure the TSC Frequency accurate as possible i heard KeStallExecutionProcessor hogging the cpu so i need roll my own precise delay i guess

4

Unless you have 'hogged the cpu' your measurement is going to be inaccurate.

5

Unfortunately, this is a ridiculous goal. What do you plan to measure it against? Remember that whatever timebase you choose is driven by the EXACT SAME CLOCKS that drive the TSC. Unless you have an independent time source from outside the computer, there is no "unbiased observer" available to make your measurements.

6

Hmmm... That's the most confusing reply I've read here on NTDEV in quite some time.

So, in case it matters: KeStallExecutionProcessor executes a calibration loop each time the system boots, to determine how best to "busy wait" for the specified amount of time. So, yes... KeStallExecutionProcessor "hogs the CPU" -- in runs in a loop until the time period has elapsed.

What level of precision do you require? What are you trying to do?

1 Like
7

You should also note that over a long period of time, Windows estimates the clock 'run' rate on each machine by using the NTP protocol. See GetSystemTimeAdjustment

You can do better with a radio receiver for GPS signals, but it requires specialized hardware. And it still feeds into the standard calibration.

8

trying to measure the rdtsc frequency accurate as possible found out
KeWaitForSingleObject doing great job is it true rdtsc still effected by turbo boost even if we have invariant tsc

9

OK… my last comment on this thread: I’m sure that what you’re doing makes sense in some larger scheme of things. But, you’re trying to measure the frequency of the highest frequency clock on the machine (the TSC) using a timing mechanism (Windows timers) that is by design very coarse and subject to skew. For example, Windows can actually modify timer requests that are “sort of” close time wise, so that they are identical. So, I dunno… it seems to me that you’re trying to check the frequency of a stop watch using a sun dial.

Whatever makes you a happy, you know? :upside_down_face:

10

got it but rdtsc cycle count on base frequency of intel on amd its p0 frequency