ea9c501856
of associated mbuf clusters) in the RX ring from 4 to 16. On my really fast PI 400Mhz test machines, 4 descriptors (and associated mbuf clusters) is enough to achieve decent performance without any RX overruns. However, one person reported problems with the following scenario: - P90 system running FreeBSD with a 3c905B-TX adapter, slow IDE hard disk (Quantum Bigfoot?) - PII 266 with SCSI disks running LoseNT and also with a 3c905B-TX - Both machines connected together via crossover cable at 100Mbps full-duplex - LoseNT machine writing largs amounts of data (2.5 GB work of files each in the neighborhood of 1 to 2 MB in size) via samba to the FreeBSD machine In this case, the LoseNT machine is sending data very fast. Apparently there weren't any problems initially because the user was writing to one particular disk which was relatively fast, however after this disk filled up and the user started writing to the second slower disk, RX overruns would occur and sometimes the RX DMA engine would stall after a 100 to 500MB had been transfered. The xl_rxeof() handler is supposed to detect this condition and restart the upload engine; I'm not sure why it doesn't, unless interrupts are being lost and the rx handler isn't getting called. This is still an improvement over the Linux driver, which uses 32 descriptors in its receive ring. :) Problem reported by: Heiko Schaefer <hschaefer@fto.de> |
||
---|---|---|
.. | ||
alpha | ||
amd64 | ||
boot | ||
compat | ||
compile | ||
conf | ||
contrib/softupdates | ||
ddb | ||
dev | ||
fs | ||
geom | ||
gnu | ||
i386 | ||
isa | ||
isofs/cd9660 | ||
kern | ||
libkern | ||
miscfs | ||
modules | ||
msdosfs | ||
net | ||
netatalk | ||
netinet | ||
netipx | ||
netkey | ||
netnatm | ||
netns | ||
nfs | ||
nfsclient | ||
nfsserver | ||
pc98 | ||
pccard | ||
pci | ||
posix4 | ||
powerpc | ||
rpc | ||
scsi | ||
sys | ||
tools | ||
ufs | ||
vm | ||
Makefile |