nanosleep
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.
----- Original Message -----
From: "H. Peter Anvin" <[email protected]>
Date: Tue, 09 Apr 2002 21:17:03 -0700
To: mark manning <[email protected]>
Subject: Re: nanosleep
Quoted 12 lines
Quoted 2 lines · mark manning
doh - i think something is still wrong, i ask for 1000 ms and i get a second but if i do a 500 itteration loop asking for 1 ms i get 5 seconds. i am also starting to distrust my elapsed time display which is using the gettimeofday syscall
It doesn't work that way. Each call to
nanosleep()gives you a *MINIMUM* time to delay. The kernel may decide to schedule you away and pick your process up when it suits it.-hpa
Signature · 4 lines
_______________________________________________ Get your free email from http://www.fastermail.com Powered by Outblaze
Followup to: <[email protected]> By author: "mark manning" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 8 lines
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
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>