netdev
[Top] [All Lists]

Re: Linux heartbeat

To: Hendrik Boom <hendrik@xxxxxxxxxxxxx>
Subject: Re: Linux heartbeat
From: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Sat, 22 Jul 2000 09:33:41 +1000
Cc: netdev@xxxxxxxxxxx
References: <200007212145.RAA11115@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Run that by me again?  15 megs in 10 millisecs is 1.5 gigabytes per
second.

What is his actual data rate?  It must be enormous.

I suspect that what he is encountering is scheduling stalls which are
much greater than 10 millisecs.  If a process does something like a huge
read() or /bin/sync then all other processes don't get scheduled for up
to 150 millisecs in my experience.

Before your colleague does anything else he should read the linux-kernel
archives for the past 4 weeks.  Search for 'low latency'.  Once he has
absorbed that little bunfight he will be better armed.

He has a requirement for hard realtime.  He has several options:

1: Use a realtime OS

2: Use RTLinux (A realtime OS)

3: Use kernel 2.2 with Ingo Molnar's low-latency patches.  This will
give him approx 2 millisec max latency.

4: Use kernel 2.4 with my low-latency patch.  This is a much simpler
patch and is probably not as reliable as Ingo's.

5: Do it in the kernel and do the realtime stuff at interrupt time.

If he goes with a low-latency Linux patch then his process will need to
give itself SCHED_FIFO scheduling policy, it should use mlockall() to
prevent itself getting paged out and it will require some cooperation
from a device driver which will cause the process to become runnable
promptly.

Whichever way, I believe it would be useful for him to send a
description of his requirements to linux-kernel@xxxxxxxxxxxxxxxxx  But
make sure that he has read the archives beforehand.



Hendrik Boom wrote:
> 
> A friend of mine is having a problem with a high-data-rate
> application which appears to involve developing some new protocols.
> He's preparing a letter with the details.  He tells me the Linux
> scheduler uses a 100-Hz clock, and that isn't fast enough for him.
> By the time the scheduler gets around to the next tick and reconsiders
> whether to execute his process, his 15-meg rotating buffer has overflowed.
> 
> He believes that the proper fix would be for the Linux timer code to be
> rewritten to operate at higher resolution.  He is facing the prospect
> of switching to another OS.
> 
> As I said, he's preparing a letter with the details.  Is this an appropriate
> forum to present it? Or should I send it elsewhere (if so, where?).
> 
> -- hendrik@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>