i'm having a problem with input overruns on fxp devices
on an alpha 164lx.

When i sniff both the sender and receiver, i can see when
the xmitter sends these back to back packets, and i can
see the missing packets on the receiver side, and i've modified
if_fxp.c to display info about the overrun condition approximatly
when it happens.

The overrun errors cause the retransmitter to send more tcp data,
but the retransmission timmer is very course compared to data delivery...

the sympton: we see end-end ftp's (for example) of 100k; 
incredibly slow data rates for 100Mhz eth.

We used fxp's after having performance problems with de's...
not cause we thought fxp's were better, but cause we could then
get an clue about whether it was related to interface-cards.

If i throttle down the sendspace to about 4k, the xmission
goes up from 100k to 4Mbytes- but that then effects all
default connections... on and off net; and its the wrong
solution to the problem.

Has anyone else seen input overrun errors?

I'm not sure we notcied this before 1.3.3... is there new
code somewhere in interrupt processing which would degrade
interrupt response to service fxp?

These are full duplex fxp connections going through a netgear switch.

I've also tried it through two different hubs, and with
direct (crossover) cables between two alphas... [when on the
the connection is half duplex]

If i set the sendspace to 4k, and get the xmission rate up to
3-4MBytes, sometimes one of the fxp cards
peroidically locks up... does it do that in response to errors?

i'm off to see if i can instrument if_de.c to display errors
more aggrevisly, so i can get a better idea about the problems
with the same 100Kb rate between the same alpha's using de.


mts.