And the "circumstances that you have described" have nothing to do with modern computing, so as I said, its irrelevant.
-----Original Message----- From: Anthony Atkielski <[EMAIL PROTECTED]> To: freebsd-questions@freebsd.org Sent: Tue, 29 Mar 2005 00:03:07 +0200 Subject: Re: hyper threading.
[EMAIL PROTECTED] writes:
Do you know how MAX_INTS and Device Polling work?
I know how device polling works. MAX_INTS is the sort of identifier that probably occurs in seven trillion lines of code in the world, so I have no idea what it means.
I can tell that you don't so why are you blabbering about how you kludged an ancient operating system to work-around poorly designed hardware?
I didn't say anything about an operating system.
First of all, with original 8250 "PC" serial ports, polling wouldn't have worked because there was no buffering.
No buffering was necessary. Even the oldest devices held the most recent character latched in the register, and that's what I picked up. It wasn't necessary to buffer the characters, as I picked them up as soon as they came in ... even at 38,400 bps.
So there were no "chunks" to deal with.
The chunks I had in mind had nothing to do with the incoming serial data. They were outstanding tasks divided into small blobs that could be handled between two polls of the serial port. Most of them involved things like writing data to the display, scrolling or clearing the display, and emptying and processing the keyboard buffer, not to mention transmitting outgoing data as required.
Which is why someone probably told you it was "impossible".
They thought it was impossible because they had never thought of just polling the port. With interrupt-driven I/O, it _was_ impossible. But I just decided to stop using interrupts to eliminate that problem.
If your MB had a later design, such as a 16550, then you could poll and gain some efficiency.
I allowed for buffered input, as I recall, but the PCs I used it on didn't have that, and it would work without it.
HOWEVER, modern controllers have much buffering, and the ability to moderate interrrupts. With polling you have a minimum constant overhead, even with no traffic.
That's right, but it's a low overhead, compared to the overhead of interrupt service.
Using interrupt moderation, you get the best of both worlds, because the contollers will only interrupt at a pre-set "safe" interval, and there is no additional overhead. And when there is no traffic there are no interrupts.
I'm sure that's appropriate in some cases. In my case, it wasn't necessary.
So if you have good hardware, polling has negative effects on performance. It ads overhead for no additional benefit.
Polling improves performance in the circumstances I've described. The extra overhead is irrelevant as long as the system is less than 100% busy.
-- Anthony
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
