Author |
Message |
graysky
|
Posted: Mon Dec 08, 2008 4:00 pm |
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
I'm having very slow LAN transfers from a single problematic machine to other boxes (some Debian/some KM). ALL the machines are running with the identical gigalan NIC behind a gigalan switch. What I can't understand is why I'm only getting ~4-6 MB/s when I scp a file from this particular machine to ANY other machine on my LAN. The problem only occurs in one direction - speeds are on the order of 30-31 MB/s when that same machine downloads from any other machine on the LAN.
This the true if I use scp or samba.
All machines are using the skge driver. I would really appreciate any info you guys can provide that would help me tweak the network settings. I'd be glad to post any config file or log.
Thanks!
_________________ Retired KM user (R4 - R6.04); friend to LH users.
|
|
Top |
|
|
jmckeown2
|
Posted: Mon Dec 08, 2008 5:06 pm |
|
Joined: Sat Sep 02, 2006 9:17 am
Posts: 359
|
Random shot-in-the-dark guess --
Is it possible that your disk is to blame? Outbound transfers suck because they're waiting on the speed of the disk. Inbound looks OK because the data is being buffered in memory on the way to the disk.
Send a large file in. If my assumption is correct then the drive activity light should continue to blink after the transfer appears to be done, because the write buffer is still working off the data.
|
|
Top |
|
|
graysky
|
Posted: Mon Dec 08, 2008 6:25 pm |
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
Hey man, good guess, but that's not the case. When I had KM on that box, the in/out xfers were more or less the same. Now that I put Debian/Lenny on it, I get the crippled outbound for some reason.
My short experience w/ LINUX is that these sorts of problems are usually solvable by a trivial change to a config file that I've never heard of Here's hoping someone in here can educate me on this one.
_________________ Retired KM user (R4 - R6.04); friend to LH users.
|
|
Top |
|
|
tscholl
|
Posted: Mon Dec 08, 2008 6:56 pm |
|
Joined: Mon Apr 10, 2006 3:48 pm
Posts: 997
Location:
Lexington, Ky
|
Check the network adapter settings. Sounds like one side is running 1/2 duplex.
|
|
Top |
|
|
graysky
|
Posted: Mon Dec 08, 2008 7:12 pm |
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
Not too sure how to access that... either of these?
Code: # ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pg Wake-on: g Current message level: 0x00000037 (55) Link detected: yes Code: # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 01:0e:b6:70:b8:12 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::20e:a6ee:fe70:b812/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1 RX packets:7472420 errors:0 dropped:0 overruns:0 frame:0 TX packets:11888939 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1691285339 (1.5 GiB) TX bytes:4115463402 (3.8 GiB) Interrupt:17
_________________ Retired KM user (R4 - R6.04); friend to LH users.
|
|
Top |
|
|
tscholl
|
Posted: Mon Dec 08, 2008 7:41 pm |
|
Joined: Mon Apr 10, 2006 3:48 pm
Posts: 997
Location:
Lexington, Ky
|
Yep that's it.
Looks like this side is 1000Mb/s Full Duplex
Quote: # ethtool eth0 Settings for eth0: Speed: 1000Mb/s Duplex: Full
What are the setting on the other machines?
Are they also 1000Mb/s Full Duplex ?
If not they should be, or this one should be configured to match the others.
|
|
Top |
|
|
Girkers
|
Posted: Tue Dec 09, 2008 4:26 am |
|
Joined: Tue Mar 22, 2005 9:18 pm
Posts: 1422
Location:
Brisbane, Queensland, Australia
|
I don't know how much this will relate to your situation, but I had the except same problem with a winblows machine a generation back. It had a onboard Realtek Chipset for a Gigabit LAN and its upload speed was atrocious when I was doing heavy processing.
I found that if I was folding or doing video encoding my upload speed was terrible, stop the CPU intensive task and boom off it went again.
So just something else to think about.
_________________ Girkers
|
|
Top |
|
|
Gnarl
|
Posted: Tue Dec 09, 2008 9:01 am |
|
Joined: Mon Feb 16, 2004 7:06 pm
Posts: 309
Location:
Toronto
|
|
Top |
|
|
graysky
|
Posted: Tue Dec 09, 2008 12:43 pm |
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
tscholl wrote: Yep that's it. Looks like this side is 1000Mb/s Full Duplex
What are the setting on the other machines? Are they also 1000Mb/s Full Duplex ? If not they should be, or this one should be configured to match the others. All the machines have identical ethtool outputs: 1000Mb/s and Duplex: Full. Gnarl wrote: When in doubt, replace your cables.
Solid advice, but no effect here
_________________ Retired KM user (R4 - R6.04); friend to LH users.
|
|
Top |
|
|
jzigmyth
|
Posted: Tue Dec 09, 2008 1:40 pm |
|
Joined: Thu Mar 02, 2006 5:42 pm
Posts: 410
Location:
middleton wi usa atsc
|
If all your nics are the same, try swapping the nic with another machine. Maybe that one nic has a flaky sending circuit.
Also, try swapping ports on the switch, that could have a bad port too.
|
|
Top |
|
|
graysky
|
Posted: Tue Dec 09, 2008 2:44 pm |
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
Thanks for the suggestions, jzigmyth. Here is an update.
I threw in an old EIDE drive (unplugged the main HDD) and installed KM R5.5 since the installer is so easy. Long story short, once I'm at the desktop, I open up a shell and scp a file to another machine on the network and I'm smoking along at the usual 30-34 Mb/s!
Just to test things out with the old drive, I booted into Ubuntu 8.10 via the live CD and did the same scp command. It too was fast. Replacing the EIDE drive with the newer SATA drive and repeating the Ubuntu experiment left me with the same slow xfers I saw under Debian/Lenny!
So, it *must* be either the HDD or more likely the onboard controller.
I'm currently reinstalling Debian/Lenny on the EDIE drive and will begin the process of migrating the system from the SATA drive to it but I'm wondering what is causing the problem and how to fix it.
_________________ Retired KM user (R4 - R6.04); friend to LH users.
|
|
Top |
|
|
graysky
|
Posted: Tue Dec 09, 2008 3:15 pm |
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
According to the manual for the board (Asus A7N8X-Deluxe), the on board SATA controller is a Promise PDC20378. I'm almost positive the kernel handles controlling it, no? In other words, there wouldn't be any 3rd party driver being invoked that might interfere with the on board LAN, right?
BTW, the on board LAN is a Marvell 88E8001 Gigabit LAN.
As always, any suggestions are welcomed.
_________________ Retired KM user (R4 - R6.04); friend to LH users.
|
|
Top |
|
|
Girkers
|
Posted: Tue Dec 09, 2008 3:23 pm |
|
Joined: Tue Mar 22, 2005 9:18 pm
Posts: 1422
Location:
Brisbane, Queensland, Australia
|
Whislt this should not effect the speed of the copy to the extent you have reported, if your SATA controller is a v2, i.e. 300MB transfers, you would need to remove the jumper from the back of the hard drive otherwise it will be running at v1 speeds.
Have you tried checking the hard drive with the manufacturers tool, an easy boot CD to use is the Ultimate Boot CD, it contains nearly all of the tools.
I don't recall it being mentioned, have you checked to see that DMA is turned on for this drive?
Good luck.
_________________ Girkers
|
|
Top |
|
|
graysky
|
Posted: Tue Dec 09, 2008 3:27 pm |
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
@Girkers - thanks for the reply. It's a SATA-1 drive (MB is old and on board controller is also SATA-1). Since it's handled as a SCSI device, hdparm cannot be used on it. My understanding is that DMA is always enabled for these HDDs.
You do raise an interesting point though.... do you think it's a function of the DISK, not the controller? Perhaps jmckeown2 was right?
jmckeown2 wrote: Random shot-in-the-dark guess --
Is it possible that your disk is to blame? Outbound transfers suck because they're waiting on the speed of the disk. Inbound looks OK because the data is being buffered in memory on the way to the disk.
Send a large file in. If my assumption is correct then the drive activity light should continue to blink after the transfer appears to be done, because the write buffer is still working off the data.
@jmckeown2 - I would try this experiment you proposed, but my HDD light isn't functional... this is an OLD machine :p
Anyway, am I right about /dev/sda being handled differently than /dev/hda? In other words, there are no hdparm settings for me to apply to it, no?
Code: # hdparm -I /dev/sda /dev/sda:
ATA device, with non-removable media powers-up in standby; SET FEATURES subcmd spins-up. Model Number: HDS722516VLSA80 Serial Number: VNRD3EC4CH3U5M Firmware Revision: V34OA63A Standards: Used: ATA/ATAPI-6 T13 1410D revision 3a Supported: 6 5 4 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 321672960 device size with M = 1024*1024: 157066 MBytes device size with M = 1000*1000: 164696 MBytes (164 GB) Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Advanced power management level: disabled Recommended acoustic management value: 128, current value: 254 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: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Release interrupt * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * NOP cmd * READ/WRITE_DMA_QUEUED Advanced Power Management feature set Power-Up In Standby feature set SET_FEATURES required to spinup after power up Address Offset Reserved Area Boot SET_MAX security extension * Automatic Acoustic Management feature set * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test * General Purpose Logging feature set * SATA-I signaling speed (1.5Gb/s) Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count not supported: enhanced erase 88min for SECURITY ERASE UNIT. Checksum: correct
_________________ Retired KM user (R4 - R6.04); friend to LH users.
|
|
Top |
|
|
Girkers
|
Posted: Tue Dec 09, 2008 3:47 pm |
|
Joined: Tue Mar 22, 2005 9:18 pm
Posts: 1422
Location:
Brisbane, Queensland, Australia
|
|
Top |
|
|