lkml.org 
[lkml]   [2000]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: new IRQ scalability changes in 2.3.48
Thomas Sailer wrote:
> > Aye, but softmodem drivers will be run on non-RTLinux systems. Because
> > it's simply for users who want to use their winmodems. And it would
> > like a bounded latency please during 99.9% of all seconds (hard RT not
>
> Now tell me where in your softmodem setup you need 0.5ms latencies,
> especially if the analog path already gives you several ms latency.

You don't. I said _bounded_ latency. 20ms is fine. But 20ms with a
100ms spike every few seconds is not, unless you know in advance you're
going to get 100ms spikes.

A softmodem can cope with quite a large response latency, provided you
can keep feeding the Tx buffer (almost) all the time.

And if you have a bound on the latency, even up to half a second or
more, that's fine too. After all, a satellite analogue link can
introduce that much. (Though you'd have problems with a half second
local latency _and_ a satellite link together :-)

Your "interactive experience" with the modem is going to be worse the
larger you keep your Tx buffer. I.e., you type, and the Tx buffer
latency is at 100ms -- that's 100ms more time before the character comes
back to you. Ditto Quake players.

You can get clever, and prefill the Tx buffer to keep a large one full
but overwrite the prefill most of the time. That's possible, but has
plenty of potential for CPU wastage. Or you can move more of the Tx
modulator into kernel space and run it off the modem device's interrupt,
or on the modem hardware if it supports that. Interrupt latency is
usually lower than scheduling latency. (It's not like we'll be doing
any _better_ than interrupt latency after all). That's another
possibilty.

But let's suppose we would like to run one in user space, and we'd like
not to generate signals which we're going to overwrite.

Then, you want to get a fairly reliable bound on your process scheduling
latency, to give the best interactive performance for a given reliability.

You can do that nicely by simply measuring latencies as you run. If you
get a long run and they're all <20ms, great, set your Tx buffer to empty
20ms after its nominal fill time.

But that's not so nice because that will work fine for ages until
someone starts Netscape (or anything else which swaps). And all of a
sudden you're getting 100ms latency spikes. Your modem transmits junk
for 80ms and then you recalibrate: "I had a spike at 100ms, let's
maintain 150ms of Tx from now on". You update all your parameters,
adjust echo etc. for the new delay, request a partial retrain (which
takes a little while) and hope the other end didn't drop the connection
(sometimes they do, sometimes they don't).

Again, fine if it is rare. (But I don't think it is).

That leaves just two reasons to desire low latency for a user space
softmodem. They aren't strictly _necessary_, but they improve
performance:

- Your estimated latency bound affects interactive performance.
A smaller bound makes for happier Quake players and ssh users.

- Unexpected large spikes are bad. I'd be pretty happy with a
reliable bound of 10ms. But 100ms spikes aren't nice at all, and
assuming 100ms Tx queue in the first place isn't nice for those
Quake players.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.160 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site