cannot receive messages; udp server with lnet

[Warfley]

You are right, that is defenetly not an exotic CPU.
If you are using Hyper-V VMs than this could be the issue, because this is where I have the exact same behavior when starting a Hyper-V VM.

[rvk]

If you are using Hyper-V VMs than this could be the issue, because this is where I have the exact same behavior when starting a Hyper-V VM.

In my Hyper-V Win10, (checking version... 21H2, so later than 2004) I still have long sleep(1) of 15ms.

Not sure why you have faster results in your Hyper-V.

Is there a method to query the current setting/value (the one which TimeBeginPeriod changes)??
Maybe some default setting in registry or otherwise is set.

[Warfley]

Maybe with ExSetTimerResolution (thin wrapper around the NT call): https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-exsettimerresolution if SetResolution is false it should return the current resolution

[PascalDragon]

Maybe with ExSetTimerResolution (thin wrapper around the NT call): https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-exsettimerresolution if SetResolution is false it should return the current resolution

Ex* functions are only available from kernel mode. Either use what is provided from the Windows API or use the Nt* function (despite not documented they're very stable as well).

[Warfley]

Ah you are right, I confused them with the FunctioNameEx functions.
The API for this is https://docs.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timegetdevcaps

[rvk]

Ah you are right, I confused them with the FunctioNameEx functions.
The API for this is https://docs.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timegetdevcaps

The TimeGetDevCaps only shows the min and max value. Not the current value.

Code: Pascal  [Select][+][-]

1. _timecaps = packed Record
2.   wPeriodMin: UINT;
3.   wPeriodMax: UINT;
4. end;

This doesn't give me a different value after doing TimeBeginPeriod(1), which I would expect because it does fix the sleep(1).

Code: Pascal  [Select][+][-]

1. var
2.   TCaps: TTimeCaps; // WinAPI.MMSystem;
3.   rc: MMResult;
4.  
5. begin
6.  
7.   rc := timeGetDevCaps(@TCaps, SizeOf(TCaps)); // WinAPI.MMSystem;
8.   if rc = 0
9.    then Writeln(Format('Min %d / Max %d', [TCaps.wPeriodMin, TCaps.wPeriodMax]))
10.     else Writeln(Format('timeGetDevCaps returned %d', [rc]));
11.  
12.   TimeBeginPeriod(1);
13.  
14.   rc := timeGetDevCaps(@TCaps, SizeOf(TCaps)); // WinAPI.MMSystem;
15.   if rc = 0
16.    then Writeln(Format('Min %d / Max %d', [TCaps.wPeriodMin, TCaps.wPeriodMax]))
17.     else Writeln(Format('timeGetDevCaps returned %d', [rc]));

Min 1 / Max 1000000
Min 1 / Max 1000000

[SymbolicFrank]

Yes, that clockres program and the powercfg report are very interesting. And it nicely explains why it is so inconsistent:

- It depends on which application has set the lowest timer.
- It is rounded up or down from the last timer tick.
- Some Windows versions try to emulate a slower timer by waiting approximately 15.6 ms by skipping interrupts. That also means that they're not running in sync.
- Some Linuxes use a free running scheduler, which impacts VM's.

In short: it depends. Don't count on it taking a specific time.


Btw. The only good way to measure time in such cases is by using the functions that return the current CPU cycle count. Or an external RTC.

On second thought: the CPU cycle count depends on the power saving, so an external clock source is the only reliable way.