Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Jan 2000 20:48:11 +0100
From:      Mattias Pantzare <pantzer@ludd.luth.se>
To:        Mikhail Teterin <mi@kot.ne.mediaone.net>
Cc:        David Schwartz <davids@webmaster.com>, stable@FreeBSD.ORG
Subject:   Re: kern/13644 
Message-ID:  <200001231948.UAA01010@queeg.ludd.luth.se>
In-Reply-To: Message from Mikhail Teterin <mi@kot.ne.mediaone.net>  of "Sun, 23 Jan 2000 11:36:08 EST." <200001231636.LAA43285@rtfm.newton> 

next in thread | previous in thread | raw e-mail | index | archive | help
> It  appears, that  you,  as well  as other  developers,  speak from  the
> implementation point of view. I only  look at the man-page. The man page
> says, the time out  is the UPPER limit. The pthread  case is broken even
> further...
> 
> Bruce,  it appeared,  tried to  say the  man-page is  broken, while  the
> implementation is correct,  but remains  silent despite  me quoting  all
> sorts of  other man-pages from all  sorts of other vendors,  who all say
> (almost) the same thing:
> 
> 	that the timeout is indeed the UPPER limit, and not the LOWER.

It is the upper limit. The kernel will put the program on the run queue when 
it noticeses that the time limit expires.

The problem is simply that the kernel that has a lower resolution on it's 
scheduling than the clock that you are using, and that it takes time to do 
things on a noral CPU. 

From the man-page on solaris:
     whose members are 0, select() does not block. If the timeout
     argument  is  a null pointer, select() blocks until an event
     causes one of the masks to be returned with  a  valid  (non-
     zero)  value.   If  the  time limit expires before any event
     occurs that would cause one of the masks  to  be  set  to  a
     non-zero  value, select() completes successfully and returns
     0.

Things will get even worse if your computer has a high CPU load or your 
process is on disk.

By the way, solaris will do the same, but with a bit more precision, at least 
on sparc:

Slept for 3452 instead of 2000 microseconds
Slept for 9103 instead of 3000 microseconds
Slept for 9955 instead of 4000 microseconds
Slept for 9803 instead of 5000 microseconds
Slept for 10136 instead of 6000 microseconds
Slept for 9624 instead of 7000 microseconds
Slept for 9964 instead of 8000 microseconds
Slept for 9802 instead of 9000 microseconds
Slept for 9880 instead of 10000 microseconds
Slept for 20894 instead of 11000 microseconds
Slept for 19450 instead of 12000 microseconds
Slept for 19803 instead of 13000 microseconds
Slept for 19731 instead of 14000 microseconds
Slept for 19883 instead of 15000 microseconds
Slept for 19887 instead of 16000 microseconds
Slept for 19882 instead of 17000 microseconds

And OSF1 on alpha:
Slept for 2930 instead of 2000 microseconds
Slept for 3906 instead of 3000 microseconds
Slept for 4883 instead of 4000 microseconds
Slept for 5859 instead of 5000 microseconds
Slept for 6836 instead of 6000 microseconds
Slept for 7813 instead of 7000 microseconds
Slept for 8789 instead of 8000 microseconds
Slept for 9766 instead of 9000 microseconds
Slept for 10742 instead of 10000 microseconds
Slept for 11719 instead of 11000 microseconds




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001231948.UAA01010>