Delay-Wait-Sleep tricks.

[penpen]

It is probably because of the PCI bus in its specification PCI 2.1:
There the specified clock speed is 66,66... MHz, so one cycle is is exact 15 ms.
Because of power input variations, and temperature differences, this value is
may differ by +-1 ms.

penpen

Edit: NO i was wrong see posts below.
Edit2: Nevertheless the last sentence is true.

[einstein1969]

seem 15,625 ms = 64Mhz

There is this clock in specific of PC?

I used this to discovery/confirm

Code: Select all

@echo off & setlocal EnableDelayedExpansion

cls

rem sync to 00 or 01

:loopm100
if "%time:~-2%" neq "00" if "%time:~-2%" neq "01" goto :loopm100
echo %time%
echo(

set old_last_digit=
set my_ms=0
for /L %%i in (1,1,10000000) do (

 set t=!time!
 set last_digit=!t:~-1!

 rem check if last digit is changed.
 if not "!old_last_digit!"=="!last_digit!" (
  set old_last_digit=!last_digit!
  
  rem check and correct
  set ms=9!t:~-2!0000
  set /a "diff=ms-(9000000+my_ms)"

  echo [%%i] !t! !ms! !my_ms! !diff!
  if !my_ms! gtr 9000000 pause

  set /a my_ms+=15625

  if !diff! geq 0 set /a my_ms+=diff

 )

)

on windows 7 32 bit

einstein1969

[penpen]

With "probably" i didn't mean: It could be that the clock cycle depends on PCI (2.1).
It should mean:
It has to do with the PCI 2.1 specification.
I just don't know if nowadays the clock is located behind a PCI (2.1), or
if it is simulated by Windows, using the High Performance Counter of the processor.

And if your measure differs, then this could possibly depend on:
Wrong voltage inputs from your power supply (for example: +12,1 -11,9 +4.9 ...), or
the clock chip doesn't meet the exact temperature of 20°C (for example: 24°C).

penpen

Edit: NO i was wrong it hasn't todo with the PCI (2.1), but the last block is true.

[einstein1969]

Hi,

can sameone test this script?

should detect the real interval timer inside of dos. It is not perfect and should be revised and improved. Once detected the interval can be used for a more accurate calculation of the time returned by the variable %TIME%.

Run it several times to get a more accurate value and if possible on different machine/SO.

thanks.

Code: Select all

@echo off & setlocal EnableDelayedExpansion

rem goto :predict

for /f %%a in ('copy /Z "%~f0" nul') do set "CR=%%a"

rem for discovery internal dos timer interval/resolution:

rem sync to 00 or 01
cls
echo(
echo Syncing to 00 or 01 cs ...
:loop
if "%time:~-2%" neq "00" if "%time:~-2%" neq "01" goto :loop
echo(
echo Starting at %time%
echo(

rem using microsecond resolution (0.000001 seconds)
set /a err=0, res=10000


set ot=!time:~-2!
set /a my_t=(1!ot!-100)*10000

rem echo !time!0000 !time:~0,-2!!my_t! !ot!
rem echo(

set /a iter=1000

echo(*=centiseconds  **=Resolution/Interval in microseconds
echo(
Echo(Iter   %%TIME%%      Calculated   diff*   R/I**   errors
echo(

:next
set /a err=0, iter+=1000

For /L %%i in (1,1,%iter%) do (

   rem take new time and check if changed.
   set t=!time!
   if not "!t:~-2!" == "!ot!" (
      
      rem save new time
      set ot=!t:~-2!

      rem check error
      set /a "my_t=(my_t+res) %% 1000000, diff=(1!ot!-100)-(my_t/10000)"

      if !diff! geq 0 (if !diff! gtr 0 set /a res+=err/2) else set /a res-=err/2

      if !diff! neq 0 set /a err+=1

      rem adjust offset
      if !diff! gtr 0 set /a "my_t=my_t+( (1!ot!-100)*10000-my_t )"

      if %iter% gtr 1000 (
         <nul set /p "=[%%i]   !t!0000 !t:~0,-2!!my_t!   !diff!   !res!   !err!   !CR!"
      ) else (
         echo [%%i]   !t!0000 !t:~0,-2!!my_t!  !diff!   !res! !err!
      )
      
   )

)

if !err! neq 0 goto :next

goto :eof

result:

Code: Select all

Syncing to 00 or 01 cs ...

Starting at 18:54:15,00

*=centiseconds  **=Resolution/Interval in microseconds

Iter    %TIME%          Calculated      diff*   R/I**   errors

[22891] 18:54:53,210000 18:54:53,219933 0       15627   0

einstein1969

[foxidrive]

It never stops - the iterations figures goes up and then starts again.

[einstein1969]

It never stops - the iterations figures goes up and then starts again.

ok. I need to rewrite the algorithm. It's seem that on load the algorithm is not efficient.

I think I have framed the problem, if someone wants to try to give a solution...

I assumed that the variable %TIME% is charged by taking the values ​​from a subsystem with millisecond precision or micro. I assumed that there are no rounding.

I verified with a jscript through the function "getTime ()" that has millisecond precision and which has the same resolution of 15-16 milliseconds.

The problem is to find the frequency or period of the oscillator / clock which is the basis. You may also need to find the phase of the same.

It 'a problem in two variables.

For the frequency / period we have some values ​​truncated to the hundredth of a second that are in the variable %TIME%

If the system is under load these values ​​can jump higher. Then serves interpolation.

To find the frequency you could implement an algorithm that exploits the Doppler effect. Is like tuning a musical instrument. (dbenham help!)

einstein1969

[einstein1969]

With "probably" i didn't mean: It could be that the clock cycle depends on PCI (2.1).
It should mean:
It has to do with the PCI 2.1 specification.
I just don't know if nowadays the clock is located behind a PCI (2.1), or
if it is simulated by Windows, using the High Performance Counter of the processor.

And if your measure differs, then this could possibly depend on:
Wrong voltage inputs from your power supply (for example: +12,1 -11,9 +4.9 ...), or
the clock chip doesn't meet the exact temperature of 20°C (for example: 24°C).

penpen

Thanks for your comments.

I have found a document that confirm my guess of 64MHz. This document talk about of 15.6 millisecond (i suppose 15.625). But talk that an application my change this interval. And talk about of AFFINITY for multicore system.

http://download.microsoft.com/download/3/0/2/3027D574-C433-412A-A8B6-5E0A75D5B237/Timer-Resolution.docx

EDIT: The frequency is 64 Hz and not 64 MHZ. Sorry.

einstein1969

[dbenham]

Another article that may prove useful: http://msdn.microsoft.com/en-us/magazine/cc163996.aspx


Dave Benham

[einstein1969]

Another article that may prove useful: http://msdn.microsoft.com/en-us/magazine/cc163996.aspx


Dave Benham

thanks. This article is interesting and it made me discover this tools

http://technet.microsoft.com/en-us/sysinternals/bb897568.aspx

can be used for confirm.

Code: Select all

C:\Users\fra\Desktop\tmp>Clockres.exe

ClockRes v2.0 - View the system clock resolution
Copyright (C) 2009 Mark Russinovich
SysInternals - www.sysinternals.com

Maximum timer interval: 15.625 ms
Minimum timer interval: 0.500 ms
Current timer interval: 15.625 ms

C:\Users\fra\Desktop\tmp>

but i want implement a batch pure solution !

einstein1969

[penpen]

I thought these results are curious, so i've looked up in my (old) papers:
First to say: Sorry. (I was so sure that i was right... .)

You are right, that i remembered (completely) wrong:
The High Performance Counter (processor time measured within the CPU) can be accesses via PCI 2.1,
so what i've said above (66,66 MHz) is the maximum timing with that the High Performance Counter could be accessed, but that doesn't mean the measurement is such good (100 ns, or 10 kHz is maximum supported by windows structs).

The real cause of this 64 Hz has to do with the real-time clock located in the CMOS chip:
The industry standard of accessing the CMOS was 32768 Hz.
This was repeatedly halfed to access a time signal of 1 Hz.

(Since some unknown time, sry it is not included in my script) this resolution could be changed
(by mutiples of two, later other mutliples possible, the interrupted time counter then do mutiple partial ticks before one full tick with setting up a new time).

The 64 Hz were used in 386, so for compatability reasons they left the recommended time tick to 15.625.

(My script has no list of references, so i could not give them, although i wished i could in this case.)

penpen

[einstein1969]

is possibile to access the timer resolution without external tools :

Code: Select all

powercfg -energy -xml duration 1

and (i have not created a script at the moment)

Code: Select all

type energy-report.xml | findstr /N "e5ba7e97-57dd-4378-a022-0b5b3fff3d22"
69

for /F "skip=69" %%f in (energy-report.xml) do @echo %%f
<Name>Risoluzione
<Value>156250</Value>

This work on windows 7 32bit

einstein1969

[AiroNG]

on topic:
I think the idea of carlsomo back on the first page of this thread might be a good idea.
He said "it uses much cpu" but I'm sure there are some nice tricks
to reduce the cpu usage (along the lines of this).


off topic:

Mod Edit: I removed the off topic posts.

[einstein1969]

Hi, I have probed the pathping command.

This may resolve the ping problem with low time wait/delay/sleep. On windows 7 this work well

Example:

delay 50ms:

Code: Select all

pathping 127.0.0.1 -n -q 1 -p 50

einstein1969

[einstein1969]

Hi, I add a recent discovery for nice HEARTBEAT in dos batch

This is good for multithreading batch and other application and It help to reduce cpu in polling cicles.

the code for command line:

Code: Select all

( for /L %n in (0) do @ping -n 2 127.0.0.1 >nul & start "PING" /B ping 127.0.0.1 -n 25 ) | FIND "128" | cmd /v:on /c" for /l %n in (0) do @(set/p "L=" & if "!L:~-3!"=="128" ( set /a t=1!time:~6,2!!time:~9,2!-10000, dt=t-oldt, dt+=(dt^>^>31^)^&6000 >NUL & if !dt! geq 20 set/p ".=!dt! "<nul & set /a oldt=t >NUL ) ) "

this code output at specified interval the number of centisec from last output. Wait few seconds for stabilize 30-60 sec

You can change the interval in the piece of code that is:

Code: Select all

if !dt! geq 20 

the 20 is 20centiseconds or 200milliseconds. This will output at frequency of 1000/200 = 5 at second.

You can change the value.

Onother value that is possible change for tuning is the number 25 in the code:

Code: Select all

start "PING" /B ping 127.0.0.1 -n 25

The number is good for the most. But if you have a very faster pc you can increase at 30 or 35 or until the output is more precise. If the output has a delay big you can try to increase for probe to decrease and have the average requested.

What happen if this is too low?

Example: Use a delay of 200 ms or 20 cs. And use a value for ping of 15
output:

23 20 47 22 22 59 20 22 63 22 22 62 21 22

the delay is not omogeneus.

Trying a value for ping -n 20
output:

26 21 33 20 20 25 39 21 22 21 45 21 21 23 44 26 21

a little better but not enough

Trying a value for ping -n 25
output:

20 23 21 25 21 21 23 23 23 20 24 21 25 22 20 23 22 20 24 24 22 24 21 21

this is accetable!

But try to keep it as low as possible because it uses a lot of resources the pc (if exaggerated)

einstein1969

[Squashman]

But try to keep it as low as possible because it uses a lot of resources the pc (if exaggerated)

Wasn't the original purpose of this thread to not use a lot of resources. I remember getting yelled at for my contribution.