From owner-freebsd-bugs Mon Jan 7 17:20:53 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 4C43E37B416 for ; Mon, 7 Jan 2002 17:20:02 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g081K2m91094; Mon, 7 Jan 2002 17:20:02 -0800 (PST) (envelope-from gnats) Date: Mon, 7 Jan 2002 17:20:02 -0800 (PST) Message-Id: <200201080120.g081K2m91094@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "David S. Madole" Subject: kern/32338: Network to disk write performance low under ATA with DMA Reply-To: "David S. Madole" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/32338; it has been noted by GNATS. From: "David S. Madole" To: , , Cc: 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