clock_gettime() returns about 1-2ms inaccuracy every 50-100ms (Debian wheezy on Virtualbox)

Question

I had a closely related thread a while ago here.

However, replacing cin.ignore() with usleep(50e3). It does not report exactly every 50ms. The clock reports

Time Passed:    s: 0 ms: 50
Time Passed:    s: 0 ms: 101
Time Passed:    s: 0 ms: 152
Time Passed:    s: 0 ms: 202
Time Passed:    s: 0 ms: 252
Time Passed:    s: 0 ms: 303
Time Passed:    s: 0 ms: 353
Time Passed:    s: 0 ms: 403
Time Passed:    s: 0 ms: 454
Time Passed:    s: 0 ms: 504
Time Passed:    s: 0 ms: 554
Time Passed:    s: 0 ms: 605
Time Passed:    s: 0 ms: 657
Time Passed:    s: 0 ms: 708
Time Passed:    s: 0 ms: 758
Time Passed:    s: 0 ms: 808
Time Passed:    s: 0 ms: 862
Time Passed:    s: 0 ms: 915
Time Passed:    s: 0 ms: 965
Time Passed:    s: 1 ms: 15
Time Passed:    s: 1 ms: 66
Time Passed:    s: 1 ms: 116
Time Passed:    s: 1 ms: 169
Time Passed:    s: 1 ms: 221
Time Passed:    s: 1 ms: 271
Time Passed:    s: 1 ms: 322
Time Passed:    s: 1 ms: 372
Time Passed:    s: 1 ms: 423
Time Passed:    s: 1 ms: 473
Time Passed:    s: 1 ms: 524
Time Passed:    s: 1 ms: 574
Time Passed:    s: 1 ms: 625
Time Passed:    s: 1 ms: 676
Time Passed:    s: 1 ms: 727
Time Passed:    s: 1 ms: 778
Time Passed:    s: 1 ms: 833
Time Passed:    s: 1 ms: 883
Time Passed:    s: 1 ms: 935
Time Passed:    s: 1 ms: 986
Time Passed:    s: 2 ms: 37
Time Passed:    s: 2 ms: 91
Time Passed:    s: 2 ms: 142
Time Passed:    s: 2 ms: 192
Time Passed:    s: 2 ms: 243
Time Passed:    s: 2 ms: 294
Time Passed:    s: 2 ms: 346
Time Passed:    s: 2 ms: 396
Time Passed:    s: 2 ms: 450
Time Passed:    s: 2 ms: 501
Time Passed:    s: 2 ms: 552
Time Passed:    s: 2 ms: 602
Time Passed:    s: 2 ms: 652
Time Passed:    s: 2 ms: 703
Time Passed:    s: 2 ms: 753
Time Passed:    s: 2 ms: 804
Time Passed:    s: 2 ms: 855
Time Passed:    s: 2 ms: 906
Time Passed:    s: 2 ms: 956
Time Passed:    s: 3 ms: 7
Time Passed:    s: 3 ms: 57
Time Passed:    s: 3 ms: 107
Time Passed:    s: 3 ms: 158
Time Passed:    s: 3 ms: 208
Time Passed:    s: 3 ms: 258
Time Passed:    s: 3 ms: 315
Time Passed:    s: 3 ms: 365
Time Passed:    s: 3 ms: 416
Time Passed:    s: 3 ms: 466
Time Passed:    s: 3 ms: 517
Time Passed:    s: 3 ms: 567
Time Passed:    s: 3 ms: 618
Time Passed:    s: 3 ms: 668
Time Passed:    s: 3 ms: 719
Time Passed:    s: 3 ms: 769
Time Passed:    s: 3 ms: 824
Time Passed:    s: 3 ms: 875
Time Passed:    s: 3 ms: 926
Time Passed:    s: 3 ms: 976
Time Passed:    s: 4 ms: 27
Time Passed:    s: 4 ms: 79
Time Passed:    s: 4 ms: 129
Time Passed:    s: 4 ms: 182
Time Passed:    s: 4 ms: 233
Time Passed:    s: 4 ms: 283
Time Passed:    s: 4 ms: 334
Time Passed:    s: 4 ms: 384
Time Passed:    s: 4 ms: 436
Time Passed:    s: 4 ms: 486
Time Passed:    s: 4 ms: 537
Time Passed:    s: 4 ms: 587
Time Passed:    s: 4 ms: 638
Time Passed:    s: 4 ms: 688
Time Passed:    s: 4 ms: 739
Time Passed:    s: 4 ms: 789
Time Passed:    s: 4 ms: 844
Time Passed:    s: 4 ms: 895
Time Passed:    s: 4 ms: 946
Time Passed:    s: 4 ms: 997
Time Passed:    s: 5 ms: 47
Time Passed:    s: 5 ms: 101
Time Passed:    s: 5 ms: 151
Time Passed:    s: 5 ms: 202
Time Passed:    s: 5 ms: 252
Time Passed:    s: 5 ms: 303
Time Passed:    s: 5 ms: 354
Time Passed:    s: 5 ms: 404
Time Passed:    s: 5 ms: 455

As you can see(sorry but perhaps a long output, but just in case), there is consistent inaccuracy present.

Why is this so, what affects it and how could it be fixed?

Answer 1

Digital ticks have an inherent quantification inaccuracy (as is in any DAC/ADC) which means that for the ticks of 1 ms duration your inaccuracy can range from "almost 0" to "almost 1 ms".

There's a perfect picture illustration from an MSDN article on timing:

(yes, sometimes MSDN actually has useful and insightful articles) with this text:

"If a hardware generator provides ticks at a constant rate, time intervals can be measured by simply counting these ticks. The rate at which the ticks are generated is called the frequency and expressed in Hertz (Hz). The reciprocal of the frequency is called the period or tick interval and is expressed in an appropriate International System of Units (SI) time unit (for example, second, millisecond, microsecond, or nanosecond). Time interval The resolution of the timer is equal to the period. Resolution determines the ability to distinguish between any two time stamps and places a lower bound on the smallest time intervals that can be measured. This is sometimes called the tick resolution. Digital measurement of time introduces a measurements uncertainty of ± 1 tick because the digital counter advances in discrete steps, while time is continuously advancing. This uncertainty is called a quantization error. For typical time-interval measurements, this effect can often be ignored because the quantizing error is much smaller than the time interval being measured."

Answer 2

This is due to how sleep work, even in Real Time OSes.

Basically, when you ask "sleep for X amount of time", you don t ask "Wake me up in X time" but "Don t call me before X time". That s why time dependent programming is so difficult and also why video game programming use frame instead of ms for example.

Chances are, if your system isn t overloaded and don t run for a too long time, that this inaccuracy don t add up enought to be troublesome, if it is, you ll need another way to check the time (maybe Universal Time? But you ll be dependent on network).

Answer 3

When your process goes to sleep by calling a sleep function, the system scheduler postpones waking it up until the requested time spends. After that it may wakes up the process or it may takes longer time.

The usleep() function will cause the calling thread to be suspended from execution until either the number of real-time microseconds specified by the argument useconds has elapsed or a signal is delivered to the calling thread and its action is to invoke a signal-catching function or to terminate the process. The suspension time may be longer than requested due to the scheduling of other activity by the system.

Many OSs don't guarantee that they will wake up processes right after the sleep time finishes.