Has any else noticed poor tcp performance on 164lx's?

Were still having problems getting mroe than 100Kb/sec
on the alpha 164lx's we've got.  Notice that this is with
both fxp's and de's ... so its not just interface card
related.

We're pretty much stuck trying to figure out what's wrong.
We're willing to make some of the machines with the
problem available for testing to someone who could
figure out what's wrong.


We have also loaded linux on two separate 164lx's and have
done some prelimitary testing... it seems as if linux
does not have the same problem (tho it does suffer from
other ones -- it doesn't like the SRM much).


thanks for any help.



------- Forwarded Message

	by off.to (8.9.1/8.9.1) with ESMTP id KAA10574;
	Fri, 7 May 1999 10:02:11 -0400 (EDT)
Message-Id: <199905071402.KAA10574@off.to>
To: port-alpha@netbsd.org
cc: mts
Subject: reception of 100 mhz packets.
Reply-To: mts@off.to
Date: Fri, 07 May 1999 10:02:11 -0400
From: "Michael T. Stolarchuk" <mts@off.to>


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.

------- End of Forwarded Message