# Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

# General questions on waiting.

#### vefatica

I'm working on an experimental WAIT which allows a float/units spec for the duration (e.g, WAIT 1.5H) or a datetime for the expiration (e.g., WAIT 20110327000000 [until midnight]).

In the first format (like DELAY) I can get results exactly like DELAY gets only if I compensate for the fact that Sleep(1) will actually give anything from 1 to 15.625 mlliseconds. I do that like this.

Code:
``````ullDue = ullNow + (ULONGLONG) number;
if ( !global.bHiResTime )
ullDue -= ((dwAdjust + 10000) / 20000);
WaitUntilTickCountOrFileTime(ullDue, bUseFileTime);``````
That is, by decreasing the due tick count by half the period of a clock tick.

With that correction, here's a comparison of how "DELAY 1" and "WAIT 1s" compare (in milliseconds, DELAY on the left, WAIT on the right):

Code:
``````999.205         999.187
999.217         999.182
999.251         999.181
999.204         999.148
999.217         999.195
999.213         999.199
999.237         999.211
999.382         999.186
999.169         999.200
999.230         999.125
999.176         999.206
999.219         999.152
999.209         999.247
999.191         999.262
999.093         999.194
999.275         999.202
999.243         999.152
999.198         999.171
999.220         999.201
999.245         999.171``````
Are you somehow (and how) taking the granularity of Sleep() into consideration?

I also have an experimntal plugin HIRESTIME (ON/OFF). HIRESTIME ON (timeBeginPeriod/maxres) should make Sleep() behave better. Here's the comparison between "DELAY 1" and "WAIT 1s" after HIRESTIME ON: (again, "DELAY1" on the left). The numbers for DELAY are pretty much as before but with a few outliers. The numbers for WAIT are higher (better?, I'd actually expect slightly over 1000ms) but also with outliers just like DELAY.

Code:
``````999.213         1000.141
999.257         1000.135
999.279         1000.151
999.176         1000.139
992.411         1000.169
999.216         1000.169
1000.161        1000.172
999.212         1002.143
999.247         1002.174
988.434         1002.061
999.218         1002.084
999.263         1002.082
999.274         1000.182
999.165         1000.192
988.442         1000.186
999.249         1000.117
999.179         1000.145
999.253         1000.141
999.212         1000.143
999.267         1000.153``````
There doesn't seem to be much (if any) advantage in trying to make delaying and timing more precise by using hi-res MM timing.

Thanks.

Are you somehow (and how) taking the granularity of Sleep() into consideration?

No; I have no interest in in that level of resolution. (Which will be irrelevant anyway as soon as you throw a few acive background processes into the mix.)

What are you doing that you require such
high precision delays in a Windows environment?

Does it really matter that you have
a +/- 55 milisecond granularity?

-Scott

vefatica <> wrote on 03/26/2011
10:48:20 PM:

> There doesn't seem to be much (if any) advantage in trying to make

> delaying and timing more precise by using hi-res MM timing.
>
>
> Thanks.
>
>
>
>

When I was using millisecond delays, I was simulating legacy disk drives and it was completely unacceptable to have delays that varied that much. We used the mm system to change the timing to millisecond accuracy.

Jim Cook

On Mar 28, 2011, at 9:05, samintz <> wrote:

> What are you doing that you require such
> high precision delays in a Windows environment?
>
> Does it really matter that you have
> a +/- 55 milisecond granularity?
>
> -Scott
>
>
> vefatica <> wrote on 03/26/2011
> 10:48:20 PM:
>
>
>
> ---Quote---
>> There doesn't seem to be much (if any) advantage in trying to make
> ---End Quote---
>
>
> ---Quote---
>> delaying and timing more precise by using hi-res MM timing.
>>
>>
>> Thanks.
>>
>>
>>
>>
> ---End Quote---
>
>
>

On Mon, 28 Mar 2011 12:05:27 -0400, you wrote:

|What are you doing that you require such
|high precision delays in a Windows environment?
|
|Does it really matter that you have
|a +/- 55 milisecond granularity?

Possibly, to some. And, it's a challenge.

On Mon, 28 Mar 2011 12:45:28 -0400, you wrote:

|When I was using millisecond delays, I was simulating legacy disk drives and it was completely unacceptable to have delays that varied that much. We used the mm system to change the timing to millisecond accuracy.

In pretty good tests like (paraphrasing)

Get the perf count
Delay_cmd(L"1") [or my experimental "WAIT 1s"]
print the elapsed time

Both DELAY and WAIT are extremely **consistent**, both nearly always giving
.9997 ms. That's without MM timing! I'm surprised since I'm looping around
Sleep(1) (which here should give anything between 1 and 15.625 ms). I don't
know what DELAY is doing, but I figure there must be a Sleep() in there too.

When I introduce MM timing (timeBeginPeriod(1)) the results get erratic.

I didn't say there wasn't a need for high-res
timing. The MM timers exist precisely because there is a need. I
just wondered what a plugin in TCC would need with them. Especially one
that is doing what Delay is doing.

-Scott

Jim Cook <> wrote on 03/28/2011
12:45:27 PM:

>
> When I was using millisecond delays, I was simulating legacy disk

> drives and it was completely unacceptable to have delays that varied
> that much. We used the mm system to change the timing to millisecondaccuracy.

>