Lee Revell wrote:
On Mon, 2004-07-12 at 19:31, Andrew Morton wrote:
OK, thanks. The problem areas there are the timer-based route cache
flushing and reiserfs.
We can probably fix the route caceh thing by rescheduling the timer after
having handled 1000 routes or whatever, although I do wonder if this is a
thing we really need to bother about - what else was that machine up to?
Gnutella client. Forgot about that. I agree, it is not reasonable to
expect low latency with this kind of network traffic happening. I am
impressed it worked as well as it did.
Why not reasonable ? It is very important that networking and HD I/O both don't interfere with low latency audio.
Think about large audio setups where you use PC hardware to act as dedicated samplers, software synthesizers etc.
Such clusters might be diskless and communicate with a GBit ethernet with a high performance file server and
in some cases lots of network I/O might occur during audio playback. So having latency spikes during network I/O
would be a big showstopper for many apps in certain setups.
Even ardour if run on a diskless client would need low latency while doing network I/O because it does lots of disk I/O
which on the diskless client translate to lots of network I/O.
Typical use could be educational or research institutions where diskless clients drastically lower the cost of managing large number
of boxes and allow sharing of resources. See the LTSP project.