> 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.
Sorry. My mistake. Out by two orders of magnitude.
The actual data rate will be about 15 megabytes per second.
>
> 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.
>
This does explain some of the problems he has been having. I've forwarded
your message; he will look into things further.
-- hendrik.
> 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
>
|