# NIC stuck in 10Mbit?

## cmay4

I recently converted my my last Windows box to Gentoo (yah!), and I am seeing some odd behavior.  I used to connect to a Gentoo server from an XP machine using Samba and got great transfer rates.  Now when I connect using a Gentoo box, my transfer rates are way down.  

I tried FTPing a file from the server to the workstation (just over the LAN) and I got the following:

```
ftp> get BIGFILE

local: BIGFILE remote: BIGFILE

200 PORT command successful

150-Connecting to port 34606

150 716766.0 kbytes to download

226-File successfully transferred

226 244.918 seconds (measured here), 2.86 Mbytes per second

```

I should be getting alot more than 2.86 Mb/sec.  That looks like I am running in 10Mbit mode.  Right?

I started to look at the network configuration and messages and found some odd differences.

On my server:

```
$ cat /proc/pci | egrep -i ethernet

    Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 34).

$ dmesg | grep eth0

eth0: Digital DS21140 Tulip rev 34 at 0xe400, 00:40:05:A2:CD:B7, IRQ 11.

eth0: Setting full-duplex based on MII#0 link partner capability of 45e1.

$ ifconfig

eth0      Link encap:Ethernet  HWaddr 00:40:05:A2:CD:B7

          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:669549 errors:1 dropped:0 overruns:0 frame:0

          TX packets:868253 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100

          RX bytes:146803406 (140.0 Mb)  TX bytes:1112462497 (1060.9 Mb)

          Interrupt:11 Base address:0xe400

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:8522 errors:0 dropped:0 overruns:0 frame:0

          TX packets:8522 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:2357840 (2.2 Mb)  TX bytes:2357840 (2.2 Mb)

$ mii-diag eth0

Basic registers of MII PHY #0:  1000 782d 7810 0000 01e1 45e1 0001 0000.

 The autonegotiated capability is 01e0.

The autonegotiated media type is 100baseTx-FD.

 Basic mode control register 0x1000: Auto-negotiation enabled.

 You have link beat, and everything is working OK.

 Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.

   End of basic transceiver information.

```

On my workstation:

```
$ cat /proc/pci | egrep -i ethernet

    Ethernet controller: Davicom Semiconductor, Inc. Ethernet 100/10 MBit (rev 49).

$ dmesg | grep eth0

eth0: Davicom DM9009 at pci00:07.0, 00:01:53:80:41:e8, irq 10.

$ ifconfig

eth0      Link encap:Ethernet  HWaddr 00:01:53:80:41:E8

          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:895082 errors:0 dropped:0 overruns:0 frame:0

          TX packets:640554 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100

          RX bytes:1176644375 (1122.1 Mb)  TX bytes:103401462 (98.6 Mb)

          Interrupt:10 Base address:0xe800

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:9362 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9362 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:3974074 (3.7 Mb)  TX bytes:3974074 (3.7 Mb)

$ mii-diag eth0

SIOCGMIIPHY on eth0 failed: Operation not supported

```

On the workstation, there is no full duplex line in dmesg and I cannot get output from mii-diag.  I am concerned that the card is running at 10Mbit instead of 100.  Does anyone know how I can tell?

ChuckLast edited by cmay4 on Wed Sep 03, 2003 8:28 pm; edited 1 time in total

----------

## Jeedo

modinfo module-names, dmfe for the davicom one

----------

## cmay4

 *Jeedo wrote:*   

> modinfo module-names, dmfe for the davicom one

 

I have the dmfe compiled in the kernel, not as a module.  So the output looks like:

```
$ modinfo dmfe

modinfo: dmfe: no module by that name found

$ lsmod

Module                  Size  Used by    Tainted: P

svgalib_helper          7628   0  (autoclean)

snd-pcm-oss            39940   0  (autoclean)

snd-mixer-oss          13848   0  (autoclean) [snd-pcm-oss]

snd-emu10k1            73460   0

snd-rawmidi            15072   0  [snd-emu10k1]

snd-util-mem            1408   0  [snd-emu10k1]

snd-pcm                65024   0  [snd-pcm-oss snd-emu10k1]

snd-timer              15880   0  [snd-pcm]

snd-page-alloc          5292   0  [snd-emu10k1 snd-pcm]

snd-ac97-codec         37888   0  [snd-emu10k1]

snd-seq-device          4448   0  [snd-emu10k1 snd-rawmidi]

snd-hwdep               5280   0  [snd-emu10k1]

snd                    32644   0  [snd-pcm-oss snd-mixer-oss snd-emu10k1 snd-rawmidi snd-util-mem snd-pcm snd-timer snd-ac97-codec snd-seq-device snd-hwdep]

soundcore               4164   8  [snd]

ezusb2131              11924   0

nvidia               1542336  10
```

