Re: scp 3G file on 125MB/s network slow at 25MB/s why?



On Dec 6, 10:41 am, gavino <gavcom...@xxxxxxxxx> wrote:
With a Gig nic on 2 boxes on same subnet I get only 25MB /s using scp
to transfer large movie files.

Why so low?

I should get 125MB /s from the Gig nics yes?

The major variables are:

1) How fast can you read data from the disk?

2) How fast can you encrypt the data for transfer?

3) How efficiently can TCP utilize the available network bandwidth?

4) What is the available outbound bandwidth between the CPU and the
network interface (given that a lot of that I/O bandwidth is being
used to read the file from the disk)? How much data can be transferred
per interrupt, buffered on the network card, what is the maximum
sustainable interrupt rate? How much data is transferred per
interrupt? How much CPU is needed to keep up with the network transfer
and how does that affect how much CPU is available for encrypting?

5) What is the available network bandwidth?

6) What is the available inbound bandwidth between the CPU and the
network interface? How do all the factors described in 4 above affect
the receiver?

7) How fast can you decrypt the data for transfer? (Given that a lot
of CPU is being used to service interrupts, copy in data, and so on.)

8) Once you've buffered as much received data in memory as you are
able/willing to, how fast can you write the data to disk? How does all
this data being written to the disk affect the I/O bandwidth available
for the network interface?

To a first approximation, the effective speed will be the lowest of
these values. Most likely it's either the disk read rate, the disk
write rate, the available CPU to both encrypt and send or to both
decrypt and receive, or the available I/O bandwidth to both read the
disk and send to the network interface or both receive from the
network interface and write to the disk.

DS
.



Relevant Pages

  • Re: Restrict resources on AIX 5.2?
    ... In article, Chris Ott wrote: ... > disk IO bandwidth and/or CPU time a process can use, ...
    (comp.unix.aix)
  • Re: sqlserver 2005: indexes on raid-0?
    ... The idea is to move the import job related tables and indexes to separate drives to reduce disk seek time during that 1 crucial minute. ... This will hopefully improve overall throughput more than having everything on one array. ... I figure that if you physically separate your bulk loaded tables from other tables you're reducing IO bandwidth for this set of tables and all others by basically reserving parts of that bandwidth for specific data. ... tables reside in their own files and the files reside on their own disks,, so hopefully disk head movement will be minimal. ...
    (comp.databases.ms-sqlserver)
  • Re: Very High Rate Continous Transfer
    ... 160 to 200 MBytes/sec transfer to disk. ... What types of drives and how would they be configured as an array? ... So memory bandwidth will be at least 320 to ...
    (comp.arch.storage)
  • Re: Bandwidth Allocations under CFQ I/O Scheduler
    ... bandwidth. ... The iops/sec metric doesn't help you. ... It's an entirely diffent thing from the mp3 player. ... least foo amount of the disk, but don't let it suck everything. ...
    (Linux-Kernel)
  • Re: Bandwidth Allocations under CFQ I/O Scheduler
    ... The iops/sec metric doesn't help you. ... that me being able to specify "90% of the disk ... bandwidth" does not help me. ... That was the whole point of using OSIOPs/sec rather than bandwidth to ...
    (Linux-Kernel)