Re: Bad sleep time resolution of nanosleep(2)

2015-11-23 Thread Michael van Elst
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

Re: Bad sleep time resolution of nanosleep(2)

2015-11-23 Thread Michael van Elst
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

Re: Bad sleep time resolution of nanosleep(2)

2015-11-23 Thread Joerg Sonnenberger
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

Bad sleep time resolution of nanosleep(2)

2015-11-23 Thread Rhialto
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

Re: Bad sleep time resolution of nanosleep(2)

2015-11-23 Thread Rhialto
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

Automated report: NetBSD-current/i386 build failure

2015-11-23 Thread NetBSD Test Fixture
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 ---

Re: Automated report: NetBSD-current/i386 build failure

2015-11-23 Thread Paul Goyette
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

daily CVS update output

2015-11-23 Thread NetBSD source update
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

Re: Bad sleep time resolution of nanosleep(2)

2015-11-23 Thread Johnny Billquist
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