nanosleep issue

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

nanosleep issue

s_graf
Does nanosleep work properly on arm?  On my orangepione (Allwinner H3), I
can not get a nanosleep of less than 20 milliseconds and anything above that
seems to sleep 10 milliseconds more than what is requested.

Reply | Threaded
Open this post in threaded view
|

Re: nanosleep issue

Artturi Alm
On Sun, May 20, 2018 at 11:54:43PM -0700, [hidden email] wrote:
> Does nanosleep work properly on arm?  On my orangepione (Allwinner H3), I
> can not get a nanosleep of less than 20 milliseconds and anything above that
> seems to sleep 10 milliseconds more than what is requested.
>

Hi,

it does, but it's apparently undocumented in nanosleep(2), that the
default HZ of =100 is something for not-really-a-modern-machine..

There's a diff[0] to fix that, and it's something i have on most of
my branches, but i was told the diff/thread needs no bumping on tech@,
so it is on users to cope with this, i guess. Good luck:)

-Artturi


[0] https://marc.info/?l=openbsd-tech&m=150274123011009&w=2

Reply | Threaded
Open this post in threaded view
|

Re: nanosleep issue

s_graf
In reply to this post by s_graf
Thank you for the patch.  I applied it and am now able to get times less than 20 ms.  However the time is now off by 1 ms instead of 10. A sleep of 10 ms goes 11 ms and a 1 ms sleep goes 2ms.  See attached.

Stephen Graf

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Artturi Alm
Sent: May 21, 2018 2:18 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: nanosleep issue

On Sun, May 20, 2018 at 11:54:43PM -0700, [hidden email] wrote:
> Does nanosleep work properly on arm?  On my orangepione (Allwinner
> H3), I can not get a nanosleep of less than 20 milliseconds and
> anything above that seems to sleep 10 milliseconds more than what is requested.
>

Hi,

it does, but it's apparently undocumented in nanosleep(2), that the default HZ of =100 is something for not-really-a-modern-machine..

There's a diff[0] to fix that, and it's something i have on most of my branches, but i was told the diff/thread needs no bumping on tech@, so it is on users to cope with this, i guess. Good luck:)

-Artturi


[0] https://marc.info/?l=openbsd-tech&m=150274123011009&w=2


10ms.PNG (27K) Download Attachment
1msec.PNG (32K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: nanosleep issue

Philip Guenther-2
On Mon, May 21, 2018 at 11:30 AM, <[hidden email]> wrote:

> Thank you for the patch.  I applied it and am now able to get times less
> than 20 ms.  However the time is now off by 1 ms instead of 10. A sleep of
> 10 ms goes 11 ms and a 1 ms sleep goes 2ms.  See attached.
>

OpenBSD is not a tickless kernel.  If you need nanosleep precision that's
much higher than what you're seeing, then OpenBSD is not currently able to
meet your requirements.

Would it be better to be tickless?  Sure, but no one has sat down and
figured out how to do that _and_ continue to support the range of hardware
we support.  Is it on peoples' lists? Sure, but so is a lot of other stuff
which is higher priority.  Some day?


Philip Guenther
Reply | Threaded
Open this post in threaded view
|

Re: nanosleep issue

s_graf
In reply to this post by s_graf
There seem to be two issues with nanosleep.

The first is a lack of information in the man page.  It would be useful to know that the minimum sleep time is limited to one tick of the system clock and that it varies with the architecture.

Second, given the above, there seems to be an initialization or end point count problem.  The minimum time seems to be two ticks, not one and the sleep time is one more tick than is requested.

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Philip Guenther
Sent: May 21, 2018 7:29 PM
To: Stephen Graf <[hidden email]>
Cc: [hidden email]; Artturi Alm <[hidden email]>
Subject: Re: nanosleep issue

On Mon, May 21, 2018 at 11:30 AM, <[hidden email]> wrote:

> Thank you for the patch.  I applied it and am now able to get times
> less than 20 ms.  However the time is now off by 1 ms instead of 10. A
> sleep of
> 10 ms goes 11 ms and a 1 ms sleep goes 2ms.  See attached.
>

OpenBSD is not a tickless kernel.  If you need nanosleep precision that's much higher than what you're seeing, then OpenBSD is not currently able to meet your requirements.

Would it be better to be tickless?  Sure, but no one has sat down and figured out how to do that _and_ continue to support the range of hardware we support.  Is it on peoples' lists? Sure, but so is a lot of other stuff which is higher priority.  Some day?


Philip Guenther

Reply | Threaded
Open this post in threaded view
|

Re: nanosleep issue

Philip Guenther-2
On Tue, May 22, 2018 at 4:02 PM, <[hidden email]> wrote:

> There seem to be two issues with nanosleep.
>
> The first is a lack of information in the man page.  It would be useful to
> know that the minimum sleep time is limited to one tick of the system clock
> and that it varies with the architecture.
>

A reference to clock_getres(2) would make sense, sure.



> Second, given the above, there seems to be an initialization or end point
> count problem.  The minimum time seems to be two ticks, not one and the
> sleep time is one more tick than is requested.
>

nanosleep(2) MUST NOT return before the requested time has passed.  Given
that hard requirement from POSIX and assuming that it's operating purely in
terms of ticks, how can it meet the requirement when the call might come a
nanosecond before the next tick?  If I request any non-zero amount of time
then the kernel can't just wait until the next tick because that may be
*too soon*, so under the limitation of only thinking in ticks, it must
round up and then add one.

Now, if you can work up a diff that peeks at the timecounters and can
deduce that it doesn't need to add one because how far away the next tick
is, go for it.  "I want nanosleep to sometimes lie" is not an option


Philip Guenther