Usleep() and QTimer resolution in Linux

[QtDimi]

A small question regarding timing issues in Qt.

I'm running a custom linux kernel (Preemptible Kernel) with a Qt application on embedded device.

I just tested these lines of code:

@
elapsedTimer.start();
usleep(100*1000);
qDebug() << "SLEEP: " << elapsedTimer.elapsed() << " ms.";
@

Output:
@
SLEEP: 109 ms.
SLEEP: 109 ms.
SLEEP: 109 ms.
SLEEP: 110 ms.
SLEEP: 109 ms.
@

But when I use a QTimer connected with a slot and timeout of 100ms I get the following output:

@
void MainWindow::printInfo()
{
qDebug() << "SLEEP: " << elapsedTimer.elapsed() << " ms.";
elapsedTimer.start();
}
@

@
SLEEP: 99 ms.
SLEEP: 99 ms.
SLEEP: 100 ms.
SLEEP: 99 ms.
SLEEP: 99 ms.
SLEEP: 99 ms.
SLEEP: 99 ms.
@

Resolution seems to be 1ms in both cases and is good enough, but using usleep takes nearly 10% extra time. So what is causing this?

Is this because usleep() is the MINIMUM amount of time the application sleeps? And QTimer tries to use exact timing?

Thanks

[sierdzio]

Can you try running the same example on a "standard" kernel on a PC? Is the difference the same there?

You would need to check the source code of QTimer and usleep, but I guess it's about context switching/ thread scheduling.

[QtDimi]

Just tested on laptop with Ubuntu and stock kernel.

The difference is non-existent it seems in this configuration:

usleep()

@SLEEP: 100 ms.
SLEEP: 102 ms.
SLEEP: 100 ms.
SLEEP: 104 ms. @

QTimer

@SLEEP: 99 ms.
SLEEP: 99 ms.
SLEEP: 99 ms.
SLEEP: 100 ms.
SLEEP: 100 ms.
SLEEP: 99 ms. @

[sierdzio]

Now it looks even more like a context switch issue :)

My guess: when using QTimer, your thread is always active, so it fires on time. When usleeping, once the given time passes, the thread needs to wake up, which takes additional time.