Testing UDP File Transfer Performance Over WAN - TCP-IP

This is a discussion on Testing UDP File Transfer Performance Over WAN - TCP-IP ; "Bruce Barnett" wrote in message news:yekzluku9dg.fsf@mail.grymoire.com... > bdwilcox@hotmail.com writes: > > > First, my company is using Microsoft's ZTP to push out Vista upgrades > > to 2000/XP clients over the LAN/WAN from a central server. ZTP > > primarily ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 36 of 36

Thread: Testing UDP File Transfer Performance Over WAN

  1. Re: Testing UDP File Transfer Performance Over WAN


    "Bruce Barnett" wrote in message
    news:yekzluku9dg.fsf@mail.grymoire.com...
    > bdwilcox@hotmail.com writes:
    >
    > > First, my company is using Microsoft's ZTP to push out Vista upgrades
    > > to 2000/XP clients over the LAN/WAN from a central server. ZTP
    > > primarily uses UDP to send its multi-gigabyte setup files to the
    > > clients and we need to ensure that we have adequate network
    > > performance to handle this kind of traffic. What I need to do is send
    > > out 4-6GBs of files at various times of the day and log how long it
    > > takes to send them to various clients using UDP. The ultimate goal is
    > > to emulate the UDP traffic that ZTP will generate and see if it brings
    > > our network to a crawl.

    >
    >
    > The real problem is that you are trying to characterize an application
    > without knowing how it performs.
    >
    > The problem with UDP is that it can swamp a network. TCP has
    > congestion control. UDP does not. Instead, the application must do
    > this.
    >
    > I have no idea what ZTP does for congestion control.
    >
    >
    > I think you need to first compare transfer times between ZTP and
    > the TCP version. You have to verify that the file arrived correctly
    > somehow. If you can measure bandwidth in both cases, that would be good.
    > Which one uses more bandwidth?
    >
    >
    >
    > Why are you considering ZTP? (I know nothign about it) The only real
    > advantage I see is that ZTP can use multicast, and may reduce overall
    > network usage.


    if you plan to use multicast so you only send 1 copy to multiple clients on
    the same site at the same time, then you just added another significant
    requirement.....
    >
    >
    > I'd do a trial in a test network with no traffic.
    > I'd then try it again with a constant stream of traffic.
    > You could use ttcp, netperf, netcat, FTP, or a traffic generator.
    >
    > As a minimum, I'd try it with zero background traffic, and a "busy"
    > traffic.
    >
    > If you know what the expected traffic is when ZTP will be used, you
    > can try to duplicate this.
    >
    > If this is mission critical, a DoE (Design of Experiment) can be used
    > to determine the effect of each of the parameters.
    >
    > Are there routers involved? SNMP can be used to measure bandwidth.
    > But traffic through the routers can also affect the measurement.
    >
    >
    >
    > If you can't set up a test network, I'd set up a test of the real
    > network with small files. Then increase the file size and refine your

    tests.
    >
    > --
    > Posted via a free Usenet account from http://www.teranews.com
    >

    --
    Regards

    stephen_hope@xyzworld.com - replace xyz with ntl



  2. Re: Testing UDP File Transfer Performance Over WAN

    wrote in message
    news:1c0cfb8a-7447-4069-805d-d17e45a7391e@v17g2000hsa.googlegroups.com...
    > First of all, thank you all for replying. I've learned quite a bit
    > from the discussion and have gained insight into the task at hand. I
    > seem to have underestimated the complexity of what I'm up against, so
    > let me elaborate on what I'm facing and what I need.
    >
    > First, my company is using Microsoft's ZTP to push out Vista upgrades
    > to 2000/XP clients over the LAN/WAN from a central server. ZTP
    > primarily uses UDP to send its multi-gigabyte setup files to the
    > clients and we need to ensure that we have adequate network
    > performance to handle this kind of traffic. What I need to do is send
    > out 4-6GBs of files at various times of the day and log how long it
    > takes to send them to various clients using UDP. The ultimate goal is
    > to emulate the UDP traffic that ZTP will generate and see if it brings
    > our network to a crawl.
    >
    > In the past, I've done this for TCP/IP traffic testing using
    > Robocopy. I create a very simple batch file that tells Robocopy to
    > send files to a remote share and append its results to a log. I then
    > kick it off at various intervals using Window's Task Scheduler. It
    > works great and is very simple. For example, this batch file tells
    > Robocopy to delete everything off of a mapped share (T then copy
    > files to the share and append its performance log to a file called
    > robo.txt:


    if you have servers on each site, why not copy to those servers and do
    replication locally?

    "lots of clients" and "Gbytes of data" and "WAN distribution" together are
    not easy to mix well.....

    1 copy, 1 Gbyte of file, 1 Mbps of bandwidth and no overheads = 8000 sec or
    2.2 hours transfer time.

    If you replicate it, you could even use your existing, working Robocopy
    system to replicate to a local server, then serve from there.

    if you are going to have problems with bandwidth - then local transfers
    across a LAN will be faster, and it is easier / faster and cheaper to
    upgrade LANs or local server interfaces than WANs.....

    the flip side of having a set of servers is to look at the cost of
    complexity and extra servers vs the cost of any needed WAN bandwidth.

    >
    > t:
    > cd\
    > echo Y|del *.*
    > c:
    > cd\
    > robocopy c:\tcptest t:\ /S /E /COPYAT /NP /R:10 /W:30 /LOG+:C:
    > \robo.txt
    >
    > The log it creates is perfect for what I need, listing file size(s),
    > total time of transmission, and subsequent average data rate. The log
    > looks like this:
    >
    > --------------------------------------------------------------------------

    -----
    > ROBOCOPY :: Robust File Copy for Windows :: Version
    > XP026
    > --------------------------------------------------------------------------

    -----
    >
    > Started : Thu Jan 31 18:51:37 2008
    >
    > Source : c:\tcptest\
    > Dest : t:\
    >
    > Files : *.*
    >
    > Options : *.* /S /E /COPYAT /NP /R:10 /W:30
    >
    > --------------------------------------------------------------------------

    ----
    >
    > 4 c:\udpsend\
    > New File 688.6 m test3.iso
    > New File 688.6 m test2.iso
    > New File 688.6 m test1.iso
    > New File 688.6 m test0.iso
    >
    > --------------------------------------------------------------------------

    ----
    >
    > Total Copied Skipped Mismatch FAILED
    > Extras
    > Dirs : 1 0 1 0 0
    > 0
    > Files : 4 4 0 0 0
    > 0
    > Bytes : 2.690 g 2.690 g 0 0 0
    > 0
    > Times : 0:02:03 0:01:48 0:00:00
    > 0:00:14
    >
    > Speed : 26502888 Bytes/sec.
    > Speed : 1516.507 MegaBytes/min.
    >
    > Ended : Thu Jan 31 18:53:40 2008
    >
    > Is there any UDP based program that can give me this kind of
    > straightforward result?
    >
    > BTW, I looked at the Windows version of tftp and it lacked the logging
    > features I needed and wouldn't go over 32MBs as Robert Wessel
    > indicated. Skybuck Flying's program looks promising, but I can't
    > code at all (I can hardly write a batch file) and that leaves me
    > without the logging option. I tried out TTCP but it didn't give me
    > the option of selecting a file of my choice, only sending
    > patterns(?). I started to poke around at a Windows version of
    > NetPerf, but it's a very intimidating program. Finally, using the ZTP
    > app to test ZTP performance is out of the question for me as its
    > implementation is still unfinished and the team won't relinquish it
    > until it's been tested and validated.
    >
    > Thanks for any more insight you can provide.
    >
    > -Brian Wilcox

    --
    Regards

    stephen_hope@xyzworld.com - replace xyz with ntl



  3. Re: Testing UDP File Transfer Performance Over WAN

    The program that Skybuck Flying referenced (UDT) is basically what I'm
    looking for but it has three deficiencies that keep it from fitting my
    needs. First, it only allows me to request a single file; this
    normally wouldn't be a deal-killer, but it has a file size limitation
    of 2GB or so and I need to send 4-6GBs. I could send more than one
    file sequentially but that leads to the second, and more frustrating,
    problem.

    With UDT, two events must occur for a file to be transferred. First,
    the server component needs to be turned on so it can wait and listen
    for a send request. Then, the receiver component must be turned so it
    can send a request to the server asking it to serve up the file.
    After this, the server sends the file to the requestor and once the
    transmission is over the server closes.

    My scripting conundrum is thus: Since the server will be off since the
    last transmission, I would somehow need to script a way to turn on the
    server, then turn on the requestor. If my script was on the server, it
    would need to turn on the local server then reach out to a remote
    machine to turn on the receiver. Conversely, if my script was on the
    receiver, it would need to reach out to the remote machine to turn on
    the server, then fire off the local receiver. (Having separate
    scripts on two different machines, one for the server and one for the
    receiver, would be a little hairy due to slight differences in timing,
    scheduling between the machines, etc. but is a possibility) In
    theory, this all sounds simple, but I have never been able to get a
    batch file on machine A to start a program on machine B so that that
    program behaves as if it's running on machine B. Anyone have any
    ideas?

    Finally, Robocopy allows me to point to a directory and it then simply
    copies everything in that directory. This is a great feature and
    would allow me to test sending a mixed bag of various sized files in
    addition to just one huge, monolithic file. The design of UDT
    precludes this test since it will only send a single file per request
    and scheduling one file after another doesn't seem possible due to the
    conflict between scheduling times and transmission times that could
    overlap and collide.

    Thanks again for all your time and help. It is much appreciated.

    Brian Wilcox

  4. Re: Testing UDP File Transfer Performance Over WAN

    In article <9a21a12d-0526-48a2-8e6d-917f3ce23bcc@s8g2000prg.googlegroups.com>,
    wrote:
    >Conversely, if my script was on the
    >receiver, it would need to reach out to the remote machine to turn on
    >the server, then fire off the local receiver.


    >In
    >theory, this all sounds simple, but I have never been able to get a
    >batch file on machine A to start a program on machine B so that that
    >program behaves as if it's running on machine B. Anyone have any
    >ideas?


    rsh or (better for security but more overhead) ssh are routinely
    used for initiating remote processes. rsh and ssh -are- available
    for Windows; I know because I have both here. I do not know, though,
    how much infrastructure you need to support rsh or ssh; I probably
    picked mine up as part of AT&T's WinU or part of cygwin, but
    I seem to recall having seen stand-alone versions of the daemons
    native for Windows.

  5. Re: Testing UDP File Transfer Performance Over WAN


    wrote in message
    news:9a21a12d-0526-48a2-8e6d-917f3ce23bcc@s8g2000prg.googlegroups.com...
    > The program that Skybuck Flying referenced (UDT) is basically what I'm
    > looking for but it has three deficiencies that keep it from fitting my
    > needs. First, it only allows me to request a single file; this
    > normally wouldn't be a deal-killer, but it has a file size limitation
    > of 2GB or so and I need to send 4-6GBs.


    Hmm I didn't know about the filesize limitation. I looked quickly at the
    source code and it seems to use 64 bit integers.

    Maybe it's some kind of bug somewhere, or maybe it is indeed a serious
    limitation.

    Whatever the case may be, I tried it, and it doesn't work for 5 GB files.

    > I could send more than one
    > file sequentially but that leads to the second, and more frustrating,
    > problem.
    >
    > With UDT, two events must occur for a file to be transferred. First,
    > the server component needs to be turned on so it can wait and listen
    > for a send request. Then, the receiver component must be turned so it
    > can send a request to the server asking it to serve up the file.
    > After this, the server sends the file to the requestor and once the
    > transmission is over the server closes.


    Batch files can have loops in them, so the sendfile.exe (server) could be
    restarted after it finishes.

    Here is an example:

    :loop
    pause
    goto loop

    Simply replace pause with the lines of previous posting/batch file and then
    the server will always loop.

    Use control-break keyboard/key combination to terminate batch files.

    So this way you could for example run multiple "servers" on different
    machines.

    And then request files from all kinds of machines.

    You could even use the loop technique on other machines as well to
    repeatedly request files after the transfer is done.

    And finally somebody mentioned some console/login functionality into remote
    machines, that might be a solution if you want to control different
    computers from a central location.

    I myself have used REALVNC (remote control software) works nicely, and you
    can see a gui as well. (free and commercial versions available)

    http://www.realvnc.com/products/download.html

    Bye,
    Skybuck.



  6. Re: Testing UDP File Transfer Performance Over WAN

    Rick Jones writes:

    > Bruce Barnett wrote:
    >> Rick Jones writes:
    >> > Sigh, my goal of replacing ttcp remains unmet

    >> Sorry, Rick. :-) I still use ttcp at times, especially when doing 6
    >> sigma analysis. There are times when a Design of Experiment needs a
    >> series of tests, and I find ttcp easier to tweak the parameters.

    >
    > Out of curiousity, which parms?



    It's been a while since the last time, but they might include
    Filesize
    Block/Segment Size
    Disk vs memory I/0
    Window Buffer
    Real Time scheduling
    Buffer/Memory Alignment
    TCP vs DCCP VS UDP
    Client vs Server parameters

    Sometimes I also synchornize this with another process that throttles
    bandwidth.


    >> I do have to write a scrpit that changes the port number for each
    >> test, to make sure the client and server are synchronized.

    >
    > I finally had to "choose your own port number for each side" stuff to
    > satisfy the folks wanting to run through firewalls


    Yeah. I did it because if I started the client and server at the same
    time, and if the client from run #3 was talking to the server that was
    on run #4, it would invalidate the entire DoE, and I'd have to repeat
    everything.

    --
    Posted via a free Usenet account from http://www.teranews.com


  7. Re: Testing UDP File Transfer Performance Over WAN

    roberson@hushmail.com (Walter Roberson) writes:

    > rsh or (better for security but more overhead) ssh are routinely
    > used for initiating remote processes. rsh and ssh -are- available
    > for Windows; I know because I have both here. I do not know, though,
    > how much infrastructure you need to support rsh or ssh; I probably
    > picked mine up as part of AT&T's WinU or part of cygwin, but
    > I seem to recall having seen stand-alone versions of the daemons
    > native for Windows.


    PUTTY is a Windows SSH terminal. There's a scp variation (pscp) and
    FTP variation as well.
    http://www.chiark.greenend.org.uk/~s.../download.html

    You can probably use it to initiate transactions.

    --
    Posted via a free Usenet account from http://www.teranews.com


  8. Re: Testing UDP File Transfer Performance Over WAN

    Skybuck,

    U DA' MAN!!!

    Got it working and it works great! Thank you, thank you, thank you!
    And a huge thanks to everyone else who helped me with this problem.

    Let me go into detailed steps how I got this to work.


    1) Download UDT from:
    http://sourceforge.net/project/downl...2.zip&93154643

    2) Create a folder on the "server" machine and call it what you like:
    for my example, I'll create it on the root and call it UDTSERV

    3) Create a folder on the "client" machine and call it what you like:
    for my example, I'll create it on the root and call it UDTCLNT

    4) Unzip the file you downloaded in step 1 and copy the contents of
    the UDT4\App folder into both the UDTSERV and UDTCLNT folders you
    created in steps 2 and 3 (you should see the files recvfile.exe,
    sendfile.exe, recvfile.cpp, sendfile.cpp, udt.dll, etc.)

    5) In the UDTSERV folder place the files you want to transfer*. I
    used dummy files I created using a free app called Dummy File Creator
    that allows me to create dummy files of any size that can be filled
    with random data to prevent network equipment from highly compressing
    them and giving a false sense of speed. I used the following file
    names:

    test0.tst
    test1.tst
    test2.tst
    test3.tst
    test4.tst
    test5.tst
    test6.tst
    test7.tst
    test8.tst
    test9.tst

    * Remember, UDT cannot copy individual files over 2GB in size.

    You can get Dummy File Creator here:
    http://www.mynikko.com/dummy/

    6) In the UDTSERV folder create the following batch-file (I called it
    SERVER.BAT):

    @ECHO OFF
    :loop
    DATE /T >> SERVELOG.TXT
    sendfile.exe >> SERVELOG.TXT
    TIME /T >> SERVELOG.TXT
    ECHO ===================== >> SERVELOG.TXT
    goto loop

    7) Find out the IP address of your "server" machine. In my example,
    it's 0.0.0.0

    8) In the UDTCLNT folder, create the following batch-file using your
    server's IP address where mine says 0.0.0.0 (I called it CLIENT.BAT):

    @ECHO OFF
    Date /T >> CLNTLOG.TXT
    ECHO START >> CLNTLOG.TXT
    Time /T >> CLNTLOG.TXT
    recvfile.exe 0.0.0.0 9000 test0.tst test0.tst >> CLNTLOG.TXT
    recvfile.exe 0.0.0.0 9000 test1.tst test1.tst >> CLNTLOG.TXT
    recvfile.exe 0.0.0.0 9000 test2.tst test2.tst >> CLNTLOG.TXT
    recvfile.exe 0.0.0.0 9000 test3.tst test3.tst >> CLNTLOG.TXT
    recvfile.exe 0.0.0.0 9000 test4.tst test4.tst >> CLNTLOG.TXT
    recvfile.exe 0.0.0.0 9000 test5.tst test5.tst >> CLNTLOG.TXT
    recvfile.exe 0.0.0.0 9000 test6.tst test6.tst >> CLNTLOG.TXT
    recvfile.exe 0.0.0.0 9000 test7.tst test7.tst >> CLNTLOG.TXT
    recvfile.exe 0.0.0.0 9000 test8.tst test8.tst >> CLNTLOG.TXT
    recvfile.exe 0.0.0.0 9000 test9.tst test9.tst >> CLNTLOG.TXT
    ECHO FINISH >> CLNTLOG.TXT
    Time /T >> CLNTLOG.TXT
    ECHO ====================== >> CLNTLOG.TXT

    9) Run the SERVER.BAT file on the "server" machine and it will keep
    running and serving files indefinitely. (It will serve up the files
    to any machine on the network that makes a properly formatted request
    through the recvfile.exe client.)

    10) To run a file-transfer test, run the CLIENT.BAT file on the
    "client" machine and it will copy the files from the "server", record
    in CLNTLOG.TXT when it started and ended transferring the files, then
    exit. If you re-run the batch-file, it will automatically overwrite
    (i.e. without prompting you) the files it transferred in a previous
    session. Each transfer session will be logged in the file CLNTLOG.TXT
    and will look like:

    Sun 02/03/2008
    START
    01:04 AM
    FINISH
    01:08 AM
    ======================
    Sun 02/03/2008
    START
    01:09 AM
    FINISH
    01:11 AM
    ======================
    Sun 02/03/2008
    START
    01:12 AM
    FINISH
    01:15 AM
    ======================

    The start and end time for total file-transfers are recorded.
    Subtract the Start time from the Finish time to get the total time
    needed to transfer your files, then divide the total size of your
    transferred files by the total time to get the average transmission
    rate. For scheduled tests, you can kick the client batch-file off at
    designated times by using Window's built-in task-scheduler found in
    Control Panel (Scheduled Tasks).





  9. Re: Testing UDP File Transfer Performance Over WAN

    Little correction.

    UDT4 probably reports speed in kilobits / sec.

    Bit weird

    Me keeps forgetting that

    Bye,
    Skybuck.



  10. Re: Testing UDP File Transfer Performance Over WAN

    Hmm,

    The source file shows:

    Megabits per second.

    However the dot is probably the decimal seperator.

    So

    233.567

    Would mean:

    233 Mbit/sec

    And not 233 thousand Mbit/sec

    Bye,
    Skybuck.



  11. Re: Testing UDP File Transfer Performance Over WAN

    Bruce Barnett wrote:
    > Rick Jones writes:
    > > Out of curiousity, which parms?


    > It's been a while since the last time, but they might include


    > Filesize


    Given that netperf doesn't actually transfer a file... you've got me
    there Still, the breadth of data from which netperf will send() or
    to which it will recv() is controllable via the "width" of the
    send/recv buffer rings. The sendfile() (system call) stuff has been
    augmented that if you don't pass it a file (-F options) it will create
    one based on the above.

    > Block/Segment Size


    At the transport level? You mean making a setsockopt(TCP_MAXSEG) call?

    > Disk vs memory I/0


    Again goes back to not actually transferring a file

    > Window Buffer


    ?

    > Real Time scheduling


    I assume you mean the scheduling in the end system? Indeed, netperf doesn't try to make any calls to change its scheduling situation.

    > Buffer/Memory Alignment


    That's been there since day one -a and -A for local and remote
    buffer alignment, -o and -O for local and remote offset from that
    alignment.

    > TCP vs DCCP VS UDP


    As it happens, just last Friday I got the new netperf "omni" tests
    transferring data via DCCP

    > Client vs Server parameters


    Hmm, netperf command line options cover both ends of the data
    "connection" so this one is a triffle surprising.

    > Sometimes I also synchornize this with another process that throttles
    > bandwidth.



    > Yeah. I did it because if I started the client and server at the
    > same time, and if the client from run #3 was talking to the server
    > that was on run #4, it would invalidate the entire DoE, and I'd have
    > to repeat everything.


    Ah, that is something which is avoided with having both client and
    server side settings coming from the netperf command line.

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    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...

  12. Re: Testing UDP File Transfer Performance Over WAN

    On Feb 3, 12:56 am, bdwil...@hotmail.com wrote:
    > Skybuck,
    >
    > U DA' MAN!!!
    >
    > Got it working and it works great! Thank you, thank you, thank you!
    > And a huge thanks to everyone else who helped me with this problem.



    Let me reiterate that this tells you nothing about the performance or
    network impact of a different UDP file transfer program, unless you
    have some evidence that they work in a similar fashion. Given some of
    the claims made by the author in the past, it's likely that the
    program in question is likely to be an extraordinarily bad network
    citizen, particularly on a WAN.

    Mind you that MS does *not* recommend running BDD/ZTI/ZTP over a LAN,
    and I quote:

    http://www.microsoft.com/technet/des...FTGuide_6.mspx

    "Providing Adequate Network Capacity
    Because of the size of the SMS 2003 OSD Feature Pack images being
    distributed to the workstations (500 MB-4 GB), your workstations need
    to have a high-speed, persistent connection to the servers used in the
    deployment process. These servers include:

    * SMS site servers

    * SMS distribution points

    * RIS servers

    * Servers hosting shared folders used to store user migration state
    data and deployment logs


    These servers should be on adjacent subnets to the workstations to
    ensure high-speed connectivity to the workstations. If you are unable
    to provide sufficient network capacity to deploy to a workstation,
    perform one of the following actions:

    * Temporarily place the appropriate servers (for example, SMS
    distribution point, RIS server) closer to the workstation for the
    duration of the migration.

    * Temporarily move the workstations to a staging area where the
    workstations can be deployed and then returned to their original
    location.

    * Store user state migration data locally on the workstation.

    * Perform automated deployments locally by using a combination of a
    Windows PE CD or an SMS 2003 OSD Feature Pack image CD.


    In addition, when you want to deploy to workstations through a
    firewall, you need to ensure that the appropriate TCP and UDP ports
    are opened on firewalls. For more information, see Ports that Systems
    Management Server 2003 uses to communicate through a firewall or
    through a proxy server in Additional Resources later in this guide."

  13. Re: Testing UDP File Transfer Performance Over WAN

    On Mon, 04 Feb 2008 14:34:56 -0800, robertwessel2@yahoo.com wrote:

    > On Feb 3, 12:56 am, bdwil...@hotmail.com wrote:
    >> Skybuck,
    >>
    >> U DA' MAN!!!
    >>
    >> Got it working and it works great! Thank you, thank you, thank you!
    >> And a huge thanks to everyone else who helped me with this problem.

    >
    >
    > Let me reiterate that this tells you nothing about the performance or
    > network impact of a different UDP file transfer program, unless you have
    > some evidence that they work in a similar fashion. Given some of the
    > claims made by the author in the past, it's likely that the program in
    > question is likely to be an extraordinarily bad network citizen,
    > particularly on a WAN.
    >
    > Mind you that MS does *not* recommend running BDD/ZTI/ZTP over a LAN,
    > and I quote:


    So besides that it will not work, it will swamp your WAN. That can be
    helped, see my other post, but this is the killer.

    So in the end, OP, go back to your employer and tell him it cannot be
    done.

    M4

  14. Re: Testing UDP File Transfer Performance Over WAN

    Rick Jones writes:

    >> Block/Segment Size

    >
    > At the transport level? You mean making a setsockopt(TCP_MAXSEG) call?


    Buffer size/length i.e. -l ###

    >
    >> Disk vs memory I/0

    >
    > Again goes back to not actually transferring a file


    The disk vs. file is useful because when some people say the network is slow,
    the real reason may be disk I/O. It's useful to isolate the difference.


    >
    >> Window Buffer

    >
    > ?


    Sorry - Socket buffer size - setsockopt(fd, SOL_SOCKET, SO_SNDBUF

    >
    >> Real Time scheduling

    >
    > I assume you mean the scheduling in the end system? Indeed, netperf
    > doesn't try to make any calls to change its scheduling situation.


    I found that this can make a big difference in reliability of UDP
    datagrams in 1995.


    >> Client vs Server parameters

    >
    > Hmm, netperf command line options cover both ends of the data
    > "connection" so this one is a triffle surprising.


    I was using the older version of netperf at the time, I guess.

    --
    Posted via a free Usenet account from http://www.teranews.com


  15. Re: Testing UDP File Transfer Performance Over WAN

    Bruce Barnett wrote:
    > Rick Jones writes:


    > >> Block/Segment Size

    > >
    > > At the transport level? You mean making a setsockopt(TCP_MAXSEG) call?


    > Buffer size/length i.e. -l ###


    In netperf that is -m for the send buffer, -M for the receive buffer.

    > >> Window Buffer

    > > ?


    > Sorry - Socket buffer size - setsockopt(fd, SOL_SOCKET, SO_SNDBUF


    -s for local socket buffer sizes, -S for remote socket buffer sizes.

    > >> Real Time scheduling

    > >
    > > I assume you mean the scheduling in the end system? Indeed, netperf
    > > doesn't try to make any calls to change its scheduling situation.


    > I found that this can make a big difference in reliability of UDP
    > datagrams in 1995.




    > >> Client vs Server parameters

    > >
    > > Hmm, netperf command line options cover both ends of the data
    > > "connection" so this one is a triffle surprising.


    > I was using the older version of netperf at the time, I guess.


    Well, netperf has "always" sent parameters for the remote over the
    control connection. Now, the number of things sent has increased over
    time, but the basics - socket buffer sizes, size of buffers passed to
    send/recv have been there since day one.

    rick jones
    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    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...

  16. Re: Testing UDP File Transfer Performance Over WAN

    In article ,
    Martijn Lievaart wrote:
    >On Thu, 31 Jan 2008 18:47:27 -0800, bdwilcox wrote:
    >
    >> First of all, thank you all for replying. I've learned quite a bit from
    >> the discussion and have gained insight into the task at hand. I seem to
    >> have underestimated the complexity of what I'm up against, so let me
    >> elaborate on what I'm facing and what I need.
    >>
    >> First, my company is using Microsoft's ZTP to push out Vista upgrades to
    >> 2000/XP clients over the LAN/WAN from a central server. ZTP primarily
    >> uses UDP to send its multi-gigabyte setup files to the clients and we
    >> need to ensure that we have adequate network performance to handle this
    >> kind of traffic. What I need to do is send out 4-6GBs of files at
    >> various times of the day and log how long it takes to send them to
    >> various clients using UDP. The ultimate goal is to emulate the UDP
    >> traffic that ZTP will generate and see if it brings our network to a
    >> crawl.

    >
    >The obvious solution. one I am implementing right now on our WAN,
    >* Make sure all your routers use fair base queueing (default is fifo,
    >which is killing for this kind of applications)
    >* If possible, start using QoS on your WAN


    You could also capture ZTP traffic with something like WireShark
    (http://www.wireshark.org) on your local source machine and examine the
    captured results to find start/stop times.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2