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
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
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
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
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
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
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
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