From: "mark manning" <mark.manning@fastermail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: nanosleep
Date: Wed, 10 Apr 2002 00:57:08 -0500 [thread overview]
Message-ID: <20020410055708.9474.qmail@fastermail.com> (raw)
hrm - im confiused now - how can you do a n NANO second delay when the resolution is 10 mili seconds ?
forgive my ignorance and my persistant "stupid" questions :)
----- Original Message -----
From: "H. Peter Anvin" <hpa@zytor.com>
Date: 9 Apr 2002 22:47:42 -0700
To: linux-kernel@vger.kernel.org
Subject: Re: nanosleep
> Followup to: <20020410044243.2916.qmail@fastermail.com>
> By author: "mark manning" <mark.manning@fastermail.com>
> In newsgroup: linux.dev.kernel
> >
> > thanx - how much of a difference should i expect - i know the
> > syscall is asking for at least the required ammount but that the
> > task switcher might not give me control back for a while after the
> > requested delay but i was expecting to be a little closer to what i
> > had asked for - this isnt critical of corse but i would like to know
> > what to expect.
> >
>
> Read the man page:
>
> BUGS
> The current implementation of nanosleep is based on the
> normal kernel timer mechanism, which has a resolution of
> 1/HZ s (i.e, 10 ms on Linux/i386 and 1 ms on Linux/Alpha).
> Therefore, nanosleep pauses always for at least the speci
> fied time, however it can take up to 10 ms longer than
> specified until the process becomes runnable again. For
> the same reason, the value returned in case of a delivered
> signal in *rem is usually rounded to the next larger mul
> tiple of 1/HZ s.
>
> As some applications require much more precise pauses
> (e.g., in order to control some time-critical hardware),
> nanosleep is also capable of short high-precision pauses.
> If the process is scheduled under a real-time policy like
> SCHED_FIFO or SCHED_RR, then pauses of up to 2 ms will be
> performed as busy waits with microsecond precision.
>
> -hpa
> --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
_______________________________________________
Get your free email from http://www.fastermail.com
Powered by Outblaze
next reply other threads:[~2002-04-10 5:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-10 5:57 mark manning [this message]
2002-04-10 6:01 ` nanosleep Robert Love
2002-04-13 21:53 ` nanosleep andrew may
2002-04-14 20:37 ` nanosleep H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2002-04-10 4:42 nanosleep mark manning
2002-04-10 5:47 ` nanosleep H. Peter Anvin
2002-04-10 4:41 nanosleep mark manning
2002-04-10 5:57 ` nanosleep Robert Love
2002-04-10 3:22 nanosleep mark manning
2002-04-09 23:24 nanosleep mark manning
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020410055708.9474.qmail@fastermail.com \
--to=mark.manning@fastermail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox