hyper threading.

[Anthony Atkielski]

em1897 at aol.com 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