I wouldn't think it would matter whether it was compiled in or built as a module.

----------

## Jeedo

well it does matter , because you can pass options to it if it's a module, see:

/usr/src/linux/Documentation/networking/dmfe.txt

im going to quote a part of it here:

 *Quote:*   

> 
> 
>         2. Insert dmfe module into kernel
> 
>            "insmod dmfe"        ;;Auto Detection Mode (Suggest)
> ...

 

im sure your other card supports that as well[/quote]

----------

## cmay4

Ok...I recompiled the kernel with dmfe as a module and added the following line to /etc/modules.autoload.d/kernel-2.4:

```
dmfe mode=5
```

and dmesg looks like this:

```
eth0: Davicom DM9009 at pci00:07.0, 00:01:53:80:41:e8, irq 10.

eth0: Tx timeout - resetting

eth0: Tx timeout - resetting
```

I assume the "resetting" lines are not good.  Here is the transfer again:

```
ftp> get BIGFILE

local: BIGFILE remote: BIGFILE

200 PORT command successful

150-Connecting to port 32777

150 716766.0 kbytes to download

226-File successfully transferred

226 224.347 seconds (measured here), 3.12 Mbytes per second
```

Better, but still seems very slow.  Does anyone know what I should expect over 100Mbit?

Chuck

----------

## cmay4

I set up an NFS server and mounted the shares on the client.  Here are the results:

```
Client rpc stats:

calls      retrans    authrefrsh

50817      40750      0

Client nfs v2:

null       getattr    setattr    root       lookup     readlink

0       0% 7546   18% 3       0% 0       0% 1745    4% 0       0%

read       wrcache    write      create     remove     rename

21541  53% 0       0% 9507   23% 3       0% 3       0% 4       0%

link       symlink    mkdir      rmdir      readdir    fsstat

0       0% 0       0% 0       0% 0       0% 50      0% 7       0%
```

Does that really mean that 80% of the calls are retransmitted?

I'm beginning to think I just need to get a new network card.  Has anyone else seen something like this?

----------

## Jeedo

dont be so quick to blame it on your network card, your speed can be hampered by lots of other things, slow hubs/switches, crappy cables and so on.. just a thought

----------

## cmay4

 *Jeedo wrote:*   

> dont be so quick to blame it on your network card, your speed can be hampered by lots of other things, slow hubs/switches, crappy cables and so on.. just a thought

 

You're right, except that I just moved from WinXP to Gentoo on that box.  The Samba transfer speeds I used to get under WinXP were very fast (I don't have the actual numbers, but they were MUCH faster).  Also, when I look at the router, the 100Mbit is lit up on that connection, so it thinks it is in 100Mbit mode.

I'm really running out of ideas.  Do you have any suggestions for a well-supported NIC under Gentoo?  My server uses the tulip driver which has never given me any troubles.

Thanks for the help,

Chuck

----------

## Ox-

Well, if you don't think it's the router (maybe one of the hub/switch ports went bad?), then it's got to be either the dmfe driver or the card is on the fritz.

Getting an error with mii-diag kind of makes me lean towards the driver (it's either broken or isn't the one you should be using).

Btw, I don't get a "full duplex" message in dmesg either with the eepro100 driver, so that's just a benefit of the tulip driver nicely informing you what the result of negotiations were.

I haven't used any drivers other than tulip or eepro100 myself, but have never had problems with either.

So, I think you should try switching to a different port on the router on the slim chance that's the problem, then buy a better supported card.  Keep the davicom card though in case you have another Windows machine.

----------

## Ox-

Oh, what do you get from mii-tool?

I get

```
# mii-tool

eth0: negotiated 100baseTx-FD flow-control, link ok
```

----------

## cmay4

 *Ox- wrote:*   

> Oh, what do you get from mii-tool?
> 
> I get
> 
> ```
> ...

 

About the same thing I get from mii-diag:

```
$ mii-tool

