Testing UDP File Transfer Performance Over WAN - TCP-IP

This is a discussion on Testing UDP File Transfer Performance Over WAN - TCP-IP ; Hi, My company is using a piece of software that delivers large files over our LAN/WAN using the UDP protocol (It was their decision, not mine) I have been tasked with testing data transmission rates over the LAN/ WAN using ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 36

Thread: Testing UDP File Transfer Performance Over WAN

  1. Testing UDP File Transfer Performance Over WAN

    Hi,

    My company is using a piece of software that delivers large files over
    our LAN/WAN using the UDP protocol (It was their decision, not mine)

    I have been tasked with testing data transmission rates over the LAN/
    WAN using the UDP protocol. Basically, what I need to do is send xGB
    files over the network and log how long it takes to transmit the
    data. I'm sure I can batch file most of the work and use Task
    Scheduler to kick it off, but does anyone know of a Windows based
    program that will send a file using UDP and log how long it takes
    (either at the server end or the receiver end)?

    The tool doesn't necessarily have to be free, but I don't have a huge
    budget for this either.

    Thank You,

    Brian Wilcox

  2. Re: Testing UDP File Transfer Performance Over WAN

    bdwilcox@hotmail.com wrote:
    > I have been tasked with testing data transmission rates over the LAN/
    > WAN using the UDP protocol. Basically, what I need to do is send xGB
    > files over the network and log how long it takes to transmit the
    > data. I'm sure I can batch file most of the work and use Task
    > Scheduler to kick it off, but does anyone know of a Windows based
    > program that will send a file using UDP and log how long it takes
    > (either at the server end or the receiver end)?


    You could try tftp (trivial ftp) which uses UDP and does file transfers.
    Could be just the ticket for generating a known amount of traffic.

    A Google search should yield some hits for Windows versions. The Wikipedia
    page for tftp (http://en.wikipedia.org/wiki/Trivial...nsfer_Protocol)
    lists includes a link to an alleged Windows port:

    http://pagesperso-orange.fr/philippe...n/tftpd32.html

  3. Re: Testing UDP File Transfer Performance Over WAN

    In article ,
    Jim Logajan wrote:
    >bdwilcox@hotmail.com wrote:
    >> I have been tasked with testing data transmission rates over the LAN/
    >> WAN using the UDP protocol. Basically, what I need to do is send xGB
    >> files over the network and log how long it takes to transmit the
    >> data. I'm sure I can batch file most of the work and use Task
    >> Scheduler to kick it off, but does anyone know of a Windows based
    >> program that will send a file using UDP and log how long it takes
    >> (either at the server end or the receiver end)?

    >
    >You could try tftp (trivial ftp) which uses UDP and does file transfers.
    >Could be just the ticket for generating a known amount of traffic.


    tftp uses a strict send/reply protocol, so unless the original poster's
    file protocol does the same, measuring tftp would likely
    greatly underestimate the potential network performance.

    It seems to me that netperf would likely be better for the
    original poster's purposes.

    http://www.netperf.org/netperf/NetperfPage.html

  4. Re: Testing UDP File Transfer Performance Over WAN

    On Jan 30, 9:08 pm, bdwil...@hotmail.com wrote:
    > Hi,
    >
    > My company is using a piece of software that delivers large files over
    > our LAN/WAN using the UDP protocol (It was their decision, not mine)
    >
    > I have been tasked with testing data transmission rates over the LAN/
    > WAN using the UDP protocol. Basically, what I need to do is send xGB
    > files over the network and log how long it takes to transmit the
    > data. I'm sure I can batch file most of the work and use Task
    > Scheduler to kick it off, but does anyone know of a Windows based
    > program that will send a file using UDP and log how long it takes
    > (either at the server end or the receiver end)?
    >
    > The tool doesn't necessarily have to be free, but I don't have a huge
    > budget for this either.



    File transfer via UDP doesn't actually tell you anything. As
    mentioned elsewhere, a simple TFTP client and server will do that.
    There are servers and client built in to any *nix, and there are
    dozens of free/share/trialware versions for Windows (there's even a
    command line client built into Windows - "tftp").

    If there's a command line client, it will likely be willing to produce
    some stats that you can redirect to a file to capture. For example,
    the Windows TFTP client generates the following:

    "Transfer successful: 897769 bytes in 1 second, 897769 bytes/s"

    Anyway, that doesn't actually help you at all. While two TCP based
    file transfer programs will likely perform similarly, since flow
    control and whatnot happens in TCP, and thus ends up more-or-less the
    same for both packages, there's none of that in UDP - any such thing
    has to be provided by the application. In the case of TFTP, it's a
    trivial protocol - it waits for an Ack after every packet. That's
    usually going to be slow. If you have an application that does UDP
    file transfers, and performs reasonably, its going to have to
    implement windowing, flow control, and all sorts of stuff, and unless
    you have another application that duplicates that, your test will not
    tell you anything.

    To further illustrate the problem, TFTP, while using UDP to transfer
    files, only supports files of 32MB if the client and/or server
    implements the base RFC1350 protocol. RFC2347/2348 add options to
    negotiate support for larger files, although those are not supported
    by many clients and servers.

    So basically you'll need to test with the application in question.

    A further issue is going to be your firewall configuration - any UDP
    traffic of this sort is almost certainly going to be blocked, and
    you'll have to get your firewall guys to open up the appropriate
    holes.


  5. Re: Testing UDP File Transfer Performance Over WAN

    If you can program a little bit in C or C++ you could give UDT 4.0 a try and
    add the logging functionality.

    Alternatively:

    I myself wrote some programs like, udp speed test and udp file transfer,
    they don't have logging functionality but maybe they are of some use to you


    Don't let the java word fool you, they are 100% pure windows applications:

    http://www.myjavaserver.com/~skybuck/

    Bye,
    Skybuck.



  6. Re: Testing UDP File Transfer Performance Over WAN

    bdwilcox@hotmail.com writes:

    > My company is using a piece of software that delivers large files over
    > our LAN/WAN using the UDP protocol (It was their decision, not mine)



    On UNIX systems, I use the program ttcp.c - if you can compile it, you
    can try it. It has all the options needed to adjust any parameter.
    The downside is that it runs once. If you want to analyse performance,
    you need to script it into a series of tests.

    Netperf is a client/server benchmark program that can be to tech the
    network any tim ethe client starts up.

    Be warned that measuring throughput of UDP is unreliable. A Unix
    system can tell you a datagram was accepted to be sent, but if the
    buffer is exceeded, the datagram may never make it to the wire. You
    need to make sure it was received. That is, ttcp will tell you that
    10,000 UDP packets were sent, but (say) 5,000 were received.

    As you should know, there is no need to even have a receiver on the
    other end.


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


  7. Re: Testing UDP File Transfer Performance Over WAN

    Bruce Barnett wrote:
    > On UNIX systems, I use the program ttcp.c - if you can compile it,
    > you can try it. It has all the options needed to adjust any
    > parameter. The downside is that it runs once. If you want to
    > analyse performance, you need to script it into a series of tests.


    Sigh, my goal of replacing ttcp remains unmet

    > Netperf is a client/server benchmark program that can be to tech the
    > network any tim ethe client starts up.


    > Be warned that measuring throughput of UDP is unreliable. A Unix
    > system can tell you a datagram was accepted to be sent, but if the
    > buffer is exceeded, the datagram may never make it to the wire. You
    > need to make sure it was received. That is, ttcp will tell you that
    > 10,000 UDP packets were sent, but (say) 5,000 were received.


    Similarly for a netperf UDP_STREAM test. Netperf will say how many
    send() calls were seemingly successful, how many knowingly "failed"
    and how many bytes the remote actually received.

    One cannot really rely on getting a ENOBUFs today to say that the
    send() wont make it onto the wire. Streams-based stacks have no call
    return path to return that value a al BSD. Some stacks though do have
    "intra-stack" flow control and will pause the sending application. On
    such systems you will notice that netperf reports sending at link
    rate, and something other than a CPU being saturated (when CPU util is
    requested).

    > As you should know, there is no need to even have a receiver on the
    > other end.


    Well, there is if you want to know what actually made it across the
    network without a sniffer, and one could argue that a sniffer on the
    remote network is akin to having a receiver on the remote .

    happy benchmarking,

    rick jones
    --
    The glass is neither half-empty nor half-full. The glass has a leak.
    The real question is "Can it be patched?"
    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...

  8. Re: Testing UDP File Transfer Performance Over WAN

    On Thu, 31 Jan 2008 18:46:45 +0000, Rick Jones wrote:

    >
    > Sigh, my goal of replacing ttcp remains unmet
    >


    Netcat?

    M4

  9. Re: Testing UDP File Transfer Performance Over WAN

    Martijn Lievaart wrote:
    > On Thu, 31 Jan 2008 18:46:45 +0000, Rick Jones wrote:
    > > Sigh, my goal of replacing ttcp remains unmet

    > Netcat?


    OK, that tells me that netperf will never replace ttcp since netperf
    won't ever act like a pipe

    happy benchmarking

    rick Jones
    --
    The glass is neither half-empty nor half-full. The glass has a leak.
    The real question is "Can it be patched?"
    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...

  10. Re: Testing UDP File Transfer Performance Over WAN

    wrote in message
    news:9e236dc2-12c6-4b6e-ae41-db711df2e0b0@q21g2000hsa.googlegroups.com...
    > Hi,
    >
    > My company is using a piece of software that delivers large files over
    > our LAN/WAN using the UDP protocol (It was their decision, not mine)
    >
    > I have been tasked with testing data transmission rates over the LAN/
    > WAN using the UDP protocol. Basically, what I need to do is send xGB
    > files over the network and log how long it takes to transmit the
    > data. I'm sure I can batch file most of the work and use Task
    > Scheduler to kick it off, but does anyone know of a Windows based
    > program that will send a file using UDP and log how long it takes
    > (either at the server end or the receiver end)?


    maybe you need to be clearer about what you want to test - either network
    possible thruput, a UDP app, or your specific app.

    for network throughput the high end way is a traffic generator / analyser
    such as a Spirent Smartbits, or an Agilent N2X
    (or 2 and GPS to sync them up if you dont have a test bed in a single lab).

    a cheaper way is spray traffic from the sending end, and see what falls out
    the other end, and "assume" that this gives a rough upper bound for what you
    might get, with no competition for bandwidth and a well designed app (pretty
    big assumptions though).

    Also - overloading your network link like that is when you find out if you
    have a robust design......

    If you dont have the network right now, or it is in use, you have a big
    problem - test to destruction schemes (or just "give me everything so i can
    test it") belong in a lab, not on a production system.

    a generic UDP transfer - well you will get wildly different results
    depending on the app you choose - so that is not going to help

    if you want to test your app, then cant you just script it to get a
    timestamp, send a file & repeat?
    >
    > The tool doesn't necessarily have to be free, but I don't have a huge
    > budget for this either.
    >
    > Thank You,
    >
    > Brian Wilcox

    --
    Regards

    stephen_hope@xyzworld.com - replace xyz with ntl



  11. Re: Testing UDP File Transfer Performance Over WAN

    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:

    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

  12. Re: Testing UDP File Transfer Performance Over WAN

    In article ,
    Rick Jones wrote:

    >> > Sigh, my goal of replacing ttcp remains unmet

    >> Netcat?

    >
    >OK, that tells me that netperf will never replace ttcp since netperf
    >won't ever act like a pipe


    Have you forgotten or did you miss my whining that BRL would not
    accept some changes to ttcp.c for better benchmarking on the grounds
    that the primary purpose of the code was transferring files?
    --


    Vernon Schryver vjs@rhyolite.com

  13. Re: Testing UDP File Transfer Performance Over WAN

    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

    With this setup, (we did other more formal tests, but this one is most
    telling) I used a traffic generator to swamp the network in all classes
    of service. There was 9 Mb/s traffic generated in both directions for a
    2Mb line (actually one end had a 34Mb/s line, the other a 2Mb line).

    Then I started up various Citrix sessions. Citrix is very sensitive to
    latency and dropped packets. I could work just as well as if the line was
    empty. Obviously Citrix traffic was in a priority class, but that class
    was also swamped with test traffic.

    In other setups we tested with just the fair based queueing, no QoS.
    Without QoS the other traffic was noticable, Citrix was a bit slugish,
    but stuff remained very workable.

    Compare this to our old setup without fair based queueing and QoS, where
    the Citrix sessions would just die with this amount of traffic. Even one
    tcp-based download could completely kill all Citrix sessions.

    So maybe this is a better angle to attack the problem. Don't measure your
    transfers. Guarantee that your network can handle it without problems.

    HTH,
    M4

  14. Re: Testing UDP File Transfer Performance Over WAN

    Two possibilities:

    Possiblity A:

    UDT 4.x and it's recvfile.exe and sendfile.exe might be exactly what you
    looking for:

    It works as follows:

    1. On the sending computer run:

    sendfile.exe

    2. On the receiving computer run:

    recvfile.exe filename of sending computer>

    Here is an (local) example with two dos prompts:

    Step 1 Sender:

    Y:\C testen\udt4\app>sendfile
    server is ready at port: 9000
    speed = 160.373 (displays speed when it's done in kb/sec I think...)

    Step 2 Receiver:

    Y:\C testen\udt4\app>recvfile
    usage: recvfile server_ip server_port remote_filename local_filename

    Y:\C testen\udt4\app>recvfile 127.0.0.1 9000 video.wmv test.wmv

    Only thing you might need is a little tool which adds a date/time to the
    log.
    (Windows date/time command can be used for that)

    So the batchfile for the sender would look like:

    SendTest.bat:

    date /T >> log.txt
    time /T >> log.txt
    sendfile >> log.txt

    Log would look like:

    vr 01-02-2008
    09:40
    server is ready at port: 9000
    speed = 232.398


    It's a bit crude, but it should give you an idea...

    Fun thing is the sender works like a server, so the receivers can be
    anywhere and simply request a file from the sender.
    After the transfer is done the sender has to be restarted again

    Also keep in mind udt 4 does some kind of throttling and fairness and such
    to other protocols, so it might be more fair on the network then your
    mentioned app I don't know about that.

    udt 4 says it's tcp friendly, so it might not be a good tool to test with,
    but I don't know if zfp is tcp friendly... otherwise you might need a
    blasting tool like udp speed test or udp file transfer or some other tool
    which simply blasts the network at a certain rate

    udt 4 is fast though it will try to use as much bandwidth as possible.

    Possiblity B:

    I might add logging functionality to udp speed test 2 but then it would work
    as follows:

    The receiver speed get logged per second, and possibly a graphicaly display
    to display it.

    This is probably not what you want, because you wrote you wanted to test at
    certain times at certain days and such and not really continously... just
    now and then...

    For possiblity A:

    You can find the necessary files at:

    http://sourceforge.net/project/downl...2.zip&93154643

    Then the executables sendfile.exe and recvfile.exe are in the sub folder:

    udt4/app

    Give it a try !

    Bye,
    Skybuck



  15. Re: Testing UDP File Transfer Performance Over WAN

    Rick Jones writes:

    > Bruce Barnett wrote:
    >> On UNIX systems, I use the program ttcp.c - if you can compile it,
    >> you can try it. It has all the options needed to adjust any
    >> parameter. The downside is that it runs once. If you want to
    >> analyse performance, you need to script it into a series of tests.

    >
    > 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.

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


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


  16. Re: Testing UDP File Transfer Performance Over WAN

    vjs@calcite.rhyolite.com (Vernon Schryver) writes:

    > Have you forgotten or did you miss my whining that BRL would not
    > accept some changes to ttcp.c for better benchmarking on the grounds
    > that the primary purpose of the code was transferring files?


    I have my own modifications, as ttcp was lacking in other areas (IMHO).
    I added some RT scheduling options to my version, for instance.

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


  17. Re: Testing UDP File Transfer Performance Over WAN

    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.


    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


  18. Re: Testing UDP File Transfer Performance Over WAN

    Vernon Schryver wrote:
    > Have you forgotten or did you miss my whining that BRL would not
    > accept some changes to ttcp.c for better benchmarking on the grounds
    > that the primary purpose of the code was transferring files?


    Must have been a multi-bit error in my dimm memory

    rick jones
    --
    oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    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...

  19. Re: Testing UDP File Transfer Performance Over WAN

    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?

    > 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

    rick jones
    --
    oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    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...

  20. Re: Testing UDP File Transfer Performance Over WAN

    bdwilcox@hotmail.com wrote:
    > Is there any UDP based program that can give me this kind of
    > straightforward result?


    Well, it really depends on the way that MS stuff sends the data - do
    you have a packet trace of a transfer?

    > I started to poke around at a Windows version of
    > NetPerf, but it's a very intimidating program.


    Little old netperf?-) Intimidating? Nah, you should see netperf4

    If the MS stuff works like tftp, then you would use a UDP_RR test:

    netperf -H -t UDP_RR -- -r 512,16

    (I probably have the request/response numbers wrong and/or the sense
    flipped depending on which way you are simulating)

    if it is request/response with multiple requests in flight at one time
    you would either ./configure --enable-burst or edit the file in
    NetPerf to add a define for "WANT_FIRST_BURST" and recompile and then
    say:

    netperf -H -t UDP_RR -- -r 512,16 -b

    where extrareqs would be one less than the number of transactions the
    actual program has in flight at one time.

    If it just blasts data you could use:

    netperf -H -t UDP_STREAM -- -m

    but I would hope that the actual program is not as simplistic
    (braindead) as that.

    It all boils down to what sort of "flow control" the actual
    application will be using. UDP doesn't have any. Netperf is either
    by virtue of number of messages at one time (UDP_RR) or by send pacing
    (an optional compilation feature under WANT_INTERVALS). The other
    limitation in netperf is that it makes no attempt to recover from lost
    UDP datagrams. That can be a test-stopper for the UDP_RR test.

    rick jones
    --
    Wisdom Teeth are impacted, people are affected by the effects of events.
    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...

+ Reply to Thread
Page 1 of 2 1 2 LastLast