Recent

Author Topic: cannot receive messages; udp server with lnet  (Read 6850 times)

Warfley

  • Hero Member
  • *****
  • Posts: 923
Re: cannot receive messages; udp server with lnet
« Reply #210 on: July 14, 2022, 12:55:23 pm »
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

  • Hero Member
  • *****
  • Posts: 4949
Re: cannot receive messages; udp server with lnet
« Reply #211 on: July 14, 2022, 01:01:39 pm »
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

  • Hero Member
  • *****
  • Posts: 923
Re: cannot receive messages; udp server with lnet
« Reply #212 on: July 14, 2022, 01:17:40 pm »
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

  • Hero Member
  • *****
  • Posts: 4569
  • Compiler Developer
Re: cannot receive messages; udp server with lnet
« Reply #213 on: July 14, 2022, 01:24:59 pm »
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

  • Hero Member
  • *****
  • Posts: 923
Re: cannot receive messages; udp server with lnet
« Reply #214 on: July 14, 2022, 01:58:50 pm »
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
« Last Edit: July 14, 2022, 02:04:34 pm by Warfley »

rvk

  • Hero Member
  • *****
  • Posts: 4949
Re: cannot receive messages; udp server with lnet
« Reply #215 on: July 14, 2022, 02:22:17 pm »
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]));

Quote
Min 1 / Max 1000000
Min 1 / Max 1000000


SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1086
Re: cannot receive messages; udp server with lnet
« Reply #216 on: July 18, 2022, 10:44:41 am »
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.
« Last Edit: July 18, 2022, 10:48:01 am by SymbolicFrank »

 

TinyPortal © 2005-2018