Date: Mon, 7 Jan 2002 17:20:02 -0800 (PST) From: "David S. Madole" <david@madole.net> To: freebsd-bugs@FreeBSD.org Subject: kern/32338: Network to disk write performance low under ATA with DMA Message-ID: <200201080120.g081K2m91094@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/32338; it has been noted by GNATS.
From: "David S. Madole" <david@madole.net>
To: <luigi@FreeBSD.org>, <sos@freebsd.dk>, <wpaul@freebsd.org>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>
Subject: kern/32338: Network to disk write performance low under ATA with DMA
Date: Mon, 7 Jan 2002 20:13:19 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_0016_01C197B7.BFC2AB60
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 8bit
>===== Original Message From sos@freebsd.dk =====
>It seems David S Madole wrote:
>> >Description:
>> Data transfers from network to ATA hard drive are very slow. Visible
>> with Samba, HTTP PUT, etc., but most easily demonstrated with FTP.
>> Only occurs when DMA is enabled on the ATA controller.
>>
>> Interestingly, only seems to happen when network data is being written
>> to the drive. Doing a large write to the drive while simultaneously
>> doing a 'ping -f -s 1400' to another node from another session does
>> not slow the disk writes significantly.
>>
>> The drive is a Maxtor 60GB (model number in included dmesg). NIC is
>> NetGear with sis driver, although same problem occurs with LinkSys
>> card on dc driver. Also occurs with older Maxtor 6GB drive.
>
>Hmm, this sounds like the SiS network card may be using DMA too
>and badly at that, making the net card and the ATA driver
>compete for the bus...
( my apologies if anyone has received this already, but I don't think the
copy I sent previously went out correctly since it never showed up on
gnats
and I was having mail trouble for a few days )
Bill, I copied you since this is your driver.
Luigi, I apologize if inappropriate to copy you on this, but I see you've
been
active in the sis driver lately and thought you might be interested.
Søren, thanks for the response. As I mentioned before, I did have this
problem with the dc driver as well, on an ADMtek AN985.
It turns out that the NIC was unable to DMA it's FIFO into memory fast
enough,
causing it to overflow and packets to get lost, throttling back TCP. It
seems
that my BIOS initializes the PCI latency timer on the card to 32, which
doesn't let it move enough data at a time to keep up with 100Mbs while
competing with the ATA controller.
I am heistant to second-quess every BIOS, so I decided to try an adaptive
approach and bump the timer up a little bit (32) each time an overflow
occurs.
On my machine, once it reaches 96 the card is stable and never overflows
again. This increased my FTP-to-disk throughput to a little over 9MBps,
pretty
good. I also changed the driver to not reinitialize the card when an
overflow
or receive error occurs -- it seems unnecessary and takes a relatively long
time, causing many packets to get lost.
I also adjusted some NIC settings particular to the National chip to make
them
conditional on the silicon version, as the latest datasheet specifies. I'm
guessing it doesn't really matter much since these are probably just
defaults
on the later chips.
I think some other DMA-based NIC drivers, like dc could probably benefit
from
this as well. I can fix up the dc driver as well, if this seems like the
best
way to go, and see if it fixes the issue there, too.
By the way, the attached diff is against 4.4-RELEASE.
Thanks,
Dave
------=_NextPart_000_0016_01C197B7.BFC2AB60
Content-Type: text/plain;
name="diff_sis.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="diff_sis.txt"
*** if_sisreg.h.orig Wed Feb 21 22:17:51 2001=0A=
--- if_sisreg.h Thu Nov 29 19:28:35 2001=0A=
***************=0A=
*** 76,81 ****=0A=
--- 76,82 ----=0A=
=0A=
/* NS DP83815 registers */=0A=
#define NS_CLKRUN 0x3C=0A=
+ #define NS_SRR 0x58=0A=
#define NS_BMCR 0x80=0A=
#define NS_BMSR 0x84=0A=
#define NS_PHYIDR1 0x88=0A=
***************=0A=
*** 401,406 ****=0A=
--- 402,408 ----=0A=
struct sis_list_data *sis_ldata;=0A=
struct sis_ring_data sis_cdata;=0A=
struct callout_handle sis_stat_ch;=0A=
+ device_t sis_dev;=0A=
};=0A=
=0A=
/*=0A=
*** if_sis.c.orig Wed Feb 21 22:17:51 2001=0A=
--- if_sis.c Thu Nov 29 19:41:31 2001=0A=
***************=0A=
*** 723,728 ****=0A=
--- 723,730 ----=0A=
unit =3D device_get_unit(dev);=0A=
bzero(sc, sizeof(struct sis_softc));=0A=
=0A=
+ sc->sis_dev =3D dev;=0A=
+ =0A=
if (pci_get_device(dev) =3D=3D SIS_DEVICEID_900)=0A=
sc->sis_type =3D SIS_TYPE_900;=0A=
if (pci_get_device(dev) =3D=3D SIS_DEVICEID_7016)=0A=
***************=0A=
*** 1159,1166 ****=0A=
void sis_rxeoc(sc)=0A=
struct sis_softc *sc;=0A=
{=0A=
sis_rxeof(sc);=0A=
- sis_init(sc);=0A=
return;=0A=
}=0A=
=0A=
--- 1161,1183 ----=0A=
void sis_rxeoc(sc)=0A=
struct sis_softc *sc;=0A=
{=0A=
+ int latency;=0A=
+ =0A=
+ /*=0A=
+ * The BIOS may have initialized the maximum latency timer=0A=
+ * too low to be able to keep up with a 100Mbs stream when=0A=
+ * heavy disk or other DMA is taking place. Try to correct=0A=
+ * for this adaptively by bumping it up a little each time=0A=
+ * the receive FIFO overflows.=0A=
+ */=0A=
+ =0A=
+ latency =3D pci_read_config(sc->sis_dev, PCIR_LATTIMER, 1);=0A=
+ if (latency < 255) {=0A=
+ if ((latency +=3D 32) > 255) latency =3D 255;=0A=
+ pci_write_config(sc->sis_dev, PCIR_LATTIMER, latency, 1);=0A=
+ }=0A=
+ =0A=
sis_rxeof(sc);=0A=
return;=0A=
}=0A=
=0A=
***************=0A=
*** 1293,1305 ****=0A=
sis_txeof(sc);=0A=
=0A=
if ((status & SIS_ISR_RX_DESC_OK) ||=0A=
! (status & SIS_ISR_RX_OK))=0A=
sis_rxeof(sc);=0A=
=0A=
! if ((status & SIS_ISR_RX_ERR) ||=0A=
! (status & SIS_ISR_RX_OFLOW)) {=0A=
sis_rxeoc(sc);=0A=
- }=0A=
=0A=
if (status & SIS_ISR_SYSERR) {=0A=
sis_reset(sc);=0A=
--- 1310,1321 ----=0A=
sis_txeof(sc);=0A=
=0A=
if ((status & SIS_ISR_RX_DESC_OK) ||=0A=
! (status & SIS_ISR_RX_OK) ||=0A=
! (status & SIS_ISR_RX_ERR))=0A=
sis_rxeof(sc);=0A=
=0A=
! if (status & SIS_ISR_RX_OFLOW)=0A=
sis_rxeoc(sc);=0A=
=0A=
if (status & SIS_ISR_SYSERR) {=0A=
sis_reset(sc);=0A=
***************=0A=
*** 1562,1569 ****=0A=
* performance." Note however that at least three=0A=
* of the registers are listed as "reserved" in=0A=
* the register map, so who knows what they do.=0A=
*/=0A=
! if (sc->sis_type =3D=3D SIS_TYPE_83815) {=0A=
CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001);=0A=
CSR_WRITE_4(sc, NS_PHY_CR, 0x189C);=0A=
CSR_WRITE_4(sc, NS_PHY_TDATA, 0x0000);=0A=
--- 1578,1593 ----=0A=
* performance." Note however that at least three=0A=
* of the registers are listed as "reserved" in=0A=
* the register map, so who knows what they do.=0A=
+ *=0A=
+ * An appararently later version (December 2000)=0A=
+ * has this data on page 78 and qualifies it as=0A=
+ * applying only to silicon version 203h, which=0A=
+ * is aparently a typo'd reference to version 302h=0A=
+ * as referred to on page 64.=0A=
*/=0A=
! if (sc->sis_type =3D=3D SIS_TYPE_83815 &&=0A=
! CSR_READ_4(sc, NS_SRR) =3D=3D 0x0302) {=0A=
! =0A=
CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001);=0A=
CSR_WRITE_4(sc, NS_PHY_CR, 0x189C);=0A=
CSR_WRITE_4(sc, NS_PHY_TDATA, 0x0000);=0A=
------=_NextPart_000_0016_01C197B7.BFC2AB60--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201080120.g081K2m91094>