SIOCGMIIPHY on 'eth0' failed: Operation not supported

no MII interfaces found
```

I can't figure out what that error is telling me?

----------

## think4urs11

try 

```
ethtool eth0
```

----------

## cmay4

 *Think4UrS11 wrote:*   

> try 
> 
> ```
> ethtool eth0
> ```
> ...

 

Still no information:

```
$ ethtool eth0

Settings for eth0:

No data available
```

Something just ain't right...

Chuck

----------

## cmay4

Ok...bit the bullet and bought a new NIC.  I picked up a Netgear FA311, which run with the natsemi driver.  Here is what I get now:

```
# cat /proc/pci | egrep -i ethernet

    Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller (rev 0).

# dmesg | grep eth0

eth0: NatSemi DP8381[56] at 0xe0802000, 00:09:5b:20:4e:04, IRQ 10.

eth0: link up.

eth0: Setting full-duplex based on negotiated link capability.

# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:09:5B:20:4E:04

          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:511497 errors:0 dropped:264 overruns:0 frame:0

          TX packets:249544 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100

          RX bytes:770170609 (734.4 Mb)  TX bytes:16625558 (15.8 Mb)

          Interrupt:10 Base address:0x2000

                                                                                                                                

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:1444 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1444 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:105896 (103.4 Kb)  TX bytes:105896 (103.4 Kb)

                                                                                                                                

# mii-diag eth0

Basic registers of MII PHY #1:  3100 786d 2000 5c21 05e1 45e1 0005 2801.

 The autonegotiated capability is 01e0.

The autonegotiated media type is 100baseTx-FD.

 Basic mode control register 0x3100: Auto-negotiation enabled.

 You have link beat, and everything is working OK.

 Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.

   End of basic transceiver information.

                                                                                                                                

# mii-tool

eth0: negotiated 100baseTx-FD flow-control, link ok
```

My transfer rate is a bit higher as well:

```
ftp> get BIGFILE

local: BIGFILE remote: BIGFILE

200 PORT command successful

150-Connecting to port 32901

150 716766.0 kbytes to download

226-File successfully transferred

226 198.831 seconds (measured here), 3.52 Mbytes per second
```

Although I would have thought over the LAN I would get a better transfer rate.  Does anyone know what speed I should get over 100Mbit?

Thanks for everyone's help,

Chuck

----------

## janlaur

I dont really know weather this i relavent, but i was also stuck at around 2.7 mb/sec. Later i found out that dma was diabled on my harddrive, becouse i forgot to compile support for my ide controller. Try testing your harddrive with 

```
hdparm -Tt /dev/hdX
```

 It's the second value that counts

----------

## cmay4

It's funny you should mention that.  I actually realized that I wasn't running in DMA mode yester day.  I now get:

```
ftp> get BIGFILE

local: BIGFILE remote: BIGFILE

200 PORT command successful

150-Connecting to port 37599

150 716766.0 kbytes to download

226-File successfully transferred

226 76.311 seconds (measured here), 9.17 Mbytes per second
```

I think I am getting pretty lousy hard drive numbers:

Workstation:

```
# hdparm -Tt /dev/hda

 

/dev/hda:

 Timing buffer-cache reads:   1024 MB in  2.00 seconds = 510.72 MB/sec

 Timing buffered disk reads:   32 MB in  3.07 seconds =  10.42 MB/sec
```

Server:

```
# hdparm -Tt /dev/hda

 

/dev/hda:

 Timing buffer-cache reads:   604 MB in  2.00 seconds = 301.25 MB/sec

 Timing buffered disk reads:   52 MB in  3.04 seconds =  17.13 MB/sec
```

Looks like that could be the limiting factor.  I need to start researching that.

Chuck

----------

## Ox-

Er yeah  :Smile: 

My machine is only 866Mhz and here's the numbers I get:

```
# hdparm -Tt /dev/hda

/dev/hda:

 Timing buffer-cache reads:   656 MB in  2.01 seconds = 326.37 MB/sec

 Timing buffered disk reads:  124 MB in  3.03 seconds =  40.92 MB/sec
```

But, you're probably still not going to see much higher numbers on your network throughput.  Unless I'm forgetting something 9.17 Mbytes per second should be pretty close to your ceiling.

----------

## cmay4

Well, after reading some other posts, I added the VIA chipset to my kernel options and rebuilt the kernel.  Now when I boot I don't get the DMA warning, and my numbers are a bit better:

```
# hdparm -Tt /dev/hda

 

