On Mon, 23 Apr 2001, Ulrich Windl wrote:
> IMHO the POSIX is doable to comply with POSIX. Probably not what many
> of the RT freaks expect, but doable. I'm tuning the nanoseconds for a
> while now...
>
> Ulrich
thanks for calling me a freak :)
yes, linux could have posix timers cobbled on
IMHO the POSIX is doable to comply with POSIX. Probably not what many
of the RT freaks expect, but doable. I'm tuning the nanoseconds for a
while now...
Ulrich
On 17 Apr 2001, at 11:53, george anzinger wrote:
> I was thinking that it might be good to remove the POSIX API for the
> kernel and
IMHO the POSIX is doable to comply with POSIX. Probably not what many
of the RT freaks expect, but doable. I'm tuning the nanoseconds for a
while now...
Ulrich
On 17 Apr 2001, at 11:53, george anzinger wrote:
I was thinking that it might be good to remove the POSIX API for the
kernel and
george anzinger wrote:
> > > a.) list insertion of an arbitrary timer,
> > should be O(log(n)) at worst
> >
> > > b.) removal of canceled and expired timers, and
> > easy to make O(1)
>
> I thought this was true also, but the priority heap structure that has
> been discussed here has a
Mark Salisbury wrote:
>
> > Functional Specification for the high-res-timers project.
> >
> > In addition we expect that we will provide a high resolution timer for
> > kernel use (heck, we may provide several).
>
> what we do here determines what we can do for the user..
I was thinking that
> Functional Specification for the high-res-timers project.
>
> In addition we expect that we will provide a high resolution timer for
> kernel use (heck, we may provide several).
what we do here determines what we can do for the user..
> We will provide several "clocks" as defined by the
On Mon, 16 Apr 2001, you wrote:
> Mark Salisbury wrote:
> >
> > > Given a system speed, there is a repeating timer rate which will consume
> > > 100% of the system in handling the timer interrupts. An attempt will
> > > be made to detect this rate and adjust the timer to prevent system
> > >
On Mon, 16 Apr 2001, you wrote:
Mark Salisbury wrote:
Given a system speed, there is a repeating timer rate which will consume
100% of the system in handling the timer interrupts. An attempt will
be made to detect this rate and adjust the timer to prevent system
lockup. This
Functional Specification for the high-res-timers project.
In addition we expect that we will provide a high resolution timer for
kernel use (heck, we may provide several).
what we do here determines what we can do for the user..
We will provide several "clocks" as defined by the
Mark Salisbury wrote:
Functional Specification for the high-res-timers project.
In addition we expect that we will provide a high resolution timer for
kernel use (heck, we may provide several).
what we do here determines what we can do for the user..
I was thinking that it might be
george anzinger wrote:
a.) list insertion of an arbitrary timer,
should be O(log(n)) at worst
b.) removal of canceled and expired timers, and
easy to make O(1)
I thought this was true also, but the priority heap structure that has
been discussed here has a O(log(n)) removal time.
Mark Salisbury wrote:
>
> > Given a system speed, there is a repeating timer rate which will consume
> > 100% of the system in handling the timer interrupts. An attempt will
> > be made to detect this rate and adjust the timer to prevent system
> > lockup. This adjustment will look like timer
> Given a system speed, there is a repeating timer rate which will consume
> 100% of the system in handling the timer interrupts. An attempt will
> be made to detect this rate and adjust the timer to prevent system
> lockup. This adjustment will look like timer overruns to the user
> (i.e. we
"Albert D. Cahalan" wrote:
>
> > CLOCK_10MS a wall clock supporting timers with 10 ms resolution (same as
> > linux today).
>
> Except on the Alpha, and on some ARM systems, etc.
> The HZ constant varies from 10 to 1200.
I suspect we will want to use 10 ms resolution for a clock named
> CLOCK_10MS a wall clock supporting timers with 10 ms resolution (same as
> linux today).
Except on the Alpha, and on some ARM systems, etc.
The HZ constant varies from 10 to 1200.
> At the same time we will NOT support the following clocks:
>
> CLOCK_VIRTUAL a clock measuring the elapsed
Mark Salisbury wrote:
>
> all this talk about which data structure to use and how to allocate memory is
> wy premature.
>
> there needs to be a clear definition of the requirements that we wish to meet,
> including whether we are going to do ticked, tickless, or both
>
> a func spec, for
all this talk about which data structure to use and how to allocate memory is
wy premature.
there needs to be a clear definition of the requirements that we wish to meet,
including whether we are going to do ticked, tickless, or both
a func spec, for lack of a better term needs to be
all this talk about which data structure to use and how to allocate memory is
wy premature.
there needs to be a clear definition of the requirements that we wish to meet,
including whether we are going to do ticked, tickless, or both
a func spec, for lack of a better term needs to be
Mark Salisbury wrote:
all this talk about which data structure to use and how to allocate memory is
wy premature.
there needs to be a clear definition of the requirements that we wish to meet,
including whether we are going to do ticked, tickless, or both
a func spec, for lack of a
CLOCK_10MS a wall clock supporting timers with 10 ms resolution (same as
linux today).
Except on the Alpha, and on some ARM systems, etc.
The HZ constant varies from 10 to 1200.
At the same time we will NOT support the following clocks:
CLOCK_VIRTUAL a clock measuring the elapsed
"Albert D. Cahalan" wrote:
CLOCK_10MS a wall clock supporting timers with 10 ms resolution (same as
linux today).
Except on the Alpha, and on some ARM systems, etc.
The HZ constant varies from 10 to 1200.
I suspect we will want to use 10 ms resolution for a clock named
CLOCK_10MS :)
On
Given a system speed, there is a repeating timer rate which will consume
100% of the system in handling the timer interrupts. An attempt will
be made to detect this rate and adjust the timer to prevent system
lockup. This adjustment will look like timer overruns to the user
(i.e. we will
Mark Salisbury wrote:
Given a system speed, there is a repeating timer rate which will consume
100% of the system in handling the timer interrupts. An attempt will
be made to detect this rate and adjust the timer to prevent system
lockup. This adjustment will look like timer overruns
Jamie Lokier wrote:
>
> george anzinger wrote:
> > Horst von Brand wrote:
> > >
> > > Ben Greear <[EMAIL PROTECTED]> said:
> > >
> > > [...]
> > >
> > > > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > > > is log(n) and finding the one with the least time is O(1),
george anzinger wrote:
>
> Horst von Brand wrote:
> >
> > Ben Greear <[EMAIL PROTECTED]> said:
> >
> > [...]
> >
> > > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > > is log(n) and finding the one with the least time is O(1), ie pop off the
> > > front It can
george anzinger wrote:
Horst von Brand wrote:
Ben Greear [EMAIL PROTECTED] said:
[...]
Wouldn't a heap be a good data structure for a list of timers? Insertion
is log(n) and finding the one with the least time is O(1), ie pop off the
front It can be implemented in an
Jamie Lokier wrote:
george anzinger wrote:
Horst von Brand wrote:
Ben Greear [EMAIL PROTECTED] said:
[...]
Wouldn't a heap be a good data structure for a list of timers? Insertion
is log(n) and finding the one with the least time is O(1), ie pop off the
front
george anzinger wrote:
> Horst von Brand wrote:
> >
> > Ben Greear <[EMAIL PROTECTED]> said:
> >
> > [...]
> >
> > > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > > is log(n) and finding the one with the least time is O(1), ie pop off the
> > > front It can
george anzinger wrote:
> If we are to do high-res-timers, I think we will always have to do some
> sort of a sort on insert.
Yes, that's called a priority queue... (And you don't actually sort on
each insertion).
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe
Horst von Brand wrote:
>
> Ben Greear <[EMAIL PROTECTED]> said:
>
> [...]
>
> > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > is log(n) and finding the one with the least time is O(1), ie pop off the
> > front It can be implemented in an array which should
Ben Greear <[EMAIL PROTECTED]> said:
[...]
> Wouldn't a heap be a good data structure for a list of timers? Insertion
> is log(n) and finding the one with the least time is O(1), ie pop off the
> front It can be implemented in an array which should help cache
> coherency and all those
Jamie Lokier wrote:
>
> george anzinger wrote:
> > > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > > is log(n) and finding the one with the least time is O(1), ie pop off the
> > > front It can be implemented in an array which should help cache
> > >
george anzinger wrote:
> > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > is log(n) and finding the one with the least time is O(1), ie pop off the
> > front It can be implemented in an array which should help cache
> > coherency and all those other things they
Ben Greear wrote:
>
> Bret Indrelee wrote:
> >
> > On Thu, 12 Apr 2001, george anzinger wrote:
> > > Bret Indrelee wrote:
> > > >
> > > > On Thu, 12 Apr 2001, george anzinger wrote:
> > > > > Bret Indrelee wrote:
> > > > > > Keep all timers in a sorted double-linked list. Do the insert
> > > > >
Ben Greear wrote:
Bret Indrelee wrote:
On Thu, 12 Apr 2001, george anzinger wrote:
Bret Indrelee wrote:
On Thu, 12 Apr 2001, george anzinger wrote:
Bret Indrelee wrote:
Keep all timers in a sorted double-linked list. Do the insert
intelligently, adding it from
george anzinger wrote:
Wouldn't a heap be a good data structure for a list of timers? Insertion
is log(n) and finding the one with the least time is O(1), ie pop off the
front It can be implemented in an array which should help cache
coherency and all those other things they talked
Jamie Lokier wrote:
george anzinger wrote:
Wouldn't a heap be a good data structure for a list of timers? Insertion
is log(n) and finding the one with the least time is O(1), ie pop off the
front It can be implemented in an array which should help cache
coherency and all
Ben Greear [EMAIL PROTECTED] said:
[...]
Wouldn't a heap be a good data structure for a list of timers? Insertion
is log(n) and finding the one with the least time is O(1), ie pop off the
front It can be implemented in an array which should help cache
coherency and all those other
Horst von Brand wrote:
Ben Greear [EMAIL PROTECTED] said:
[...]
Wouldn't a heap be a good data structure for a list of timers? Insertion
is log(n) and finding the one with the least time is O(1), ie pop off the
front It can be implemented in an array which should help cache
george anzinger wrote:
If we are to do high-res-timers, I think we will always have to do some
sort of a sort on insert.
Yes, that's called a priority queue... (And you don't actually sort on
each insertion).
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
george anzinger wrote:
Horst von Brand wrote:
Ben Greear [EMAIL PROTECTED] said:
[...]
Wouldn't a heap be a good data structure for a list of timers? Insertion
is log(n) and finding the one with the least time is O(1), ie pop off the
front It can be implemented in an
Bret Indrelee wrote:
>
> On Thu, 12 Apr 2001, george anzinger wrote:
> > Bret Indrelee wrote:
> > >
> > > On Thu, 12 Apr 2001, george anzinger wrote:
> > > > Bret Indrelee wrote:
> > > > > Keep all timers in a sorted double-linked list. Do the insert
> > > > > intelligently, adding it from the
On Thu, 12 Apr 2001, george anzinger wrote:
> Bret Indrelee wrote:
> >
> > On Thu, 12 Apr 2001, george anzinger wrote:
> > > Bret Indrelee wrote:
> > > > Keep all timers in a sorted double-linked list. Do the insert
> > > > intelligently, adding it from the back or front of the list depending on
Bret Indrelee wrote:
>
> On Thu, 12 Apr 2001, george anzinger wrote:
> > Bret Indrelee wrote:
> > > Keep all timers in a sorted double-linked list. Do the insert
> > > intelligently, adding it from the back or front of the list depending on
> > > where it is in relation to existing entries.
> >
On Thu, 12 Apr 2001, george anzinger wrote:
> Bret Indrelee wrote:
> > Keep all timers in a sorted double-linked list. Do the insert
> > intelligently, adding it from the back or front of the list depending on
> > where it is in relation to existing entries.
>
> I think this is too slow,
Bret Indrelee wrote:
>
> Mikulas Patocka ([EMAIL PROTECTED]) wrote:
> > Adding and removing timers happens much more frequently than PIT tick,
> > so
> > comparing these times is pointless.
> >
> > If you have some device and timer protecting it from lockup on buggy
> > hardware, you actually
>
On Thu, 12 Apr 2001, Mark Salisbury wrote:
> On Wed, 11 Apr 2001, Bret Indrelee wrote:
> > Current generation PCs can easily handle 1000s of
> > interrupts a second if you keep the overhead small.
>
> the PC centric implementation of the ticked system is one of its major flaws.
>
> there are
On Wed, 11 Apr 2001, Bret Indrelee wrote:
> Current generation PCs can easily handle 1000s of
> interrupts a second if you keep the overhead small.
the PC centric implementation of the ticked system is one of its major flaws.
there are architectures which the cost of a fixed interval is the
On Wed, 11 Apr 2001, Jamie Lokier wrote:
> Think of the original 64k and 256k VGA cards. I think some of those
> didn't have an irq, but did have a way to read the progress of the
> raster, which you could PLL to using timer interrupts. Some video games
> still look fine at 320x200 :-)
The
watermodem wrote:
> As somebody who is now debating how to measure latencies in a
> giga-bit ethernet environment with several components doing
> L3 switching in much less than 10 micro-seconds ... (hardware)
> I agree that some method is need to achieve higher resolutions.
> (Sigh... I will
John Alvord wrote:
> I bumped into a funny non-optimization a few years ago. A system with
> a timer queue like the above had been "optimized" by keeping old timer
> elements... ready for new tasks to link onto and activate. The
> granularity was 1 millsecond. Over time, all timer values from 0
John Alvord wrote:
I bumped into a funny non-optimization a few years ago. A system with
a timer queue like the above had been "optimized" by keeping old timer
elements... ready for new tasks to link onto and activate. The
granularity was 1 millsecond. Over time, all timer values from 0 to
watermodem wrote:
As somebody who is now debating how to measure latencies in a
giga-bit ethernet environment with several components doing
L3 switching in much less than 10 micro-seconds ... (hardware)
I agree that some method is need to achieve higher resolutions.
(Sigh... I will
On Wed, 11 Apr 2001, Jamie Lokier wrote:
Think of the original 64k and 256k VGA cards. I think some of those
didn't have an irq, but did have a way to read the progress of the
raster, which you could PLL to using timer interrupts. Some video games
still look fine at 320x200 :-)
The
On Wed, 11 Apr 2001, Bret Indrelee wrote:
Current generation PCs can easily handle 1000s of
interrupts a second if you keep the overhead small.
the PC centric implementation of the ticked system is one of its major flaws.
there are architectures which the cost of a fixed interval is the same
On Thu, 12 Apr 2001, Mark Salisbury wrote:
On Wed, 11 Apr 2001, Bret Indrelee wrote:
Current generation PCs can easily handle 1000s of
interrupts a second if you keep the overhead small.
the PC centric implementation of the ticked system is one of its major flaws.
there are
Bret Indrelee wrote:
Mikulas Patocka ([EMAIL PROTECTED]) wrote:
Adding and removing timers happens much more frequently than PIT tick,
so
comparing these times is pointless.
If you have some device and timer protecting it from lockup on buggy
hardware, you actually
send request
On Thu, 12 Apr 2001, george anzinger wrote:
Bret Indrelee wrote:
Keep all timers in a sorted double-linked list. Do the insert
intelligently, adding it from the back or front of the list depending on
where it is in relation to existing entries.
I think this is too slow, especially for a
Bret Indrelee wrote:
On Thu, 12 Apr 2001, george anzinger wrote:
Bret Indrelee wrote:
Keep all timers in a sorted double-linked list. Do the insert
intelligently, adding it from the back or front of the list depending on
where it is in relation to existing entries.
I think this
On Thu, 12 Apr 2001, george anzinger wrote:
Bret Indrelee wrote:
On Thu, 12 Apr 2001, george anzinger wrote:
Bret Indrelee wrote:
Keep all timers in a sorted double-linked list. Do the insert
intelligently, adding it from the back or front of the list depending on
where it is
Bret Indrelee wrote:
On Thu, 12 Apr 2001, george anzinger wrote:
Bret Indrelee wrote:
On Thu, 12 Apr 2001, george anzinger wrote:
Bret Indrelee wrote:
Keep all timers in a sorted double-linked list. Do the insert
intelligently, adding it from the back or front of the list
Alan Cox wrote:
>
> > Timers more precise than 100HZ aren't probably needed - as MIN_RTO is 0.2s
> > and MIN_DELACK is 0.04s, TCP would hardly benefit from them.
>
> There are a considerable number of people who really do need 1Khz resolution.
> Midi is one of the example cases. That doesn't
> I suspect you might go for ticked if its overhead was less. The thing
> that makes me think the overhead is high for tick less is the accounting
> and time slice stuff. This has to be handled each system call and each
> schedule call. These happen WAY more often than ticks... Contrary
>
On Wed, 11 Apr 2001 20:57:04 +0200, Jamie Lokier
<[EMAIL PROTECTED]> wrote:
>george anzinger wrote:
>> > A pointer-based priority queue is really not a very complex thing, and
>> > there are ways to optimise them for typical cases like the above.
>> >
>> Please do enlighten me. The big problem
george anzinger wrote:
> > A pointer-based priority queue is really not a very complex thing, and
> > there are ways to optimise them for typical cases like the above.
> >
> Please do enlighten me. The big problem in my mind is that the
> pointers, pointing at points in time, are perishable.
Mikulas Patocka ([EMAIL PROTECTED]) wrote:
> Adding and removing timers happens much more frequently than PIT tick,
> so
> comparing these times is pointless.
>
> If you have some device and timer protecting it from lockup on buggy
> hardware, you actually
>
> send request to device
> add
On Mon, 9 Apr 2001, Alan Cox wrote:
> > > Its worth doing even on the ancient x86 boards with the PIT.
> >
> > Note that programming the PIT is slw and doing it on every timer
> > add_timer/del_timer would be a pain.
>
> You only have to do it occasionally.
>
> When you add a timer newer
Jamie Locker wrote:
>
> Mark Salisbury wrote:
> > > The complexity comes in when you want to maintain indexes into the list
> > > for quick insertion of new timers. To get the current insert
> > > performance, for example, you would need pointers to (at least) each of
> > > the next 256
Maciej W. Rozycki wrote:
> On Tue, 10 Apr 2001, Zdenek Kabelac wrote:
>
> > I think it would be wrong if we could not add new very usable features
> > to the system just because some old hardware doesn't support it.
>
> s/old/crappy/ -- even old hardware can handle vsync IRQs fine. E.g. TVGA
Mark Salisbury wrote:
> > The complexity comes in when you want to maintain indexes into the list
> > for quick insertion of new timers. To get the current insert
> > performance, for example, you would need pointers to (at least) each of
> > the next 256 centasecond boundaries in the list. But
On Tue, 10 Apr 2001, Zdenek Kabelac wrote:
> I think it would be wrong if we could not add new very usable features
> to the system just because some old hardware doesn't support it.
s/old/crappy/ -- even old hardware can handle vsync IRQs fine. E.g. TVGA
8900C.
--
+ Maciej W. Rozycki,
>f) As noted, the account timers (task user/system times) would be much
>more accurate with the tick less approach. The cost is added code in
>both the system call and the schedule path.
>
>Tentative conclusions:
>
>Currently we feel that the tick less approach is not acceptable due to
>(f).
f) As noted, the account timers (task user/system times) would be much
more accurate with the tick less approach. The cost is added code in
both the system call and the schedule path.
Tentative conclusions:
Currently we feel that the tick less approach is not acceptable due to
(f). We felt
On Tue, 10 Apr 2001, Zdenek Kabelac wrote:
I think it would be wrong if we could not add new very usable features
to the system just because some old hardware doesn't support it.
s/old/crappy/ -- even old hardware can handle vsync IRQs fine. E.g. TVGA
8900C.
--
+ Maciej W. Rozycki,
Mark Salisbury wrote:
The complexity comes in when you want to maintain indexes into the list
for quick insertion of new timers. To get the current insert
performance, for example, you would need pointers to (at least) each of
the next 256 centasecond boundaries in the list. But the
Maciej W. Rozycki wrote:
On Tue, 10 Apr 2001, Zdenek Kabelac wrote:
I think it would be wrong if we could not add new very usable features
to the system just because some old hardware doesn't support it.
s/old/crappy/ -- even old hardware can handle vsync IRQs fine. E.g. TVGA
8900C.
Jamie Locker wrote:
Mark Salisbury wrote:
The complexity comes in when you want to maintain indexes into the list
for quick insertion of new timers. To get the current insert
performance, for example, you would need pointers to (at least) each of
the next 256 centasecond
On Mon, 9 Apr 2001, Alan Cox wrote:
Its worth doing even on the ancient x86 boards with the PIT.
Note that programming the PIT is slw and doing it on every timer
add_timer/del_timer would be a pain.
You only have to do it occasionally.
When you add a timer newer than the
On Wed, 11 Apr 2001 20:57:04 +0200, Jamie Lokier
[EMAIL PROTECTED] wrote:
george anzinger wrote:
A pointer-based priority queue is really not a very complex thing, and
there are ways to optimise them for typical cases like the above.
Please do enlighten me. The big problem in my mind is
Mikulas Patocka ([EMAIL PROTECTED]) wrote:
Adding and removing timers happens much more frequently than PIT tick,
so
comparing these times is pointless.
If you have some device and timer protecting it from lockup on buggy
hardware, you actually
send request to device
add timer
I suspect you might go for ticked if its overhead was less. The thing
that makes me think the overhead is high for tick less is the accounting
and time slice stuff. This has to be handled each system call and each
schedule call. These happen WAY more often than ticks... Contrary
wise, I
Alan Cox wrote:
Timers more precise than 100HZ aren't probably needed - as MIN_RTO is 0.2s
and MIN_DELACK is 0.04s, TCP would hardly benefit from them.
There are a considerable number of people who really do need 1Khz resolution.
Midi is one of the example cases. That doesn't mean we
Mark Salisbury wrote:
>
> It would probably be a good compile config option to allow fine or coarse
> process time accounting, that leaves the choice to the person setting up the
> system to make the choice based on their needs.
>
I suggested this a while ago during a discussion about
Mark Salisbury wrote:
>
> > mark salisbury wrote:
> > >
> > > george anzinger wrote:
> > >
> > > > f) As noted, the account timers (task user/system times) would be much
> > > > more accurate with the tick less approach. The cost is added code in
> > > > both the system call and the schedule
> mark salisbury wrote:
> >
> > george anzinger wrote:
> >
> > > f) As noted, the account timers (task user/system times) would be much
> > > more accurate with the tick less approach. The cost is added code in
> > > both the system call and the schedule path.
> > >
> > > Tentative conclusions:
mark salisbury wrote:
>
> george anzinger wrote:
>
> > f) As noted, the account timers (task user/system times) would be much
> > more accurate with the tick less approach. The cost is added code in
> > both the system call and the schedule path.
> >
> > Tentative conclusions:
> >
> >
On Tue, Apr 10, 2001 at 02:45:15PM -0400, Stephen D. Williams wrote:
> When this is rewritten, I would strongly suggest that we find a way to
> make 'gettimeofday' nearly free. Certain applications need to use this
> frequently while still being portable. One solution when you do have
> clock
george anzinger wrote:
> f) As noted, the account timers (task user/system times) would be much
> more accurate with the tick less approach. The cost is added code in
> both the system call and the schedule path.
>
> Tentative conclusions:
>
> Currently we feel that the tick less approach is
When this is rewritten, I would strongly suggest that we find a way to
make 'gettimeofday' nearly free. Certain applications need to use this
frequently while still being portable. One solution when you do have
clock ticks is a read-only mapped Int. Another cheap solution is
library assembly
Just for your information we have a project going that is trying to come
up with a good solution for all of this:
http://sourceforge.net/projects/high-res-timers
We have a mailing list there where we have discussed much of the same
stuff. The mailing list archives are available at sourceforge.
Alan Cox wrote:
> > > This is an X issue. I was talking with Jim Gettys about what is needed to
> > > get the relevant existing X extensions for this working
> >
> > Last time I looked at XF86DGA (years ago), it seemed to have the right
> > hooks in place. Just a matter of server
> > This is an X issue. I was talking with Jim Gettys about what is needed to
> > get the relevant existing X extensions for this working
>
> Last time I looked at XF86DGA (years ago), it seemed to have the right
> hooks in place. Just a matter of server implementation. My
> recollection is
On Tue, Apr 10, 2001 at 04:43:36AM -0700, David Schleef wrote:
> However, on machines without a monotonically increasing counter,
> i.e., the TSC, you have to use 8254 timer 0 as both the timebase
> and the interval counter -- you end up slowly losing time because
> of the race condition between
Alan Cox wrote:
> > Games would like to be able to page flip at vertical refresh time --
> > <1ms accuracy please. Network traffic shaping benefits from better than
>
> This is an X issue. I was talking with Jim Gettys about what is needed to
> get the relevant existing X extensions for this
> Games would like to be able to page flip at vertical refresh time --
> <1ms accuracy please. Network traffic shaping benefits from better than
This is an X issue. I was talking with Jim Gettys about what is needed to
get the relevant existing X extensions for this working
-
To unsubscribe
Mikulas Patocka wrote:
> Timers more precise than 100HZ aren't probably needed - as MIN_RTO is 0.2s
> and MIN_DELACK is 0.04s, TCP would hardly benefit from them.
Indeed, using precise timers for TCP would probably degrade performance
-- you should process a group of timer events together, when
> Timers more precise than 100HZ aren't probably needed - as MIN_RTO is 0.2s
> and MIN_DELACK is 0.04s, TCP would hardly benefit from them.
There are a considerable number of people who really do need 1Khz resolution.
Midi is one of the example cases. That doesn't mean we have to go to a 1KHz
>BTW. Why we need to redesign timers at all? The cost of timer interrupt
>each 1/100 second is nearly zero (1000 instances on S/390 VM is not common
>case - it is not reasonable to degradate performance of timers because of
>this).
The cost of the timer interrupts on a single image system is
Mikulas Patocka wrote:
> BTW. Why we need to redesign timers at all? The cost of timer interrupt
> each 1/100 second is nearly zero (1000 instances on S/390 VM is not common
> case - it is not reasonable to degradate performance of timers because of
> this).
>
> Timers more precise than 100HZ
On Tue, Apr 10, 2001 at 04:10:28PM +0200, Mikulas Patocka wrote:
> Timers more precise than 100HZ aren't probably needed - as MIN_RTO is 0.2s
> and MIN_DELACK is 0.04s, TCP would hardly benefit from them.
On networking bandwidth shaping and traffic control generally need higher precision
1 - 100 of 183 matches
Mail list logo
