public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 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