Member Avatar for shwick

I'm having many little problems with my gigabit network.

My hard drive reads at 85 MB/s, so why am I downloading from the ftp server at 68 MB/s? How could I diagnose what is eating those 17 MB/s?

Why does my windows machine have a slow 326 Mbit/s transmit speed compared with ubuntu's transmit speed of 763 Mbit/s when testing with iperf?

Why do I get slow samba speeds?

Windows is connected to Ubuntu with a 6 foot crossover cable. Both machines are fully updated.

windows xp3
motherboard: gigabit ga-965p-ds3
cpu: C2D E4400
hard drives: 250gb seagate, read = 85 MB/s
lan: marvel 8053 Gigabit LAN (onboard, PCI-E)

ubuntu 8.04 gateway
motherboard: Asus P5B-MX
cpu: C2D E2160
hard drive: 250gb seagate, read = 85 MB/s
lan: attansic® L1 PCI-E Gigabit LAN controller (onboard, PCI-E)

iperf

  • windows pc downloading from gateway: 763 Mbit/s = 95 MB/s
  • gateway downloading from windows pc: 326 Mbit/s = 41 MB/s

ftp

  • windows pc downloading from gateway: 544 Mbit/s = 68 MB/s

Samba

  • windows pc downloading from gateway: 194 MBit/s = 24 MB/s
  • gateway downloading from windows pc: 160 MBit/s = 20 MB/s

smb.conf

[global]
        netbios name = SHWICK_GATEWAY
        server string = SHWICK_GATEWAY
        interfaces = lo, eth1
        bind interfaces only = Yes
        map to guest = Bad User
        passdb backend = tdbsam
        syslog only = Yes
        socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192
        os level = 65
        preferred master = Yes
        domain master = Yes
        dns proxy = No
        wins support = Yes
        invalid users = root

[Media]
        path = /home/ftp/
        create mask = 0640
        directory mask = 0750
        guest only = Yes
        guest ok = Yes
  • 2 Contributors
  • 4 Replies
  • 559 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by shwick

Dani AI

Generated

Summary and quick context drawn from the thread: the iperf tests show a strong direction-dependent difference, FTP is noticeably slower than raw disk read, and Samba improved after removing custom socket options (as discovered). Suggested next steps are focused, ordered tests and low-risk changes that isolate the root cause (NIC/driver, TCP offloads, or application limits).

Checklist — what to verify first

  • Confirm link speed/duplex and what offloads the NIC reports (driver + hardware). Example checks on Linux: ethtool eth1, ethtool -i eth1, ethtool -k eth1. Driver/firmware updates can fix TSO/segmentation bugs found in some older chips (Attansic/atl1 had known TSO issues in vendor drivers). (man7.org)

Quick offload tests (safe, reversible)

  • Temporarily turn off segmentation/receive coalescing to test whether offloads are the limiter (this increases CPU but isolates the problem): 
    ethtool -K eth1 tso off gso off gro off
  • On Windows disable LSO (Large Send Offload) via Device Manager advanced NIC settings or PowerShell (Disable-NetAdapterLso) while testing. Re-enable after tests if stable. Disabling is only for troubleshooting — it can raise CPU usage. (man7.org)

Application-level isolation and tests

  • Replace the FTP layer with a raw TCP test to separate server app overhead from the network: on the server, pipe a large file to nc -l -p 12345; on the client nc server 12345 > /dev/null and measure throughput/CPU.
  • Try segmented/multi-connection downloads (FTP clients like lftp support pget -n) or use iperf with parallel streams (-P) to see if single-stream limits are the bottleneck. These steps distinguish TCP/windowing or app-protocol limits from link/NIC issues. (manpages.debian.org)

Other notes

  • Jumbo frames only help if every device in the path (both NICs and any intervening switch) supports and is configured for the larger MTU — change on both ends simultaneously. After isolating the root cause, re-tune socket buffer sizes and Samba settings (avoid forcing very small buffers). (cisco.com)

Suggested sequence: check link/driver/offloads → run raw TCP (nc) → test FTP with segmented downloads → re-enable tuned features. Mentioned observations from and fit this flow: driver/offload quirks and socket options commonly explain the kind of asymmetric and protocol-dependent results shown in the thread.

Recommended Answers

All 4 Replies

Member Avatar for jbennet

What category is the crossover cable
They both got gigabit cards?

Member Avatar for shwick

Yes both onbaord gigabit cards. Crossover is CAT5.

So I found how to make samba faster, I removed "SO_RCVBUF=8192 SO_SNDBUF=8192" from socket options. I let the tcp stack set the buffer size automatically now. 8192 was too small for a gigabit lan.

But is there any way I can improve the ftp speeds? The problem is server side, as I tested a download on both windows and from an ubuntu livecd, and both times it was 68 MB/s.

Member Avatar for jbennet

You should really be using cat6 cable on a gigabit LAN
giabit cards dont need crossover cables anyway, a patch is fine

Member Avatar for shwick

Well I give up I guess I'll settle for 68 MB/s ftp and 43 MB/s samba. lame.

I tried a bunch of tcp tweaking on my ubuntu gateway, stuff from articles like

# TCP gigabit tweaks
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

Tried setting mtu to 9000, tried disabling tcp sack. Double checked cables were cat5e. (cat5e supports gigabit)

Booted ubuntu livecd on windows machine, iperf got 940 Mbit/s down. And I get 544 Mbit/s from ftp server.

Tried messing with nfs, looked like i was getting 62 MB/s down. Couldn't do proper tests b/c livecd boot kept running out of space.

Whatever. Getting that last 17 MB/s isn't worth it if it's this difficult.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.