/dev/hda:

 Timing buffer-cache reads:   1052 MB in  2.00 seconds = 526.00 MB/sec

 Timing buffered disk reads:   46 MB in  3.07 seconds =  14.98 MB/sec
```

One thing that I do not understand is why hdparm isn't reporting which mode I am running in:

```
# hdparm -i /dev/hda

 

/dev/hda:

 

 Model=Maxtor 33073H3, FwRev=YAH814Y0, SerialNo=L3H9F5PC

 Config={ Fixed }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57

 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=60032448

 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}

 PIO modes:  pio0 pio1 pio2 pio3 pio4

 DMA modes:  mdma0 mdma1 mdma2

 UDMA modes: udma0 udma1 udma2

 AdvancedPM=yes: disabled (255) WriteCache=enabled

 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 0:

 

 * signifies the current active mode

```

I think I am in udma5, but it isn't listed, and nothing has a "*" next to it.

----------

## btg308

Try hdparm -I /dev/hda instead. It reads the data fresh off the drive and presents it in another format.

```
obelix portage # hdparm -i /dev/ide/host0/bus1/target0/lun0/disc

/dev/ide/host0/bus1/target0/lun0/disc:

 Model=ST380023A, FwRev=3.30, SerialNo=3KB018H7

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4

 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488

 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}

 PIO modes:  pio0 pio1 pio2 pio3 pio4

 DMA modes:  mdma0 mdma1 mdma2

 UDMA modes: udma0 udma1 udma2

 AdvancedPM=no WriteCache=enabled

 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:

 * signifies the current active mode
```

vs

```
obelix portage # hdparm -I /dev/ide/host0/bus1/target0/lun0/disc

/dev/ide/host0/bus1/target0/lun0/disc:

ATA device, with non-removable media

        Model Number:       ST380023A

        Serial Number:      3KB018H7

        Firmware Revision:  3.30

Standards:

        Used: ATA/ATAPI-6 T13 1410D revision 2

        Supported: 6 5 4 3

Configuration:

        Logical         max     current

        cylinders       16383   16383

        heads           16      16

        sectors/track   63      63

        --

        CHS current addressable sectors:   16514064

        LBA    user addressable sectors:  156301488

        device size with M = 1024*1024:       76319 MBytes

        device size with M = 1000*1000:       80026 MBytes (80 GB)

Capabilities:

        LBA, IORDY(can be disabled)

        bytes avail on r/w long: 4      Queue depth: 1

        Standby timer values: spec'd by Standard

        R/W multiple sector transfer: Max = 16  Current = 16

        Recommended acoustic management value: 128, current value: 128

        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=240ns  IORDY flow control=120ns

Commands/features:

        Enabled Supported:

           *    READ BUFFER cmd

           *    WRITE BUFFER cmd

           *    Host Protected Area feature set

           *    Look-ahead

           *    Write cache

           *    Power Management feature set

                Security Mode feature set

           *    SMART feature set

           *    Mandatory FLUSH CACHE command

           *    Device Configuration Overlay feature set

           *    Automatic Acoustic Management feature set

                SET MAX security extension

           *    DOWNLOAD MICROCODE cmd

           *    SMART self-test

           *    SMART error logging

Security:

        Master password revision code = 65534

                supported

        not     enabled

        not     locked

        not     frozen

        not     expired: security count

        not     supported: enhanced erase

HW reset results:

        CBLID- below Vih

        Device num = 0 determined by the jumper

Checksum: correct
```

Note that the -I tells me the mode, -i doesn't (for this drive, some of my drives tells it even in -i).

Oh, and while we're at it:

```
obelix portage # hdparm -Tt  /dev/ide/host0/bus1/target0/lun0/disc

/dev/ide/host0/bus1/target0/lun0/disc:

 Timing buffer-cache reads:   904 MB in  2.00 seconds = 452.00 MB/sec

 Timing buffered disk reads:  110 MB in  3.02 seconds =  36.42 MB/sec
```

Also, please note that measuring real network speeds in megabytes and comparing that against fictional signaling speeds measured in megabits may be detrimental to your mental health and the stability of your system. ;-)

----------

