In testing Dostime in OI i find an oddity that I hope all the really smart people on the list can help me with .. of course abuse is also welcomed ..

The following test code ..

subroutine foo(a)

string="

for pntr=1 to 10000

call dostime(x)

string := @fm : x

next pntr

debug

return

When this is completed i get data like

:52557.9370

:52557.9370

:52557.9370

…

:52557.9530

:52557.9530

:52557.9530

…

:52557.9680

:52557.9680

:52557.9680

…

:52557:9840

:52557:9840

:52557:9840

…

:52558.00

:52558.00

:52558.00

etc etc etc

So my question is .. why the great gaps. I realize that the for/next loop is happening very fast .. but shouldn't that make it less likely to see skips in the numbers?

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Phone: 971-570-2005

OS: Win2k sp2 (5.00.2195)

OI: 4.1.2

I know that DOS updates the timer every 18.2 times a second. And I am sure that you are calling that subroutine more than 18.2 times a second.

So… that would account for the DOS time being the same for several calls in a row, and then the jump in the time (decimal portion) of the DOS time.

I also believe it is how many seconds past midnight.

I believe it is because you are on Windows Time!

Here is the (updated) relevant online documentation at MSDN:

Windows Time

This says that on the latest versions of NT, the system timer runs at approximately 10ms. That is all the resolution you are going to get with the standard time related functions. This page also has some links to other pages if a higher resolution is needed.

Pat

pat,

thanks for the quick response and further reading ..

and if your eyes are rolling up in your head go ahead and just close this out .. i ask why a lot and my wife just tells me to accept ..

BUT ..

but if OI DosTime is running off windows and windows is only doing 10 ms (milliseconds) then I would *think* (stop laughing) that the increments would still be consistant and show all increments of 10ms.

So here are the first 5 changes ..

:52557.9370

:52557.9530

:52557.9680

:52557:9840

:52558.00

from 9370 to 9530 is .016

from 9530 to 9680 is .015

from 9680 to 9840 is .016

from 9840 to .00 is .016

So the odd one .015 was probably just on the cusp ..

If OI is going through this tight loop .. shouldn't it see the change every 10 ms? Shouldn't it have been 9530, 9540 9550 …

any way .. thanks sorry to bug ya

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Phone: 971-570-2005

OS: Win2k sp2 (5.00.2195)

OI: 4.1.2

Richard,

thanks for the response .. I can understand why I would see so many in the same second .. OI is blindingly fast BUT then shouldn't the increment be a little more granular that .016 as it *seems* to be from the first 5/6 changes.

I know this is not a big deal .. just like to understand why .. why .. why ..

BUT in just testing against Arev .. it jumped from nnnnn.61 to nnnnn.66 so what the heck .. as long as it is *similar* I guess I can live with it

thanks again

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Phone: 971-570-2005

OS: Win2k sp2 (5.00.2195)

OI: 4.1.2

Well, this is the exact wording of MS'es documentation:

Windows NT 3.5 and later: The system timer runs at approximately 10ms.

Windows NT 3.1: The system timer runs at approximately 16ms.

Windows 95/98/Me: The system timer runs at approximately 55ms.

Note the word "approximately"…

However, your results are pretty close to the claimed resolution under Windows NT 3.1.

What is the problem you are trying to solve?

Pat

View this thread on the forum...