setTimeout drifts after busy wait

[bjouhier]

if you call setTimeout after a busy wait the delay can be much longer than expected.

I created a gist: https://gist.github.com/bjouhier/c7adb5f54caf9fc86d6e

OSX 10.9.4, node 0.10.27

[micnic]

Win8, node 0.10.29:

busy:   expected 300, got 300
idle:   expected 100, got 114
busy:   expected 300, got 300
idle:   expected 100, got 104
busy:   expected 300, got 300
idle:   expected 100, got 113
busy:   expected 300, got 300
idle:   expected 100, got 104
DONE: 1650

[loyd]

Linux, node 0.10.30:

busy:   expected 300, got 300
idle:   expected 100, got 1
busy:   expected 300, got 300
idle:   expected 100, got 100
busy:   expected 300, got 300
idle:   expected 100, got 100
busy:   expected 300, got 300
idle:   expected 100, got 100
DONE: 1511

WIth v0.13.0-pre, the same as gist.

[bjouhier]

Upgraded to 0.10.29 on OSX, to compare with Win8. Same result as 0.10.27:

busy:   expected 300, got 300
idle:   expected 100, got 101
busy:   expected 300, got 300
idle:   expected 100, got 402 SURPRISE!!
busy:   expected 300, got 300
idle:   expected 100, got 400 SURPRISE!!
busy:   expected 300, got 300
idle:   expected 100, got 401 SURPRISE!!
DONE: 2518

[almike]

normal behavior if your cpu is busy.

chrome while cpu is busy:

busy:   expected 300, got 300 VM111:8
idle:   expected 100, got 293 SURPRISE!! VM111:16
busy:   expected 300, got 300 VM111:8
idle:   expected 100, got 699 SURPRISE!! VM111:16
busy:   expected 300, got 300 VM111:8
idle:   expected 100, got 700 SURPRISE!! VM111:16
busy:   expected 300, got 300 VM111:8
idle:   expected 100, got 700 SURPRISE!! VM111:16
DONE: 3593 

what is not normal is the first idle being below 100ms, either 0 or 1 on my computer.

ubuntu/10.30:

busy:   expected 300, got 300
idle:   expected 100, got 0
busy:   expected 300, got 300
idle:   expected 100, got 100
busy:   expected 300, got 300
idle:   expected 100, got 100
busy:   expected 300, got 300
idle:   expected 100, got 100
DONE: 1506

[bjouhier]

@almike
Problem is not the computer being busy. CPU is idle during the idleWait call. Yet it takes 400 ms instead of 100 ms.

Also I can control the drift precisely: if I change the busy wait to X ms, the abnormal idleWait calls take X + 100 ms. Results are reproducible with a few ms margin if the computer is idle otherwise.

[almike]

what happens if you run it for a longer time?

function combined(a) {
    busyWait(500, function() {
        idleWait(200,function(){
            a < 50 && combined(++a);
        });
    }); 
}
combined(0);

also not sure if that is normal:

console.log(Date.now());
setTimeout(function(){
    console.log(Date.now());
    setTimeout(function(){
        console.log(Date.now());
    },100);
},100);

gives:

1407491392450
1407491392513
1407491392614

the first timeout is 63ms but it should be equal or above 100

[bjouhier]

Result:

busy:   expected 500, got 500
idle:   expected 200, got 203
busy:   expected 500, got 500
idle:   expected 200, got 702 SURPRISE!!
busy:   expected 500, got 500
idle:   expected 200, got 701 SURPRISE!!
busy:   expected 500, got 500
idle:   expected 200, got 701 SURPRISE!!
busy:   expected 500, got 500
idle:   expected 200, got 701 SURPRISE!!
busy:   expected 500, got 500
...

[bjouhier]

Also, if I use process.nextTick(cb) instead of cb() to chain at the end of busyWait then the problem goes away.

[almike]

ah so your idle time is actually busy time + idle time on your computer.
maybe while it is looping date is not updated https://codereview.chromium.org/173793002

[trevnorris]

Can you update the test to use process.hrtime() for comparison with
Date.now()?

[bjouhier]

If date was not updated during busy loop idleWait would elapse earlier rather than later. This is the bug that we observe on Linux, in the first iteration. On OSX it looks like the first iteration is properly compensated but that the compensation is applied twice in the following iterations.

The Chromium link points to another problem, related to timezone offsets.

[bjouhier]

@trevnorris
I updated the gist to measure the elapsed times with process.hrtime(). I get the same results.

The problem does not seem to be with Date.now() but rather with setTimeout. If I use a long busyWait I can see that the second and subsequent idleTimeoutcalls take much longer than the first one.

[almike]

but later if it happens in the loop, I thought it could be some caching for optimization... but you are right I looked at that chromium diff the changes do not match the title.

[almike]

ok, tried with v0.10.26. still on ubuntu:

busy:   expected 300, got 300
idle:   expected 100, got 100
busy:   expected 300, got 300
idle:   expected 100, got 400 SURPRISE!!
busy:   expected 300, got 300
idle:   expected 100, got 400 SURPRISE!!
busy:   expected 300, got 300
...

seems ok @ v0.10.30, except for the first timeout which is triggered too fast.

[vkurchatkin]

My results:

0.10.28:

busy:   expected 300, got 300
idle:   expected 100, got 102
busy:   expected 300, got 300
idle:   expected 100, got 401 SURPRISE!!
busy:   expected 300, got 300
idle:   expected 100, got 401 SURPRISE!!
busy:   expected 300, got 300

0.10.30:

busy:   expected 300, got 300
idle:   expected 100, got 0
busy:   expected 300, got 300
idle:   expected 100, got 101
busy:   expected 300, got 300
idle:   expected 100, got 100

0.11.13

busy:   expected 300, got 300
idle:   expected 100, got 100
busy:   expected 300, got 300
idle:   expected 100, got 403 SURPRISE!!
busy:   expected 300, got 300
idle:   expected 100, got 402 SURPRISE!!
busy:   expected 300, got 300