8 messages, 5 authors, 2005-08-28 · open the first message on its own page
From: Rune Torgersen <hidden>
Date: 2005-08-26 22:48:59
On Friday, August 26, 2005 16:32 Tom Rini wrote:
So 250 is supposed to be the best choice of power vs latency and such. But hey, there's nothing stopping us from setting all of the embedded configs back down to 100 :)
I thought the default value for HZ in 2.6 was 1000? At least this is what it is set at for the 82xx (and bigger embedded) boards=20
From: Dan Malek <hidden>
Date: 2005-08-26 22:54:52
On Aug 26, 2005, at 6:48 PM, Rune Torgersen wrote:
I thought the default value for HZ in 2.6 was 1000? At least this is what it is set at for the 82xx (and bigger embedded) boards
Oh geeze, no wonder we can't get any performance out of 2.6 on these boards. Between that and the TLB thrashing going on there's nothing left for the applications :-) -- Dan
From: Tom Rini <hidden>
Date: 2005-08-26 22:55:10
On Fri, Aug 26, 2005 at 05:48:53PM -0500, Rune Torgersen wrote:
On Friday, August 26, 2005 16:32 Tom Rini wrote:quoted
So 250 is supposed to be the best choice of power vs latency and such. But hey, there's nothing stopping us from setting all of the embedded configs back down to 100 :)I thought the default value for HZ in 2.6 was 1000?
Yes, it was. With 2.6.13 and on i386 (and other arches that actually make use of the question) it can be any of 100, 250 or 1000. -- Tom Rini http://gate.crashing.org/~trini/
From: Dan Malek <hidden>
Date: 2005-08-26 23:07:19
On Aug 26, 2005, at 6:55 PM, Tom Rini wrote:
Yes, it was. With 2.6.13 and on i386 (and other arches that actually make use of the question) it can be any of 100, 250 or 1000.
Well, 250 just seems wrong as I mentioned in a previous message. It will function, but an application is going to see lots of clock jitter unless you work in multiples of 100. My choices would be 100, 200, 500, or 1000. Thanks. -- Dan
From: Tom Rini <hidden>
Date: 2005-08-26 23:13:22
On Fri, Aug 26, 2005 at 07:07:01PM -0400, Dan Malek wrote:
On Aug 26, 2005, at 6:55 PM, Tom Rini wrote:quoted
Yes, it was. With 2.6.13 and on i386 (and other arches that actually make use of the question) it can be any of 100, 250 or 1000.Well, 250 just seems wrong as I mentioned in a previous message. It will function, but an application is going to see lots of clock jitter unless you work in multiples of 100. My choices would be 100, 200, 500, or 1000.
That's an arguement for lkml. But as I recall things, there shouldn't be jitter, probably, with non multiples of 100. There was some discussion, and a fair bit of flaming about all of this on lkml. I think with some sort of numbers Linus might buy another choice added to the list, but refuses anything "in theory" (this stems in part from the must be 1000 crowd not being happy about 250 as the default). -- Tom Rini http://gate.crashing.org/~trini/
From: Grant Likely <hidden>
Date: 2005-08-27 05:15:18
On Fri, Aug 26, 2005 at 07:07:01PM -0400, Dan Malek wrote:
On Aug 26, 2005, at 6:55 PM, Tom Rini wrote:quoted
Yes, it was. With 2.6.13 and on i386 (and other arches that actually make use of the question) it can be any of 100, 250 or 1000.Well, 250 just seems wrong as I mentioned in a previous message. It will function, but an application is going to see lots of clock jitter unless you work in multiples of 100. My choices would be 100, 200, 500, or 1000.
What's the reason for clock jitter? Is it because most timeouts are set to multiples of 100, or some other reason? Thanks, g.
From: Dan Malek <hidden>
Date: 2005-08-28 00:48:29
On Aug 27, 2005, at 1:04 AM, Grant Likely wrote:
What's the reason for clock jitter? Is it because most timeouts are set to multiples of 100, or some other reason?
Yes, the application interfaces are all defined as 100 Hz (10 mSec). If the POSIX timer implementation is done properly, it should be possible to determine the timer parameters to eliminate this, but I doubt any applications do this. They all assume 10 mSec :-) -- Dan
From: Paul Mackerras <hidden>
Date: 2005-08-28 02:19:47
Dan Malek writes:
Yes, the application interfaces are all defined as 100 Hz (10 mSec). If the POSIX timer implementation is done properly, it should be possible to determine the timer parameters to eliminate this, but I doubt any applications do this. They all assume 10 mSec :-)
There are in fact only a few interfaces that work in terms of "clock ticks", which are 10ms as far as userspace is concerned. I can think of times() and that's about it. There are also the si_utime and si_stime fields of the siginfo_t that comes along with a SIGCHLD. All of those are about reporting CPU time used, not about specifying timeouts. All of the interfaces that specify timeouts or control timers use struct timeval (seconds + microseconds) or struct timespec (seconds + nanoseconds), or else use milliseconds (e.g. poll()). Paul.