Results 1 to 10 of 10

Hybrid View

  1. #1

    Why my max is 1.4MB/s

    Im transfering a large file via scp to another server. Both servers have a 100Mbs Port. If both servers have a Fully Dedicated 100Mbs Port... Why do my server transfer max out at 1.4MB/s. Both servers are not being used by other processes that would lower my transfer speed.
    thanks

  2. #2
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,710
    TCP/IP limitations (latency). What is the ping time from one server to the other?

  3. #3
    Quote Originally Posted by layer0
    TCP/IP limitations (latency). What is the ping time from one server to the other?
    The average ping time is 33ms

  4. #4
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    SCP in generally is a slow process.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  5. #5
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,710
    Quote Originally Posted by Steven
    SCP in generally is a slow process.
    Very true however you definitely can't max out 100mbits with a latency of 30ms, you'd generally need <5ms to do that (from what I've seen).

  6. #6
    Join Date
    May 2006
    Location
    Florida, USA
    Posts
    364
    TCP/IP limitations (latency).
    what do you mean I'm latent and limited? (sorry couldn't resist lol)

    What processors and how much memory on each one of the machines? If you are using heavy encryption then it will tax the CPU.

    If you have a Celeron sending a lot of encrypted data to a quad Xeon or a cool Opteron, the celeron will be your bottleneck and vice-verca... even on a dedicated gig connection. I would try using a different encryption algorithm and see what happens.

    good luck!
    Host, YES!
    Reselling? Partner for profit instead!

  7. #7
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,710
    Quote Originally Posted by TCP/IP Warrior
    what do you mean I'm latent and limited? (sorry couldn't resist lol)
    ...lol.......

  8. #8
    Join Date
    Feb 2004
    Location
    here and there
    Posts
    767
    Could also be the network card, or your provider is lieing to you about your port.
    Dedicated Servers, Virtual Machines, Colocation, BGP & IPs
    objx.net - AS33333 - Salt Lake, Utah
    awknet.com - AS17048 - Los Angeles, California

  9. #9
    Might want to ask them to check for a duplex mismatch. From your description this could very well be the problem.
    Steve Eschweiler - Hivelocity.net - Since 2002
    The Bare Metal Cloud Co.
    Instantly Deploy Dedicated Servers in 30 Data Centers on 4 Continents
    24/7/365 World Class Phone, Chat and Ticket Technical Support

  10. #10
    Join Date
    Nov 2005
    Location
    Minneapolis, MN
    Posts
    1,648
    Performance would suck a lot more if it was a duplex mismatch issue. The problem is likely that your TCP Send & Receive buffers are set too small. It's a matter of physics; you can send a "window" of data and then you must get an acknowledgment for that chunk of data before getting another. The window is determined by the send & receive buffers. If your servers are 33ms apart, that means you get ~30 round-trips per second. 100mbit = 12.5MB/sec. 12.5MB/sec / 30 round-trips/sec = 416667 bytes per window to achieve full performance.

    Default buffers for CentOS/Fedora Linux is 16384 bytes send, and 87380 bytes receive. You can bump those up by doing the following:

    Do a "cat /proc/sys/net/ipv4/tcp_window_scaling" and make sure you get "1" as a return. That enables window scaling to values greater than 64KB.

    Do a "cat /proc/sys/net/ipv4/tcp_rmem" and you should see "4096 87380 4194304"

    Bump that up to a 384k window by doing this:

    echo "4096 393216 4194304" > /proc/sys/net/ipv4/tcp_rmem

    You'll also want to check your send-space buffers

    "cat /proc/sys/net/ipv4/tcp_wmem" and you should see "4096 16384 4194304"

    Bump that to 384k send-space as well:

    echo "4096 393216 4194304" > /proc/sys/net/ipv4/tcp_wmem

    Those values should allow the TCP to gain more efficiency to give you better transfer rates, but you'll need to make sure to do this on both hosts.
    Eric Spaeth
    Enterprise Network Engineer :: Hosting Hobbyist :: Master of Procrastination
    "The really cool thing about facts is they remain true regardless of who states them."

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •