darcy@druid.net (D'Arcy J.M. Cain) wrote:
> Thus spake Onno van der Linden
>> 'people' most certainly includes me, and when I made my first
>> patches (based on message from Bill Wells to current-users) I was
>> able to do 115200 bps on a null modem cable between two 486DX2's
>> that had 8250s in 'em.

> I'm getting overflows at 28.8K on a DX2/66 486.
[ ... ]
>> One request at the end of all this: if someone still has problems
>> with overflows on x86 machines can they please give a very accurate
>> description of the situation (software, hardware and processes that
>> are running) in which the overflows occur.

> The system has two ethernet cards and there is a fair amount of traffic
> but it still seems odd that it can't handle a 28.8K connection.

> Well, besides what I mentioned above, this is a gateway machine with one
> 28.8K PPP user.  It is running routed and not much else.  No web, ftp or
> logins except for maintenance by me.

I assume this is with a recent com.c (the one running at IPL_SERIAL).
You could try running with FIFO_TRIGGER_1 instead of 4 or 8. This
will increase the interrupt rate a lot but might decrease the overflow
situation.

> I wonder about the following bit of code in that routine:
>
>            /*
>             * If we're out of space, throw away any further input.
>             */

 My patches never had input flow control / input overflow check in them
because 
(1) I was too lazy to write them and
(2) I choose the buffers so big that it was highly unlikely they would
    ever overflow.

However, I don't think a couple of extra instructions in the comintr()
routine matter that much to the overall performance. The main
trouble in the overflow case is always that something else is locking out
the serial interrupt. I've seen interrupt routines in drivers that
completely block out all the other interrupts by using cli (clear interrupt
enable) and sti (set interrupt enable).

Onno