View unanswered posts    View active topics

All times are UTC - 6 hours





Post new topic Reply to topic  [ 18 posts ] 
Go to page 1, 2  Next

Print view Previous topic   Next topic  
Author Message
Search for:
PostPosted: Mon Dec 08, 2008 4:00 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Mon Dec 08, 2008 5:06 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Mon Dec 08, 2008 6:25 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Mon Dec 08, 2008 6:56 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Mon Dec 08, 2008 7:12 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Mon Dec 08, 2008 7:41 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Dec 09, 2008 4:26 am 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Dec 09, 2008 9:01 am 
Offline
Joined: Mon Feb 16, 2004 7:06 pm
Posts: 309
Location: Toronto
When in doubt, replace your cables.

_________________
KnoppMyth Folding@home
How to setup F@H
F@H Stats Page


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 09, 2008 12:43 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Dec 09, 2008 1:40 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Dec 09, 2008 2:44 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Dec 09, 2008 3:15 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Dec 09, 2008 3:23 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Dec 09, 2008 3:27 pm 
Offline
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
 Profile  
 
 Post subject:
PostPosted: Tue Dec 09, 2008 3:47 pm 
Offline
Joined: Tue Mar 22, 2005 9:18 pm
Posts: 1422
Location: Brisbane, Queensland, Australia
Have you checked dmesg for what it tells you about this connection to this drive?

I also just did a quick google for hdparam /dev/sd and it came up with a few links, one of interest is http://www.linuxforums.org/forum/peripherals-hardware/30563-solved-cannot-enable-hd-dma-modes.html it gives you a why to test the speed of your drive, this may give you some indication if that is it.

_________________
Girkers


Top
 Profile  
 

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ] 
Go to page 1, 2  Next



All times are UTC - 6 hours




Who is online

Users browsing this forum: No registered users and 29 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group

Theme Created By ceyhansuyu