Re: Timer accuracy.

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Wed, 4 Jan 2006 15:32:03 -0000, "Mike Williams"
<Mike@xxxxxxxxxxxxxxxxx> wrote:

>"J French" <erewhon@xxxxxxxxxx> wrote in message
>news:43bba18d.9477587@xxxxxxxxxxxxxxxxxxxxxxx
>
>> This is what I used for measuring time, it uses the high
>> resolution timer and is more accurate than GetTickCount
>> Private Declare Function timeGetTime _
>> Lib "winmm.dll" () As Long
>
>You have to be a bit careful about the timeGetTime function Jerry. Under
>Win98 it defaults to a 1 millisecond resolution, but under Win XP it usually
>doesn't. On my XP system the default resolution of timeGetTime is somewhere
>between 15 and 16 milliseconds.

Mike, thanks a lot for the heads up on this

My main use of it has been for slowing down sending data to the RS232
provided by a USB on Win XP to a Zebra printer

If I did not slow things down so that I sent no more than 3 bytes in
2ms then I would get a buffer overflow on the printer, which I could
only put down to the CTS coming up too slowly

I found that GetTickCount made things run dog slow on Win 95 with a
real RS232 so I resorted to timeGetTime

It is probably working Ok on the XP machines because the system is in
a tight loop, is the foreground application with nothing else
(significant) running on the machine.

I'll need to look into this - thanks again


.

Relevant Pages

  • Re: Timer accuracy.
    ... Private Declare Function timeGetTime Lib "winmm.dll" As Long ... Private Declare Function GetTickCount Lib "kernel32" As Long ... they both have 15ms to 16 ms resolution. ...
    (microsoft.public.vb.general.discussion)
  • Re: Accurate time measurement
    ... "Multiple statements execute before either ... GetTickCount or timeGetTime record a change" and adding, ... increase the resolution of both GetTickCount and timeGetTime using ...
    (microsoft.public.vb.general.discussion)
  • Re: Constructing a more precise "Now()" and "DateDiff()"
    ... However, if you actually do want to use a "timestamp" and if the resolution of my own suggested method of using GetLocalTime is not sufficient for you then why not just record the actual time at the start of your program. ... Then every time you want to know the current time you simply use the timeGetTime function and deduct from its returned value the initial value that you got from timeGetTime at the start of your program. ... The resolution of timeGetTime is one millisecond. ... if the one millisecond resolution of timeGetTime is still not sufficient for your purposes you can instead use QueryPerformanceCounter in a similar way. ...
    (microsoft.public.vb.general.discussion)
  • Re: GetTickCount()/timeGetTime across processes
    ... >> timeGetTime() is not a global value. ... Millisecond resolution is good enough for my purpose and it's ... Yes -- that's why I'm using timeGetTimeafter calling timeBeginPeriod() to ... One possible explanation for the discrepancy between the tick count returned ...
    (microsoft.public.win32.programmer.kernel)
  • Re: GetTickCount()/timeGetTime across processes
    ... >> often precedes the time logged by the client process. ... >> timeGetTime() is not a global value. ... Millisecond resolution is good enough for my purpose and it's ... Yes -- that's why I'm using timeGetTimeafter calling timeBeginPeriod() to ...
    (microsoft.public.win32.programmer.kernel)