I haven't been able to find this information anywhere. I know HZ was
increased to 1000, but was the timeslice decreased to 1 ms (from 10 ms)
as well?
Steve
On Sat, 2 Aug 2003 01:51, Stephen Anthony wrote:
> I haven't been able to find this information anywhere. I know HZ was
> increased to 1000, but was the timeslice decreased to 1 ms (from 10 ms)
> as well?
Depends on nice of the task. Nice 0 tasks get 102ms.
Con
>> I haven't been able to find this information anywhere. I know HZ was
>> increased to 1000, but was the timeslice decreased to 1 ms (from 10 ms)
>> as well?
>
> Depends on nice of the task. Nice 0 tasks get 102ms.
I don't think I asked the right question :) If I call usleep(x) or
nanosleep(x) with kernel 2.4.21, and x < 10, the sleep would still last
10 ms because of the timeslice. All sleeps would be a multiple of 10 ms.
If I call usleep(x) or nanosleep(x) in 2.6.0-test2, what 'multiple' can I
expect? Maybe I mean granularity instead of timeslice. Basically, I
want to know how 'soft' of a real-time system the new kernel is.
It would be great if sleeps were 1ms accurate instead of 10ms. It would
make synchronization code a lot easier.
Steve
On Fri, Aug 01, 2003 at 02:04:46PM -0230, Stephen Anthony wrote:
> It would be great if sleeps were 1ms accurate instead of 10ms. It would
> make synchronization code a lot easier.
Doesn't this depend on what HZ you define for the kernel?
If you want 1ms sleep, just set HZ to 1000HZ+, and give your process a
high priority?
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Mark Mielke wrote:
> On Fri, Aug 01, 2003 at 02:04:46PM -0230, Stephen Anthony wrote:
>
>>It would be great if sleeps were 1ms accurate instead of 10ms. It would
>>make synchronization code a lot easier.
>
>
> Doesn't this depend on what HZ you define for the kernel?
>
> If you want 1ms sleep, just set HZ to 1000HZ+, and give your process a
> high priority?
>
> mark
>
From user space, at least, you can configure /dev/rtc to 1024HZ and then
select on it's file descriptor. That will give you fairly reliable 1ms (or so)
sleeps, especially if you set your niceness to a high-priority setting.
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Ben Greear wrote:
>
> Mark Mielke wrote:
>
>> On Fri, Aug 01, 2003 at 02:04:46PM -0230, Stephen Anthony wrote:
>>
>>> It would be great if sleeps were 1ms accurate instead of 10ms. It
>>> would make synchronization code a lot easier.
>>
>>
>>
>> Doesn't this depend on what HZ you define for the kernel?
>>
>> If you want 1ms sleep, just set HZ to 1000HZ+, and give your process a
>> high priority?
As it currently stands in the 2.6 kernel for the i386, HZ is defined
as 1000. Since the PIT interrupt source can not hit this, the actual
timer interrupt period is 999848 nano seconds. The minimum sleep
interval nanosleep will take is 1 of these and since the time may
start between ticks it adds another to give a min sleep time of
999848+~1/2 of that depending on where the request falls in the time
period.
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml