On 2015-11-24 01:58, Rhialto wrote:
On Tue 24 Nov 2015 at 00:41:42 +0100, Joerg Sonnenberger wrote:On Tue, Nov 24, 2015 at 12:25:45AM +0100, Rhialto wrote:In the context of the machine simulator simh, which needs some accurate timing now and then, I have come across an example of rather bad time resolution of the nanosleep() system call. The minimal sleep time seems to be 20 ms, even if you ask for just 1 ms delay. If you ask for longer sleeps, the discrepancy becomes relatively less but remains substantial: 20 ms becomes 30 ms, and 40 ms becomes 50.Well, it is rounded up first to whole ticks, that's the easy part. Next the callout is scheduled at the tick boundary and then the LWP is unblocked and scheduled again. It will run in the next scheduling cycle unless nothing else is running?I tried it on some fairly idle machines, and the result was quite consistent. It really looks like there is something in there that inadvertently always causes an extra tick delay.
Are you sure it's not just a case of the (re)scheduling only happening at the next clock tick after the timer runs out?
We do not have a real time system here. sleeps only guarantee a minimum time. There is no upper bound to how long it will sleep.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol