Messages in this thread | | | Date | Tue, 14 Mar 2000 16:15:50 +0100 | From | Jamie Lokier <> | Subject | Re: 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/
| |