Loading ...
Sorry, an error occurred while loading the content.

Really slow writing files over network via samba and scp?

Expand Messages
  • George Styles
    Hi, My openslug 2.5beta box with external USB2 hard drive is VERY slow to access files over the network. (ie, read/write files on the slug from a windows box).
    Message 1 of 35 , Sep 28, 2005
    • 0 Attachment
      Hi,

      My openslug 2.5beta box with external USB2 hard drive is VERY slow to
      access files over the network. (ie, read/write files on the slug from
      a windows box). I have tried 2 different windows boxes, and they are
      the same, so its a problem with my slug

      Its slow with both samba, and using scp to write the file.

      Its not the disk itself, because
      dd if=/dev/zero of=testdummy bs=1M count=100
      takes around 20s, so thats 5megs per s.

      The network is OK, as transfering files between other hosts works at
      full speed (eg, this 100m file takes 23s to copy from a windows box to
      another windows box, which is 4megs per second.

      1. SAMBA

      From the slug, if I try and copy that file to a windows box, using
      copy \\192.168.0.254\smbroot\lithium\testdummy .
      it takes 90s, so thats 1MB/s, which is only 1% of the ideal bandwidth
      of the network.

      Writing is MUCH worse, trying to copy that 100m file to the slug
      causes Windows explorer to estimate 53 minutes for the transfer... I
      havent waited the full 53 mins, but a smaller 3meg file estimates 3
      mins, and takes slightly longer than that... This is 0.01MB/s...

      smbd is using 0.1% of cpu according to top while this transfer is
      taking place, and cat /proc/swaps shows that only 5megs of swap space
      is being used, so its not swapping like crazy.

      Ive read http://www.nslu2-linux.org/wiki/OpenSlug/GettingStartedWithSamba
      and there are no clues there.

      2. SCP
      copying the 100m file TO the slug gives:

      X:\>scp testdummy 192.168.0.254:/home/george/
      The authenticity of host '192.168.0.254 (192.168.0.254)' can't be established.
      RSA key fingerprint is 8f:b1:e4:c2:5a:9e:72:4f:56:f2:1e:02:7c:65:ea:a6.
      Are you sure you want to continue connecting (yes/no)? yes
      Warning: Permanently added '192.168.0.254' (RSA) to the list of known hosts.
      testdummy 0% 0 0.0KB/s --:-- ETA

      Here, it waits for about 1min and then starts transferring at 1.8KB/s

      3. COPYING INTO SLUG FROM WINDOWS SHARE USING cp FROM A SSH SESSION ON THE SLUG
      When I mounted a smb share from a windows server on the slug, using
      smbmount on the slug, I can cp a 10meg file to the USB drive in 10s,
      so although not lightning fast, it seems to be in keeping with the
      general network speed here. Its certainly 100 times faster than I was
      getting via samba.
      Catt'ing the same file into /dev/null (instead of writing to USB
      drive) takes 6s.
      This eliminates any network hardware issues (i think)

      so, can anyone suggest why it takes so long to push files to the slug
      from a windows box, whereas pulling the same file from the slug is a
      lot quicker?

      I remember reading somewhere about a setting that makes Samba faster
      on the slug - someone suggested it gave a big (i think 2x or 4x)
      increase. I cant remember if I applied that setting, or what it was...
      anyone???

      thanks
      George
    • Attila Csipa
      ... try miitool -v for verbose output. I m under the impression that there is a confusion somewhere in the driver-kernel-miitool chain so the status of eth1 is
      Message 35 of 35 , Oct 4, 2005
      • 0 Attachment
        On Tuesday 04 October 2005 15:02, George Styles wrote:
        > eth0: negotiated 100baseT4 flow-control, link ok
        > eth1: negotiated 100baseTx-HD, link ok

        try miitool -v for verbose output. I'm under the impression that there is a
        confusion somewhere in the driver-kernel-miitool chain so the status of eth1
        is the status our eth0, the autonegotiating, the Tx, all say that those are
        the actual parameters of the 'real' eth0. One note, IIRC the HD means
        HALF-duplex operation ? That's most certainly not fun on network intensive
        connections.

        > interface, the LED indicates that it has switched to 10... Doing it
        > on eth1 makes the slug hang (or at least fall off the network).

        If you are doing this sort of thing try disconnecting/reconnecting the cable
        after the command (and wait a few seconds), especially if you are going
        through a switch/router, I've seen too much broken autosensing equipment to
        trust it will work just right...

        > Should it see 2 ethernet devices? maybe thats what my problem is?

        The Intel chip in the slug has two ethernet ports, it's just that only one is
        implemented on the NSLU2 board, so that should be okay.
      Your message has been successfully submitted and would be delivered to recipients shortly.