Martin,
> It might also be an idea to measure using different values of burst size.
> I personally find the Juniper manuals to be somewhat lacking here...
You may want to try a perf testing application which is less bursty. iperf UDP
traffic is very bursty -- it does not go out of its way to evenly space
packets. You can easily see this by capturing the perf traffic, then
processing it with something like tcpdump -ttt -r file.pcap | awk '{print $1}'
| sed -e 's/00:00:00.//' | sort -n | uniq -c > deltas. In the 'deltas'
histogram that results you should see the overwhelming majority of the packets
in your flow are spaced extremely close together (e.g., near the 0 end).
Your interface speed appears to be GigE, so you are bursting out at line rate
and relying on the buffers in the router to accommodate these line-rate bursts.
You should have different results if you connected the host at FastE vs GigE.
nuttcp is a perf testing tool which, by default, is much less bursty -- you can
control whether it bursts or not. Go to www.nuttcp.org or grab the latest rev
from http://lcp.nrl.navy.mil/nuttcp/beta/nuttcp-7.1.3.c.
Use the -Ri10M option for a non-bursty 10Mbps flow. You can add /# to make it
burst # number of packets. (This can be useful for seeing how "much" bursty
traffic a device can take before it exhausts its buffers when there is a speed
transition, for example..)
-Ri#[/#] instantaneous rate limit with optional packet burst
If you look closely at the CPU usage of iperf vs nuttcp, you will find nuttcp
(unlike iperf) consumes 100% of the sender's CPU when running in UDP mode
because it puts itself into a very tight loop to get the most precise timing.
-Chris
--
Chris Tracy <[email protected]>
Energy Sciences Network (ESnet)
Lawrence Berkeley National Laboratory
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
