Lan performance issues

I just realized that my in-apartment LAN performance is pretty poor. My
intranet is typical: I have an OpenBSD box as my firewall/gateway/NAT
box. The OpenBSD machine has two NICs, one for DSL and one that
connects to a Linksys 100/10 Mbps switch (can't remember official model
number). The LAN NIC in the OpenBSD box is a Linksys 100/10 Mbps PCI
card (can't remember exact model). My computer is a Linux box; it has
an on-board 3Com 3c59x controller (Asus A7N8X Deluxe motherboard).

For any large file transfer between the Linux and OpenBSD
machines---using scp/sftp, http, rsync, or samba---the best transfer
rate I can get is about 230 K Bytes/sec. (I.e. an 80 MB file would take
about six minutes to transfer.)

I realize that there are a fair number of potential causes of slow LAN
performance. Where should I first start to look? What are the most
likely causes, what's easiest (and cheapest!) to check?

According to ifconfig, I'm not getting any collisions. Also according
to ifconfig, both cards are running in 100baseTX mode with full-duplex.
It looks like some folks suggest using half-duplex operation, but I
don't understand how this could *improve* performance.

I am also wondering if my cables are bad or not "good enough". Can I
visually check my cabling to make sure it's adequate for 100Mbps
operation?

Thanks for any feedback! Please let me know if I should post any more
info.

Thanks again,
Matt

Matt Garman <(E-Mail Removed)> wrote:
> I just realized that my in-apartment LAN performance is pretddty poor. My
[..]
> an on-board 3Com 3c59x controller (Asus A7N8X Deluxe motherboard).

> For any large file transfer between the Linux and OpenBSD
> machines---using scp/sftp, http, rsync, or samba---the best transfer
> rate I can get is about 230 K Bytes/sec. (I.e. an 80 MB file would take
> about six minutes to transfer.)

> I realize that there are a fair number of potential causes of slow LAN
> performance. Where should I first start to look? What are the most
> likely causes, what's easiest (and cheapest!) to check?

Duplex mismatch is a common reason, however raising errors in the
ifconfig output should be mentionable, while transferring data.

> According to ifconfig, I'm not getting any collisions. Also according
> to ifconfig, both cards are running in 100baseTX mode with full-duplex.
> It looks like some folks suggest using half-duplex operation, but I
> don't understand how this could *improve* performance.

Could you post your 'ifconfig' output, never saw the speed
mentioned on any Linux distro ifconfig output. Usually 'mii-tool'
is used.


--
Michael Heiming

Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of SPAM

Matt Garman <(E-Mail Removed)> wrote:
> I just realized that my in-apartment LAN performance is pretty poor. My
> intranet is typical: I have an OpenBSD box as my firewall/gateway/NAT
> box. The OpenBSD machine has two NICs, one for DSL and one that
> connects to a Linksys 100/10 Mbps switch (can't remember official model
> number). The LAN NIC in the OpenBSD box is a Linksys 100/10 Mbps PCI
> card (can't remember exact model). My computer is a Linux box; it has
> an on-board 3Com 3c59x controller (Asus A7N8X Deluxe motherboard).
>
> For any large file transfer between the Linux and OpenBSD
> machines---using scp/sftp, http, rsync, or samba---the best transfer
> rate I can get is about 230 K Bytes/sec. (I.e. an 80 MB file would take
> about six minutes to transfer.)
>
> I realize that there are a fair number of potential causes of slow LAN
> performance. Where should I first start to look? What are the most
> likely causes, what's easiest (and cheapest!) to check?

The most likely cause is poor cabling. Particularly at the rj45s.

> According to ifconfig, I'm not getting any collisions. Also according
> to ifconfig, both cards are running in 100baseTX mode with full-duplex.
> It looks like some folks suggest using half-duplex operation, but I
> don't understand how this could *improve* performance.

I wouldfirst drop to 10BT, and see if that helps. If it does, it's
obvious that some component of your system doesn't work at the higher
frequencies. Then you get to play swappee until you find what it is.

> I am also wondering if my cables are bad or not "good enough". Can I

Oh, yes.

> visually check my cabling to make sure it's adequate for 100Mbps
> operation?

It must be cat5, all the bibs and bobs attched.

Peter

On Fri, 5 Dec 2003 21:39:14 +0100, Michael Heiming
<michael+(E-Mail Removed)> wrote:
> Could you post your 'ifconfig' output, never saw the speed mentioned
> on any Linux distro ifconfig output. Usually 'mii-tool' is used.

Sorry, I was being a bit liberal with my verbage I had already got
and ran both the vortex-diag and mii-diag tools when I initially posted.

Here's the output of uname and ifconfig for both machines. Also is the
output of vortex-diag and mii-diag for the Linux box. (I'm not sure if
such diagnostic tools exist for OpenBSD or not.)

Thanks again!
Matt


uname -a

OpenBSD septictank.raw-sewage.fake 3.3 GENERIC#44 i386


ifconfig dc0

dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:a0:cc:5b:dd:f8
media: Ethernet 100baseTX full-duplex
status: active
inet6 fe80::2a0:ccff:fe5b:ddf8%dc0 prefixlen 64 scopeid 0x2
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255


uname -a

Linux sewage 2.4.20-gentoo-r7 #1 Fri Oct 17 07:47:06 CDT 2003 i686 AMD
Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux


ifconfig eth0

eth0 Link encap:Ethernet HWaddr 00:26:54:0B:F6:A0
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::226:54ff:fe0b:f6a0/10 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:24190811 errors:0 dropped:0 overruns:11 frame:0
TX packets:29496092 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3298474746 (3145.6 Mb) TX bytes:4217941979 (4022.5 Mb)
Interrupt:11 Base address:0xa000


vortex-diag -a

vortex-diag.c:v2.14 12/28/2002 Donald Becker ((E-Mail Removed))
http://www.scyld.com/diag/index.html
Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xa000.
Station address 00:26:54:0b:f6:a0.
Receive mode is 0x07: Normal unicast and all multicast.
The Vortex chip may be active, so FIFO registers will not be read.
To see all register values use the '-f' flag.
Initial window 7, registers values by window:
Window 0: 0000 0000 0000 0000 8080 00bf ffff 0000.
Window 1: FIFO FIFO 0700 0000 0000 0037 0000 2000.
Window 2: 2600 0b54 a0f6 0000 0000 0000 0052 4000.
Window 3: 0000 0180 05ea 0020 0040 0800 0800 6000.
Window 4: 0000 0000 0000 0cc0 0003 8080 0000 8000.
Window 5: 1ffc 0000 0000 0600 0807 06ce 06c6 a000.
Window 6: 0000 0000 0000 0100 0000 0072 0072 c000.
Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0xa000
0xA010: **FIFO** 00000000 0000001c *STATUS*
0xA020: 00000020 00000000 00080000 00000004
0xA030: 00000000 d45d2ba3 364960a0 00080004
0xA040: 002e3ef7 00000000 000000b7 00000000
0xA050: 00000000 00000000 00000000 00000000
0xA060: 00000000 00000000 00000000 00000000
0xA070: a3000020 00000000 01600040 00000000
DMA control register is 00000020.
Tx list starts at 00000000.
Tx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to empty.
Rx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to full.
Poll period Tx 00 ns., Rx 0 ns.
Maximum burst recorded Tx 64, Rx 352.
Indication enable is 06c6, interrupt enable is 06ce.
No interrupt sources are pending.
Transceiver/media interfaces available: MII.
Transceiver type in use: Autonegotiate.
MAC settings: full-duplex.
Station address set to 00:26:54:0b:f6:a0.
Configuration options 0052.


vortex-diag -e

vortex-diag.c:v2.14 12/28/2002 Donald Becker ((E-Mail Removed))
http://www.scyld.com/diag/index.html
Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xa000.
Station address 00:26:54:0b:f6:a0.
Receive mode is 0x07: Normal unicast and all multicast.
Saved EEPROM settings of a 3Com Vortex/Boomerang:
3Com Node Address 00:26:54:0B:F6:A0 (used as a unique ID only).
OEM Station address 00:26:54:0B:F6:A0 (used as the ethernet address).
Device ID 9201, Manufacturer ID 6d50.
Manufacture date (MM/DD/YYYY) 15/31/2027, division ÿ, product ÿÿ.
No BIOS ROM is present.
Transceiver selection: MII.
Options: negotiated duplex, link beat required.
PCI Subsystem IDs: Vendor 1043 Device 80ab.
MII.
Vortex format checksum is incorrect (c9 vs. 1043).
Cyclone format checksum is incorrect (0xf1 vs. 00).
Hurricane format checksum is incorrect (0xda vs. 00).


vortex-diag -m

vortex-diag.c:v2.14 12/28/2002 Donald Becker ((E-Mail Removed))
http://www.scyld.com/diag/index.html
Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xa000.
Station address 00:26:54:0b:f6:a0.
Receive mode is 0x07: Normal unicast and all multicast.
MII PHY found at address 2, status 786d.
MII PHY 0 at #2 transceiver registers:
3000 786d 0022 5521 01e1 41e1 0005 2801
2801 2801 2801 2801 2801 2801 2801 2801
1800 0000 0e99 0000 c010 0001 0fff 8001
8886 00ff 0000 0000 0044 1000 1a60 0100.


mii-diag -v

mii-diag.c:v2.09 9/06/2003 Donald Becker ((E-Mail Removed))
http://www.scyld.com/diag/index.html
Using the new SIOCGMIIPHY value on PHY 2 (BMCR 0x3000).
The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
Basic mode control register 0x3000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
End of basic transceiver information.

libmii.c:v2.10 4/22/2003 Donald Becker ((E-Mail Removed))
http://www.scyld.com/diag/index.html
MII PHY #2 transceiver registers:
3000 786d 0022 5521 01e1 41e1 0005 2801
2801 2801 2801 2801 2801 2801 2801 2801
1800 0000 0e99 0000 c010 0001 0fff 8001
b308 00ff 0000 0000 0044 1000 1a60 0100.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x786d ... 786d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:08:95:--:--:--, model 18 rev. 1.
No specific information is known about this transceiver type.
I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Negotiation completed.


--
Matt Garman
email at: http://raw-sewage.net/index.php?file=email

Matt Garman wrote:

> According to ifconfig, I'm not getting any collisions. Also according
> to ifconfig, both cards are running in 100baseTX mode with full-duplex.
> It looks like some folks suggest using half-duplex operation, but I
> don't understand how this could improve performance.

Are you getting any other errors? You should never see collisions on a
switch.

>
> I am also wondering if my cables are bad or not "good enough". Can I
> visually check my cabling to make sure it's adequate for 100Mbps
> operation?
>

Did you make the cables yourself? If so, the prime suspect would be
improperly connected cables, where you've crossed wired some pairs. The
cables must be wired so that you've got a pair on pins 1&2 and 3&6. Check
EIA/TIA 568A or B (your choice) for standard connections.

--

Fundamentalism is fundamentally wrong.

To reply to this message, replace everything to the left of "@" with
james.knott.

Matt Garman <(E-Mail Removed)> wrote:
[..]

> ifconfig eth0

> eth0 Link encap:Ethernet HWaddr 00:26:54:0B:F6:A0
> inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
> inet6 addr: fe80::226:54ff:fe0b:f6a0/10 Scope:Link
> UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:24190811 errors:0 dropped:0 overruns:11 frame:0
> TX packets:29496092 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:3298474746 (3145.6 Mb) TX bytes:4217941979 (4022.5 Mb)
> Interrupt:11 Base address:0xa000

Looks not that bad, even if you usually see bad cable from errors
above, I'd try out another cable, not some self-made, just to be
sure.

The BSD box isn't running some kind of traffic shaper? In
addition I'd use a cross-over cable, to exclude the switch from
testing.

Perhaps forcing the NIC to 10 Mb, like Peter T. Breuer suggested,
to see if your cable work better at this speed, would be another
good idea. You can set this with mii-tool/mii-diag while running.

[..]

--
Michael Heiming

Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of SPAM

> For any large file transfer between the Linux and OpenBSD
> machines---using scp/sftp, http, rsync, or samba---the best transfer
> rate I can get is about 230 K Bytes/sec. (I.e. an 80 MB file would take
> about six minutes to transfer.)
>
> I realize that there are a fair number of potential causes of slow LAN
> performance. Where should I first start to look? What are the most
> likely causes, what's easiest (and cheapest!) to check?

First, eliminate the file transfer, and test *just* the network
transmission speed with one of the various tests designed just for that.
That one test will likely cut your troubleshooting time by at least half.
: )

> According to ifconfig, I'm not getting any collisions. Also according
> to ifconfig, both cards are running in 100baseTX mode with full-duplex.
> It looks like some folks suggest using half-duplex operation, but I
> don't understand how this could *improve* performance.

The only time half-duplex should be necessary is if you're using a hub, as
opposed to a switch. If you're using a hub, you'll only get half-duplex no
matter what. If you're using a switch and find half-duplex any improvement,
something in the mix is faulty or misconfigured, and you should fix the
source of the problem, not hide it with a band-aid. (I'm assuming your
network hardware isn't completely antiquated ;-) )

> I am also wondering if my cables are bad or not "good enough". Can I
> visually check my cabling to make sure it's adequate for 100Mbps
> operation?

See if they have "cat 5" or "cat 3" printed on them. For 100mbit
performance, specs call for cat5.

Now, that being said, I've seen a lot of very poor cabling, and a lot of
that has used cat3 for 100mbit operation, without *any* problems. What I
*have* seen cause problems, time and time again, are two things: (1)
loose/intermittent connections in the cabling/plugs, and (2) coiling up
network cable. I can take a perfectly good, working, full-spec cable, roll
it up into a nice, tight coil, and bingo - it no longer works correctly.

> Thanks for any feedback! Please let me know if I should post any more
> info.

You isolate layers/subsystems to find exactly where the fault is. That
generally makes most any troubleshooting go much more quickly! ; )

steve

On Sat, 6 Dec 2003 00:35:52 +0100, Michael Heiming
<michael+(E-Mail Removed)> wrote:
> Looks not that bad, even if you usually see bad cable from errors
> above, I'd try out another cable, not some self-made, just to be sure.

I verified that all my cables are indeed Cat5 (actually, they are "CAT5e
UTP"). Note that my roommate has a Windows 2k box also attached to the
switch. Transfers from the server to his computer also cap around 230
KB/s.

> The BSD box isn't running some kind of traffic shaper? In addition I'd
> use a cross-over cable, to exclude the switch from testing.

Nope, the BSD box is not running any kind of traffic shaper. I verified
this by transferring a file between my computer (Linux) and my
roommate's computer (Win2k). The speed was actually halved! (I got
about 120 KB/s.)

I also bought a crossover cable, and ran it between the Linux and
OpenBSD boxes. The transfer speeds did not improve.

> Perhaps forcing the NIC to 10 Mb, like Peter T. Breuer suggested, to
> see if your cable work better at this speed, would be another good
> idea. You can set this with mii-tool/mii-diag while running.

I set the Linux box to 10baseT, and my transfer speeds were actually
*reduced* by about 1/3 (went down to around 80 KB/s).

Finally, since the OpenBSD box has two NICs (a Linksys and a
Realtek-based card), I swapped their roles. Originally, the Linksys was
for the LAN, and the Realtek was for the DSL. Now the Linksys is
connected to the DSL and the Realtek is connected to the LAN. No
improvement in performance.

I'm starting to think I have multiple points of failure.

Any more thoughts? Looks like I actually need to start physically
swapping NICs.

Thanks for all the help guys!
Matt

--
Matt Garman
email at: http://raw-sewage.net/index.php?file=email

Matt Garman <(E-Mail Removed)> wrote:
[..]
> Nope, the BSD box is not running any kind of traffic shaper. I verified
> this by transferring a file between my computer (Linux) and my
> roommate's computer (Win2k). The speed was actually halved! (I got
> about 120 KB/s.)

What about speed between the M$ box and the BSD box, using the
cross-over cable.

> I also bought a crossover cable, and ran it between the Linux and
> OpenBSD boxes. The transfer speeds did not improve.

Good, (not really), what about the NIC in the Linux Box, are you
really using the right driver? I'd put in another NIC in the
Linux box, an retry.

Yep, it sounds like you have several problems.

Good luck

--
Michael Heiming

Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of SPAM

"Steve Wolfe" <(E-Mail Removed)> wrote in message
news:bqrp7l$255t2d$(E-Mail Removed)

>> I am also wondering if my cables are bad or not "good enough". Can I
>> visually check my cabling to make sure it's adequate for 100Mbps
>> operation?
>
> See if they have "cat 5" or "cat 3" printed on them. For 100mbit
> performance, specs call for cat5.

I once had the same performance problems in a server room on wrt traffic
to/from a Tru64 machine. Verified that all cabling was labeled "Cat5", yet
one segment, when replaced, was the nature of the problem. Even though
labeled "Cat5" it had Cat3 performance for some reason.

It's prudent to not trust the cable labeling, but to physically replace the
cable segments when testing such vexing problems.


tony

--
use hotmail for any email replies



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----