Re: Bad sleep time resolution of nanosleep(2)
On Tue, Nov 24, 2015 at 01:58:15AM +0100, Rhialto wrote: > > > > 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. The extra tick is added to ensure that the minumum sleep time is met. Otherwise the sleep will be too short if called just before s tick. David -- David Laight: da...@l8s.co.uk
Re: Bad sleep time resolution of nanosleep(2)
On Tue 24 Nov 2015 at 06:54:09 +, Michael van Elst wrote: > N.B. nanosleep shouldn't be based on ticks. I agree. I found that I get much better precision if I simply subtract 1/HZ seconds from the time I want to sleep, since that always gets added in practice. But user programs should not need to do that (not need to find out the value of HZ). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Bad sleep time resolution of nanosleep(2)
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: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Bad sleep time resolution of nanosleep(2)
rhia...@falu.nl (Rhialto) writes: >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. tick - some nanoseconds later - you wake up - you sleep for at least one tick tick - not enough yet because the first interval was a few nanoseconds too short tick - some nanoseconds or microseconds later - you wake up ... N.B. nanosleep shouldn't be based on ticks. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Bad sleep time resolution of nanosleep(2)
rhia...@falu.nl (Rhialto) writes: >For the standard HZ=3D100, one would expect the worst resolution to be >1000/100 =3D 10 ms. The resolution is 10ms, but since it waits for at least 10ms this can only happen when the current tick interval is expiring in the same moment. A loop waiting for the 'next tick' will always wait for (almost) two ticks because the first interval has already started when you wake up from the previous loop. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Bad sleep time resolution of nanosleep(2)
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. > Joerg -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Bad sleep time resolution of nanosleep(2)
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? Joerg
