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
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.NetBSD.org, a NetBSD/amd64 host, using sources from CVS date 2015.11.23.23.46.33. An extract from the build.sh output follows: --- dependall-sys --- /tmp/bracket/build/2015.11.23.23.46.33-i386/src/sys/dev/filemon/filemon.c: In function 'filemon_ioctl': /tmp/bracket/build/2015.11.23.23.46.33-i386/src/sys/dev/filemon/filemon.c:281:25: error: unused variable 'p' [-Werror=unused-variable] struct proc *tp, *lp, *p; ^ /tmp/bracket/build/2015.11.23.23.46.33-i386/src/sys/dev/filemon/filemon.c:281:20: error: unused variable 'lp' [-Werror=unused-variable] struct proc *tp, *lp, *p; ^ cc1: all warnings being treated as errors --- dependall-external --- --- dependall-bsd --- --- ippool_l.h --- --- dependall-sys --- *** [filemon.o] Error code 1 nbmake[8]: stopped in /tmp/bracket/build/2015.11.23.23.46.33-i386/src/sys/modules/filemon 1 error The following commits were made between the last successful build and the failed build: 2015.11.23.21.40.14 jdc src/sys/arch/sparc64/dev/schizo.c,v 1.34 2015.11.23.21.40.14 jdc src/sys/arch/sparc64/dev/schizoreg.h,v 1.11 2015.11.23.21.40.14 jdc src/sys/arch/sparc64/dev/schizovar.h,v 1.7 2015.11.23.22.20.57 pgoyette src/sys/dev/filemon/filemon.c,v 1.18 2015.11.23.22.34.00 christos src/usr.sbin/makemandb/apropos-utils.c,v 1.18 2015.11.23.22.35.28 christos src/lib/libterminfo/terminfo.3,v 1.13 2015.11.23.23.00.29 pgoyette src/share/man/man4/filemon.4,v 1.14 2015.11.23.23.23.25 pgoyette src/share/man/man7/sysctl.7,v 1.95 2015.11.23.23.27.38 pgoyette src/sys/dev/filemon/filemon.c,v 1.19 2015.11.23.23.28.33 pgoyette src/share/man/man4/filemon.4,v 1.15 2015.11.23.23.45.44 joerg src/sys/kern/kern_ntptime.c,v 1.57 2015.11.23.23.46.33 joerg src/sys/external/isc/atheros_hal/dist/ar5210/ar5210_reset.c,v 1.6 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2015.11.html#2015.11.23.23.46.33
Re: Automated report: NetBSD-current/i386 build failure
This has already been fixed. On Tue, 24 Nov 2015, NetBSD Test Fixture wrote: This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.NetBSD.org, a NetBSD/amd64 host, using sources from CVS date 2015.11.23.23.46.33. An extract from the build.sh output follows: --- dependall-sys --- /tmp/bracket/build/2015.11.23.23.46.33-i386/src/sys/dev/filemon/filemon.c: In function 'filemon_ioctl': /tmp/bracket/build/2015.11.23.23.46.33-i386/src/sys/dev/filemon/filemon.c:281:25: error: unused variable 'p' [-Werror=unused-variable] struct proc *tp, *lp, *p; ^ /tmp/bracket/build/2015.11.23.23.46.33-i386/src/sys/dev/filemon/filemon.c:281:20: error: unused variable 'lp' [-Werror=unused-variable] struct proc *tp, *lp, *p; ^ cc1: all warnings being treated as errors --- dependall-external --- --- dependall-bsd --- --- ippool_l.h --- --- dependall-sys --- *** [filemon.o] Error code 1 nbmake[8]: stopped in /tmp/bracket/build/2015.11.23.23.46.33-i386/src/sys/modules/filemon 1 error The following commits were made between the last successful build and the failed build: 2015.11.23.21.40.14 jdc src/sys/arch/sparc64/dev/schizo.c,v 1.34 2015.11.23.21.40.14 jdc src/sys/arch/sparc64/dev/schizoreg.h,v 1.11 2015.11.23.21.40.14 jdc src/sys/arch/sparc64/dev/schizovar.h,v 1.7 2015.11.23.22.20.57 pgoyette src/sys/dev/filemon/filemon.c,v 1.18 2015.11.23.22.34.00 christos src/usr.sbin/makemandb/apropos-utils.c,v 1.18 2015.11.23.22.35.28 christos src/lib/libterminfo/terminfo.3,v 1.13 2015.11.23.23.00.29 pgoyette src/share/man/man4/filemon.4,v 1.14 2015.11.23.23.23.25 pgoyette src/share/man/man7/sysctl.7,v 1.95 2015.11.23.23.27.38 pgoyette src/sys/dev/filemon/filemon.c,v 1.19 2015.11.23.23.28.33 pgoyette src/share/man/man4/filemon.4,v 1.15 2015.11.23.23.45.44 joerg src/sys/kern/kern_ntptime.c,v 1.57 2015.11.23.23.46.33 joerg src/sys/external/isc/atheros_hal/dist/ar5210/ar5210_reset.c,v 1.6 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2015.11.html#2015.11.23.23.46.33 +--+--+-+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--+-+
daily CVS update output
Updating src tree: P src/distrib/sets/lists/base/mi P src/etc/mtree/NetBSD.dist.base P src/etc/mtree/special P src/etc/rc.d/ntpd P src/lib/libcurses/setterm.c P src/lib/libterminfo/terminfo.3 P src/share/man/man4/filemon.4 P src/share/man/man7/sysctl.7 P src/sys/arch/sparc64/dev/schizo.c P src/sys/arch/sparc64/dev/schizoreg.h P src/sys/arch/sparc64/dev/schizovar.h P src/sys/dev/filemon/filemon.c P src/sys/external/isc/atheros_hal/dist/ar5210/ar5210_reset.c P src/sys/kern/kern_ntptime.c P src/sys/ufs/lfs/ulfs_readwrite.c P src/tests/net/net/t_forwarding.sh P src/usr.sbin/makemandb/apropos-utils.c Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Tue Nov 24 03:29:13 2015 SUP Scan for current completed at Tue Nov 24 03:42:12 2015 SUP Scan for mirror starting at Tue Nov 24 03:42:12 2015 SUP Scan for mirror completed at Tue Nov 24 03:49:50 2015 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 56021485 Nov 24 04:05 ls-lRA.gz
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
