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)
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)
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)
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
Bad sleep time resolution of nanosleep(2)
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.
For the standard HZ=100, one would expect the worst resolution to be
1000/100 = 10 ms.
As an experiment, I built a kernel with "options HZ=1000" for NetBSD 7,
and even there a 1 ms sleep still takes 2 ms. For other times, the
actual time seems systematically 1 ms too long.
This seems to indicate that the actual time is rounded up to whole ticks
and then another whole tick is added. I'd expect the former, but not the
latter; this seems rather unnecessarily inaccurate.
I have measured times in us (microseconds) using the following program,
which is derived from the simh sources.
#include
#include
#include
#include
#define NANOS_PER_MILLI 100
#define MILLIS_PER_SEC 1000
#define sleep1Samples 100
uint64_t sim_os_usec (void)
{
struct timeval cur;
gettimeofday (, NULL);
return cur.tv_sec * 100L + cur.tv_usec;
}
/* returns the time actually slept in microseconds */
uint32_t sim_os_ms_sleep (unsigned int milliseconds)
{
uint64_t stime = sim_os_usec ();
struct timespec treq;
treq.tv_sec = milliseconds / MILLIS_PER_SEC;
treq.tv_nsec = (milliseconds % MILLIS_PER_SEC) * NANOS_PER_MILLI;
(void) nanosleep (, NULL);
return sim_os_usec () - stime;
}
void sim_os_ms_sleep_init (int milliseconds)
{
uint32_t i, tot, tim;
uint64_t t1, t2;
sim_os_ms_sleep (1); /* Start sampling on a tick boundary
*/
for (i = 0, tot = 0; i < sleep1Samples; i++) {
t1 = sim_os_usec ();
sim_os_ms_sleep (milliseconds);
t2 = sim_os_usec ();
tot += (t2 - t1);
}
tim = (tot + (sleep1Samples - 1)) / sleep1Samples;
printf("precision of %d ms sleep: %d microsec (should be %d microsec)\n",
milliseconds, tim, milliseconds * 1000);
}
int main(int argc, char **argv)
{
int ms = 1;
if (argc > 1) {
ms = atoi(argv[1]);
}
sim_os_ms_sleep_init(ms);
return 0;
}
-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 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 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
