Linux-Router - 100mbps???
Robert G. Brown
rgb at phy.duke.edu
Tue Mar 19 11:32:42 PST 2002
On Tue, 19 Mar 2002, - ZouL - wrote:
> Hello,
>
> I have for more than a year now an old linux server (133MHZ, 16MB RAM),
> which operates as a router and gateway to the internet for 3 Windows
> clients. Yes, i agree...this is not a very "good" server - anyway, i haven't
> had any problems with it in the past. It worked well (Internet, LAN etc.)
Wrong list, but sure, why not.
Routing/gateway services are moderately CPU intensive. This system is
awfully light on memory and CPU to run 2.4 kernels, which are likely
desirable (since 2.2.16 has a security exploit IIRC, not to mention
dozens of other lesser problems).
RTL 8139 cards really suck. Having it on either end of the connection
can explain a lot of your problem. The slow CPU is especially likely to
be an additional bottleneck for RTL's for reasons you can find in some
of Don Becker's list replies in the list archives (from the last few
months, even, although it is a perennial problem).
Some cards and switches have a hard time with Nway autonegotiation. You
don't say what switch you have, but this is something to check. This
really sounds likely to be a problem from your mii-diag stuff below.
Finally, if you use a useless card like the RTL and do bandwidth tests
on ANY sort of network with problems, they are likely to be greatly
amplified. For example, a UDP/NFS transfer of large blocks may have to
do a whole block over if a single packet in the block stream is
corrupted (TCP is a bit smarter and just asks for a retransmit of the
one bad packet). I found that whacking an RTL with a high speed TCP
stream of packets could cut throughput down to as little as 3-5 Mbps on
a 100 Mbps, presumably because it was dropping most of the incoming
packets and constantly thrashing to have them resent.
So (in order of things to try):
a) Use better network cards, in particular do NOT use RTL's. It might
just be the worst NIC in existence and a waste of money at $10 a card.
b) Use a decent switch (one that properly supports Nway, ditto the
NIC).
c) Upgrade your gateway. C'mon, it's time. Put a bullet through its
head. Give it to a museum. You can BUY a dedicated NAT
gateway/firewall for a small WinXX cluster for order of $100, probably
even one with four or five switched ports on it, from several vendors.
Use your linux desktop as your gateway if need be. Anything.
rgb
>
> But now, i have a really confusing problem:
> I wanted to download some files from it and suddenly i remarked, that there
> is only a 10mbps instead of 100mbps connection between the server and all
> windows clients (CuteFTP -> ca. 1200KB/s). This made me wonder, because i
> had a Davicom 9102 in it, which supported 10/100 mbit/s. I looked at the
> 10/100 switch, which paradoxically indicated a 100 MBits connection. I use
> Kernel 2.2.16 and so I compiled updated drivers...with no success, the
> connection remained 10 mbps.
> Okay, so i changed the davicom card with a realtek (rtl8139A) card from one
> of the windows clients. But same picture: mii-diag, mii-tool and the switch
> "said" there is a negotiated 100baseTx-FDX card with "link ok". Though, the
> data transfer was about 1200KB/s only!
> I was really confused...
> now i used rtl8139-diag and - i don't know why - this prog says, that i have
> a "10mbps half duplex card" with auto-negotiation disabled, even though the
> other progs like mii-diag say something different...
> Then i decided to use TTCP to get clearness. And the result was: Between the
> windows clients there is a connection about 11.000KB/s (in other words ca.
> 100mbps), between a windows client and the server is something about
> 3800KB/s. So more than 10 mbps but not 100 mbps.
>
> UUh? what's that now? Is the server "too old" for 100 mbps? Is somebody out
> there, who has got a solution for this problem? P.S: I even used an
> expensive SMC Ethernet II of a friend for testing...the ttcp result remains
> 3800 KB/s!
> P.P.S: In the system there is a second ethernet interface for the connection
> with the DSL modem. its an old ne2000 compatible. Could this be the problem?
> There aren't any collisions, says ifconfig....
>
> -----
> Outputs:
>
> ifconfig eth0
> eth0 Link encap:Ethernet HWaddr 00:E0:4C:39:18:69
> inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
> inet6 addr: fe80::e0:4c39:1869/10 Scope:Link
> inet6 addr: fe80::2e0:4cff:fe39:1869/10 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:1320 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1288 errors:0 dropped:0 overruns:4 carrier:0
> collisions:0 txqueuelen:100
> Interrupt:10 Base address:0x6000
>
> ./mii-diag
> Using the default interface 'eth0'.
> Basic registers of MII PHY #32: 1100 782d 0000 0000 05e1 45e1 0001 0000.
> The autonegotiated capability is 01e0.
> The autonegotiated media type is 100baseTx-FD.
> Basic mode control register 0x1100: 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.
>
> cat /proc/pci
> PCI devices found:
> Bus 0, device 0, function 0:
> Host bridge: Acer Labs M1489 (rev 0).
> Slow devsel. Master Capable. No bursts.
> Bus 0, device 4, function 0:
> VGA compatible device: S3 Inc. Vision 964-P (rev 0).
> Medium devsel.
> Non-prefetchable 32 bit memory at 0xf8000000 [0xf8000000].
> Bus 0, device 5, function 0:
> Ethernet controller: Realtek 8139 (rev 16).
> Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable.
> Late
> ncy=32. Min Gnt=32.Max Lat=64.
> I/O at 0x6000 [0x6001].
> Non-prefetchable 32 bit memory at 0xf8800000 [0xf8800000].
>
> ./rtl8139-diag -aaeemmf
> rtl8139-diag.c:v2.05 1/28/2002 Donald Becker (becker at scyld.com)
> http://www.scyld.com/diag/index.html
> Index #1: Found a RealTek RTL8139 adapter at 0x6000.
> RealTek chip registers at 0x6000
> 0x000: 394ce000 00006918 88010000 42000000 0010a03c 0010a03c 0010a03c
> 0010a03c
> 0x020: 006c0000 006c0600 006c0c00 006c1200 00700000 0d0a0000 b298b288
> 0000c07f
> 0x040: 73000400 00009c0e 3cf7f940 00000000 006c1400 00000000 0000c180
> 00100000
> 0x060: 1100f00f 05e1782d 000145e1 00000000 00000004 000207c0 78fa8388
> a538de43.
> No interrupt sources are pending.
> The chip configuration is 0x14 0x6c, MII full-duplex mode.
> Decoded EEPROM contents:
> PCI IDs -- Vendor 0x10ec, Device 0x8139.
> PCI Subsystem IDs -- Vendor 0x10ec, Device 0x8139.
> PCI timer settings -- minimum grant 32, maximum latency 64.
> x020: 006c General purpose pins -- direction 0xe1 value 0x11.
> Station Address 00:E0:4C:39:18:69.
> Configuration register 0/1 -- 0x4c / 0xc2.
> EEPROM active region checksum is 0967.
> EEPROM contents (64 words):
> 0x00: 8129 10ec 8139 10ec 8139 4020 e111 e000
> 0x08: 394c 6918 4c14 f7c2 0001 8388 78fa 070a
> 0x10: de43 a538 0000 0000 de43 0000 de43 0000
> 0x18: de43 a438 0000 0000 de43 0000 de43 0000
> 0x20: 0000 ffff ffff ffff ffff ffff ffff ffff
> 0x28: ffff ffff ffff ffff ffff ffff ffff ffff
> 0x30: ffff ffff ffff ffff ffff ffff ffff ffff
> 0x38: ffff ffff ffff ffff ffff ffff ffff ffff
> The RTL8139 does not use a MII transceiver.
> It does have internal MII-compatible registers:
> Basic mode control register 0x1100.
> Basic mode status register 0x782d.
> Autonegotiation Advertisement 0x05e1.
> Link Partner Ability register 0x45e1.
> Autonegotiation expansion 0x0001.
> Disconnects 0x0000.
> False carrier sense counter 0x0000.
> NWay test register 0x0004.
> Receive frame error count 0x0000.
> MII PHY #-1 transceiver registers:
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000.
> Basic mode control register 0x0000: Auto-negotiation disabled!
> Speed fixed at 10 mbps, half-duplex.
> Basic mode status register 0x0000 ... 0000.
> Link status: not established.
> Capable of <Warning! No media capabilities>.
> Unable to perform Auto-negotiation, negotiation not complete.
> This transceiver has no vendor identification.
> I'm advertising 0000:
> Advertising no additional info pages.
> Using an unknown (non 802.3) encapsulation.
> Link partner capability is 0000:.
> Negotiation did not complete.
>
> mii-tool
> eth0: negotiated 100baseTx-FD flow-control, link ok
> SIOCGMIIPHY on 'eth1' failed: Die Operation wird nicht unterstützt
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb at phy.duke.edu
More information about the Beowulf
mailing list