* latency error (~2ms) with nanosleep
@ 2005-06-13 13:30 quade
2005-06-13 14:21 ` Richard B. Johnson
2005-06-13 16:48 ` Chris Friesen
0 siblings, 2 replies; 6+ messages in thread
From: quade @ 2005-06-13 13:30 UTC (permalink / raw)
To: linux-kernel; +Cc: quade
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
Playing around with the (simple) measurement of latency-times
I noticed, that the systemcall "nanosleep" has always a minimal
latency from about ~2ms (haven't run it all night, so...). It
seems to be a systematical error.
A short investigation shows, that "sys_nanosleep()" uses
schedule_timeout(), but schedule_timeout() is working exactly
as expected. Therefore I think it has something to do with
the scheduling?
Has someone an explanation for the ~2ms error?
If it is indeed a systematical error, does it make sense to
"adjust" (correct) this error in the systemcall "sys_nanosleep()"?
Find attached my small test program.
Juergen.
[-- Attachment #2: nano.c --]
[-- Type: text/x-csrc, Size: 1633 bytes --]
#include <stdio.h>
#include <time.h>
#include <sched.h>
#include <sys/time.h>
#define TAKTFREQ 600
static inline unsigned long long int rdtsc()
{
unsigned long long int x;
__asm__ volatile (".byte 0x0f, 0x31" : "=A" (x));
return x;
}
// XXX - I know, there can be an overrun ...
static inline unsigned long time_in_usec( struct timeval *tv )
{
return (tv->tv_sec*1000000)+tv->tv_usec;
}
int main( int argc, char **argv )
{
int i;
struct timespec delay;
struct timeval tvstart, tvend;
unsigned long start, end, timediff, maxdiff, shouldbetime;
unsigned long mindiff;
#if 1
struct sched_param SchedulingParameter;
SchedulingParameter.sched_priority = 50;
if( sched_setscheduler( 0, SCHED_RR, &SchedulingParameter )!= 0 ) {
perror( "Set Scheduling Priority" );
return -1;
}
#endif
for( shouldbetime=1000; shouldbetime<51000;shouldbetime+=1000 ) {
mindiff = 0xffffffff;
maxdiff = 0;
for( i=0; i<30; i++ ) {
delay.tv_sec = 0;
delay.tv_nsec = shouldbetime*1000; // in nsec
gettimeofday(&tvstart,NULL);
start = rdtsc();
nanosleep( &delay, NULL );
end = rdtsc();
gettimeofday(&tvend,NULL);
#if 0
printf("timdiff: %ld - %ld\n",
(end-start)/TAKTFREQ, // 600 MHz - in usec
time_in_usec(&tvend)-time_in_usec(&tvstart));
#endif
timediff = time_in_usec(&tvend)-time_in_usec(&tvstart);
timediff -= shouldbetime;
if( (timediff > maxdiff)&&i>0 )
maxdiff = timediff;
if( (timediff < mindiff)&&i>0 )
mindiff = timediff;
}
//printf("%7.1ld-> max diff: %ld\n", shouldbetime, maxdiff );
printf("%7.1ld %ld %ld\n", shouldbetime, maxdiff, mindiff );
}
return 0;
}
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: latency error (~2ms) with nanosleep
2005-06-13 13:30 latency error (~2ms) with nanosleep quade
@ 2005-06-13 14:21 ` Richard B. Johnson
2005-06-13 14:27 ` Eric Piel
2005-06-13 16:48 ` Chris Friesen
1 sibling, 1 reply; 6+ messages in thread
From: Richard B. Johnson @ 2005-06-13 14:21 UTC (permalink / raw)
To: quade; +Cc: linux-kernel
nanosleep, according to the documation is supposed to sleep
"at least" the 'struct timespec' time. It can return in
a shorter time as a result of a signal and, if so, the
input time-values will be updated accordingly. The resolution
is limited to the HZ value. This means that it will, unless
interrupted, always sleep at least 1 / HZ seconds (about 1 ms
on current x86 distributions).
FYI, there is no 'fine resolution' timer available on any
Linux-ported platform that could take advantage of the nanosecond
input resolution of the function.
On Mon, 13 Jun 2005, quade wrote:
>
> Playing around with the (simple) measurement of latency-times
> I noticed, that the systemcall "nanosleep" has always a minimal
> latency from about ~2ms (haven't run it all night, so...). It
> seems to be a systematical error.
>
> A short investigation shows, that "sys_nanosleep()" uses
> schedule_timeout(), but schedule_timeout() is working exactly
> as expected. Therefore I think it has something to do with
> the scheduling?
>
> Has someone an explanation for the ~2ms error?
> If it is indeed a systematical error, does it make sense to
> "adjust" (correct) this error in the systemcall "sys_nanosleep()"?
>
> Find attached my small test program.
>
> Juergen.
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: latency error (~2ms) with nanosleep
2005-06-13 14:21 ` Richard B. Johnson
@ 2005-06-13 14:27 ` Eric Piel
0 siblings, 0 replies; 6+ messages in thread
From: Eric Piel @ 2005-06-13 14:27 UTC (permalink / raw)
To: linux-os; +Cc: quade, linux-kernel
06/13/2005 04:21 PM, Richard B. Johnson wrote/a écrit:
>
> nanosleep, according to the documation is supposed to sleep
> "at least" the 'struct timespec' time. It can return in
> a shorter time as a result of a signal and, if so, the
> input time-values will be updated accordingly. The resolution
> is limited to the HZ value. This means that it will, unless
> interrupted, always sleep at least 1 / HZ seconds (about 1 ms
> on current x86 distributions).
>
> FYI, there is no 'fine resolution' timer available on any
> Linux-ported platform that could take advantage of the nanosecond
> input resolution of the function.
>
I could add that there is a project working on this issue:
high-resolution timers . You can download patches for 2.6 and 2.4 . The
precision is in the order of 10 or 100 µs.
Eric
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: latency error (~2ms) with nanosleep
2005-06-13 13:30 latency error (~2ms) with nanosleep quade
2005-06-13 14:21 ` Richard B. Johnson
@ 2005-06-13 16:48 ` Chris Friesen
2005-06-13 16:54 ` Nish Aravamudan
1 sibling, 1 reply; 6+ messages in thread
From: Chris Friesen @ 2005-06-13 16:48 UTC (permalink / raw)
To: quade; +Cc: linux-kernel
quade wrote:
> Playing around with the (simple) measurement of latency-times
> I noticed, that the systemcall "nanosleep" has always a minimal
> latency from about ~2ms (haven't run it all night, so...). It
> seems to be a systematical error.
Known issue. The x86 interrupt usually has a period of slightly less
than a ms. It will therefore generally add nearly a whole ms to ensure
that it does not ever wait for *less* than specified.
Chris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: latency error (~2ms) with nanosleep
2005-06-13 16:48 ` Chris Friesen
@ 2005-06-13 16:54 ` Nish Aravamudan
2005-06-14 8:57 ` quade
0 siblings, 1 reply; 6+ messages in thread
From: Nish Aravamudan @ 2005-06-13 16:54 UTC (permalink / raw)
To: Chris Friesen; +Cc: quade, linux-kernel
On 6/13/05, Chris Friesen <cfriesen@nortel.com> wrote:
> quade wrote:
> > Playing around with the (simple) measurement of latency-times
> > I noticed, that the systemcall "nanosleep" has always a minimal
> > latency from about ~2ms (haven't run it all night, so...). It
> > seems to be a systematical error.
>
> Known issue. The x86 interrupt usually has a period of slightly less
> than a ms. It will therefore generally add nearly a whole ms to ensure
> that it does not ever wait for *less* than specified.
Exactly. And the sys_nanosleep() code adds one more if the parameter
has any positive value at all:
expire = timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec);
current->state = TASK_INTERRUPTIBLE;
expire = schedule_timeout(expire);
Thanks,
Nish
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: latency error (~2ms) with nanosleep
2005-06-13 16:54 ` Nish Aravamudan
@ 2005-06-14 8:57 ` quade
0 siblings, 0 replies; 6+ messages in thread
From: quade @ 2005-06-14 8:57 UTC (permalink / raw)
To: Nish Aravamudan; +Cc: Chris Friesen, linux-kernel
On Mon, Jun 13, 2005 at 09:54:47AM -0700, Nish Aravamudan wrote:
> On 6/13/05, Chris Friesen <cfriesen@nortel.com> wrote:
> > quade wrote:
> > > Playing around with the (simple) measurement of latency-times
> > > I noticed, that the systemcall "nanosleep" has always a minimal
> > > latency from about ~2ms (haven't run it all night, so...). It
> > > seems to be a systematical error.
> >
> > Known issue. The x86 interrupt usually has a period of slightly less
> > than a ms. It will therefore generally add nearly a whole ms to ensure
> > that it does not ever wait for *less* than specified.
>
> Exactly. And the sys_nanosleep() code adds one more if the parameter
> has any positive value at all:
>
> expire = timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec);
> current->state = TASK_INTERRUPTIBLE;
> expire = schedule_timeout(expire);
>
> Thanks,
> Nish
> -
> 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/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-06-14 8:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-13 13:30 latency error (~2ms) with nanosleep quade
2005-06-13 14:21 ` Richard B. Johnson
2005-06-13 14:27 ` Eric Piel
2005-06-13 16:48 ` Chris Friesen
2005-06-13 16:54 ` Nish Aravamudan
2005-06-14 8:57 ` quade
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox