File Transfer Rates - NFS

This is a discussion on File Transfer Rates - NFS ; Hello all - I have a bit of a quandry and I'm not sure how to even begin the math to solve it. I have a user that has a requirement to transfer a 250 - 650Gb database across the ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: File Transfer Rates

  1. File Transfer Rates

    Hello all -
    I have a bit of a quandry and I'm not sure how to even begin the math
    to solve it. I have a user that has a requirement to transfer a 250 -
    650Gb database across the network (WAN) in aprox 6 to 8 hours. I'm
    doing the math but I think i'm going in circles as far as figuring out
    how much bandwidth they need. Anyone have a decent formula to figure
    this out with? I'm about at wits end!
    Thanks in advance!!


  2. Re: File Transfer Rates

    mcechman@adelphia.net wrote:
    > I have a bit of a quandry and I'm not sure how to even begin the
    > math to solve it. I have a user that has a requirement to transfer
    > a 250 - 650Gb database across the network (WAN) in aprox 6 to 8
    > hours. I'm doing the math but I think i'm going in circles as far
    > as figuring out how much bandwidth they need. Anyone have a decent
    > formula to figure this out with? I'm about at wits end! Thanks in
    > advance!!


    I suspect it would be akin to solving:

    "Jane has 6 hours to travel from Washington, DC to San Francisco, a
    distance of ~2400 miles. At what speed must Jane travel to accomplish
    that task."

    keeping track of course, of the units you used as you look to convert
    your GBytes of data and Hours of transfer time to whatever units are
    used to describe the bandwidth of your WAN. I would suggest you use
    the maximum size of database and the minimum allowed time when doing
    the calculations.

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  3. Re: File Transfer Rates

    mcechman@adelphia.net wrote:
    : Hello all -
    : I have a bit of a quandry and I'm not sure how to even begin the math
    : to solve it. I have a user that has a requirement to transfer a 250 -
    : 650Gb database across the network (WAN) in aprox 6 to 8 hours. I'm
    : doing the math but I think i'm going in circles as far as figuring out
    : how much bandwidth they need. Anyone have a decent formula to figure
    : this out with? I'm about at wits end!
    : Thanks in advance!!


    Assuming this isn't some kind of homework question, in the real world there
    are too many variables to come up with an equation and say it's the rule to
    be followed.

    Also being asked on a group that deals with nfs, whatever servers and
    operating systems you are dealing with is about as important as the
    bandwidth between them.

    In a nutshell, a 100mb network isn't going to work. This sort of leaves the
    gigabit ethernet as your only option. I don't have any real world experience
    with it but I assume the performance of it over 100mb ethernet is similar to
    100mb over 10mb.

    To estimate the time involved with transfering files, you have to keep in
    mind the ever going conflict of terminology with megabits and megabytes.
    Ethernet (along with modems) generally use megabits in describing the speed
    while file sizes (reading the directory off a hard drive) is in megabytes.

    One issue to address is the fiddley bits (pun intended) with how many bits
    are in a byte (generally argued as 8 or 10) and if 1K of data is 1000 bytes
    or 1024. Personally I don't care. Rounding every thing off to 10/1000 is
    about as accurate as using 8/1024, real world.

    To solve your problem, assume you only have a 10mb ethernet to deal with,
    which was the state of the art 10 years ago. Basically the speed of it means
    it can handle 10,000,000 BITS of data per second. The file on you hard drive
    is measured in bytes, which by my rules are 10 bits to a byte. Dividing the
    10,000,000 by 10 means 1,000,000 bytes of data from your hard drive file can
    be transmitted over the ethernet per second.

    So if you have the 350meg version of the Paris Hilton sex video, two
    computers and a 10mb ethernet between them, your file is 350,000,000 bytes
    and your network can transfer 1,000,000 bytes per second, the time it would
    take to transfer it would be 350,000,000/1,000,000 or 350 seconds. Divide
    that by 60 (seconds in a minute) and you have "about 6 minutes" as your
    answer.

    Leaving everything the same except changing the 10mb ethernet to 100mb, your
    data now passes at 10,000,000 bytes per second, or 10 times faster than the
    10mb ethernet. So now, 350,000,000/10,000,000 is 35 seconds.

    Moving the same idea from 100mb to 1gb network, the result is 3.5 seconds.

    Moving to your question, you ask about moving 250gb to 650gb of data within
    a time limit of 6-8 hours. Keep in mind that data size is a 3x slop factor
    and probably should be narrowed down a bit.

    Anyway, forget about the time limit and plug in what you know. Assume to
    have a 100mb network, totally idle, a crossover cable going between two
    boxes.

    On the low side, you have 250,000,000,000 bytes of data and a network
    (100mb) that passes 10,000,000 bytes (not bits) per second. That is 25,000
    seconds or 25,000/60 is 416 minutes and divide that by 60 to get hours and
    that comes out to about 7 hours.

    So in this case, if your file stays around 250GB and you have a full
    bandwidth 100mb network available, you could get away with using a plain old
    100mb connection.

    Naturally if the file grows to 500GB, your time doubles to 14 hours and if
    it peaks at the 750GB, it'll take almost a day (21 hours).

    Again, assuming gigabit carries up proportionally, divide all of that by ten
    so 250GB would be 41.6 minutes, 500GB is around 83 minutes, 750GB is around
    2 hours.

    The point to make is simply that 10/100 isn't going to cut it. 100mb is
    barely going to fit the theory and only if it is working 100%.

    As I mentioned earlier, taking in other factors, everything from other
    network traffic, switch/hub counts, speed of your disks to server hardware
    and operating systems, the "real world" answer could be easily off by 100%
    and more.

    -bruce
    bje@ripco.com

  4. Re: File Transfer Rates


    "Bruce Esquibel" wrote in message
    news:e0tpap$msp$1@e250.ripco.com...
    > mcechman@adelphia.net wrote:
    > : Hello all -
    > : I have a bit of a quandry and I'm not sure how to even begin the math
    > : to solve it. I have a user that has a requirement to transfer a 250 -
    > : 650Gb database across the network (WAN) in aprox 6 to 8 hours. I'm
    > : doing the math but I think i'm going in circles as far as figuring out
    > : how much bandwidth they need. Anyone have a decent formula to figure
    > : this out with? I'm about at wits end!
    > : Thanks in advance!!
    >
    >
    > Assuming this isn't some kind of homework question, in the real world
    > there
    > are too many variables to come up with an equation and say it's the rule
    > to
    > be followed.
    >
    > Also being asked on a group that deals with nfs, whatever servers and
    > operating systems you are dealing with is about as important as the
    > bandwidth between them.
    >
    > In a nutshell, a 100mb network isn't going to work. This sort of leaves
    > the
    > gigabit ethernet as your only option. I don't have any real world
    > experience
    > with it but I assume the performance of it over 100mb ethernet is similar
    > to
    > 100mb over 10mb.
    >
    > To estimate the time involved with transfering files, you have to keep in
    > mind the ever going conflict of terminology with megabits and megabytes.
    > Ethernet (along with modems) generally use megabits in describing the
    > speed
    > while file sizes (reading the directory off a hard drive) is in megabytes.
    >
    > One issue to address is the fiddley bits (pun intended) with how many bits
    > are in a byte (generally argued as 8 or 10) and if 1K of data is 1000
    > bytes
    > or 1024. Personally I don't care. Rounding every thing off to 10/1000 is
    > about as accurate as using 8/1024, real world.
    >
    > To solve your problem, assume you only have a 10mb ethernet to deal with,
    > which was the state of the art 10 years ago. Basically the speed of it
    > means
    > it can handle 10,000,000 BITS of data per second. The file on you hard
    > drive
    > is measured in bytes, which by my rules are 10 bits to a byte. Dividing
    > the
    > 10,000,000 by 10 means 1,000,000 bytes of data from your hard drive file
    > can
    > be transmitted over the ethernet per second.
    >
    > So if you have the 350meg version of the Paris Hilton sex video, two
    > computers and a 10mb ethernet between them, your file is 350,000,000 bytes
    > and your network can transfer 1,000,000 bytes per second, the time it
    > would
    > take to transfer it would be 350,000,000/1,000,000 or 350 seconds. Divide
    > that by 60 (seconds in a minute) and you have "about 6 minutes" as your
    > answer.
    >
    > Leaving everything the same except changing the 10mb ethernet to 100mb,
    > your
    > data now passes at 10,000,000 bytes per second, or 10 times faster than
    > the
    > 10mb ethernet. So now, 350,000,000/10,000,000 is 35 seconds.
    >
    > Moving the same idea from 100mb to 1gb network, the result is 3.5 seconds.
    >
    > Moving to your question, you ask about moving 250gb to 650gb of data
    > within
    > a time limit of 6-8 hours. Keep in mind that data size is a 3x slop factor
    > and probably should be narrowed down a bit.
    >
    > Anyway, forget about the time limit and plug in what you know. Assume to
    > have a 100mb network, totally idle, a crossover cable going between two
    > boxes.
    >
    > On the low side, you have 250,000,000,000 bytes of data and a network
    > (100mb) that passes 10,000,000 bytes (not bits) per second. That is 25,000
    > seconds or 25,000/60 is 416 minutes and divide that by 60 to get hours and
    > that comes out to about 7 hours.
    >
    > So in this case, if your file stays around 250GB and you have a full
    > bandwidth 100mb network available, you could get away with using a plain
    > old
    > 100mb connection.
    >
    > Naturally if the file grows to 500GB, your time doubles to 14 hours and if
    > it peaks at the 750GB, it'll take almost a day (21 hours).
    >
    > Again, assuming gigabit carries up proportionally, divide all of that by
    > ten
    > so 250GB would be 41.6 minutes, 500GB is around 83 minutes, 750GB is
    > around
    > 2 hours.
    >
    > The point to make is simply that 10/100 isn't going to cut it. 100mb is
    > barely going to fit the theory and only if it is working 100%.
    >
    > As I mentioned earlier, taking in other factors, everything from other
    > network traffic, switch/hub counts, speed of your disks to server hardware
    > and operating systems, the "real world" answer could be easily off by 100%
    > and more.
    >
    > -bruce
    > bje@ripco.com


    Bruce,

    Most of the theory here is solid however real-world variables may affect
    the outcome.

    Other variables:
    Interconnect type: 10/100/1000/other ?
    Transport layer is: UDP or TCP ?
    Network loss: ? percentage of packets lost ?
    Duplex: Full, or Half.
    Retransmit timeout value ?
    Transport filesystem ? (NFS Version 2, Version 3, or CIFs, ftp,
    rcp,scp )?
    Transfer size ?
    Jumbo frames ?
    NIC type and buss ? ISA, PCI, PCI-X, 32 bit, 64 bit ?
    Network switches ? Any congestion here ?
    Operating systems at both ends of circuit ?
    Disk controllers at both ends of the circuit.
    Number and type of disks, at both ends of the circuit.
    NV-RAM, Disk caches at both ends of the circuit.

    Examples of where simple theory goes wrong.

    In theory above, a gigabit link would do 100 Mbyes/sec, BUT,
    if the transport filesystem is NFS Version 2, and writes are
    sync with the server storage (as required by the RFC), and
    the server receiving the file has a old SCSI drive, then the
    throughput would be 5 to 10 Mbytes/sec, not 100 Mbytes/sec.

    In theory above, a gigabit link would do 100 Mbyes/sec, BUT
    if the transport filesystem is NFS version 3, and the NFS client
    has a terabyte of memory and fast backplane, then the NFS
    client could appear to be transferring data at 800 to 1600
    Mbytes/sec.
    If the client had 10 NICs and was using port aggregation, then
    the data could be flowing async to the server at these rates too...

    In theory above, a gigabit link would do 100 Mbyes/sec, BUT
    the network filesystem type has overhead. NFS, CIFs, have
    some internal overhead that will reduce the throughput. Other
    remote filesystems have significantly lower overhead, and
    different internal mechanisms. Such as... clustered filesystems:
    Polyserve, GFS, GPFS, Lustre, Panasys.....

    The interconnect type is also a variable.
    10Mbit -> ~ 1 Mbyte/sec
    100Mbit -> ~10 Mbytes/sec
    1Gbit -> ~100 Mbytes/sec
    Quadrics -> ~300 to 800 Mbytes/sec (depending on type)
    10GigE -> ~ 1 Gbytes/sec
    Infiniband -> ~1 Gbytes/sec


    There are many variables in the real world that can cause
    over simplifications to become very unrealistic.
    To model the throughput one would need to know the
    speeds and feeds of each component in the path from
    end to end.

    There are many variables in the real world :-)

    Enjoy,
    Postmaster




  5. Re: File Transfer Rates

    mcechman@adelphia.net wrote:

    > Hello all -
    > I have a bit of a quandry and I'm not sure how to even begin the math
    > to solve it. I have a user that has a requirement to transfer a 250 -
    > 650Gb database across the network (WAN) in aprox 6 to 8 hours.


    I have found database backup files compress very well, maybe 10:1.

    That should help.

    -- glen


+ Reply to Thread