> >Yes it does. And, in fact, a simple real-mode DOS ISR which uses the same
> >hardware (as stated) runs approximately 10 times faster. I get damn tired
> >of having everybody and their brother "explain" that I don't know what
> >I'm doing. I presented true, factual, information. It was not a complaint.
> >It was just fact. Take it or leave it.
>
> I'm not trying to claim that you don't know what you're doing, nor do I
> dispute that your figures are the true results you saw. I was merely
> providing a theory for why your results showed (what appeared to be) rather
> poor performance, and asking whether you had attempted to find the cause for
> yourself.
>
> There's no need to assume that everybody is out to get you every time
> something you write is challenged.
>
Having worked with many drivers in many kinds of Multitasking systems,
I thought Linux performance was rather __good__ . I note that for years,
Sun would't let you set the baud-rate higher than 19200, and VAXen
wouldn't allow greater than 9600. Now, VAXen are dead, most other
modern systems use UARTs with FIFOs, so the baud-rates can be very
high, regardless of some limit imposed by the rate at which interrupts
can be handled on these systems.
In Linux, the kernel does some considerable work before the driver's
ISR is called. This is good. It provides a nice standardized interface
to the ISR with a pointer to the drivers previously-registered stuff, etc.
If the driver's ISR was RAW, i.e., save your own registers, manipulate
the controller(s) yourself, set up your own data, etc., you could probably
run faster. However, usually to do useful work, this stuff has to be done
and I'd much rather have the kernel do it in a controlled standardized way
as it does.
As I said before, none of my tests and measurments were complaints, only
statements of verifiable facts.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
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/