I still use tcptrace and xplot.org for deep dives.
I just fired off 2048 netperfs to localhost on my laptop. It started
bogging down at 1000 but made it to the end, all connections chugging away.
Probably a better tool would be the apache benchmark `ab` or something else
that is built to stress
On Tue, 14 May 2013 15:48:38 +0200
Jesper Dangaard Brouer jbro...@redhat.com wrote:
(I'm testing fq_codel and codel)
I need a test tool that can start many TCP streams (1024).
During/after the testrun I want to know if the connections got a fair
share of the bandwidth.
Can anyone
On May 14, 2013 12:21 PM, Stephen Hemminger step...@networkplumber.org
wrote:
On Tue, 14 May 2013 15:48:38 +0200
Jesper Dangaard Brouer jbro...@redhat.com wrote:
(I'm testing fq_codel and codel)
I need a test tool that can start many TCP streams (1024).
During/after the testrun I
There are really three kinds of killer traffic here, and it's important to
understand the differences so as to best design testing:
1) long lived flows that clobber you and ruin your whole day.
2) streaming video traffic (e.g. netflix, youtube, hulu), that are
actually chunking data over
On Tue, 14 May 2013 08:47:26 -0700
Stephen Hemminger step...@networkplumber.org wrote:
You may want to look at some of the realistic load tools since
in real life not all flows are 100% of bandwidth and long lived.
Well perhaps it would be easier to use some apache load test tool, but
in this
On Tue, 14 May 2013 07:46:02 -0700
Dave Taht dave.t...@gmail.com wrote:
I still use tcptrace and xplot.org for deep dives.
Okay, I just hoped something new popped up.
Didn't we add some tcp trace system to the kernel?
I just fired off 2048 netperfs to localhost on my laptop. It started
It will not match what one can get from tcptrace, or commercial
solutions, but netperf can be asked to emit a number of potentially
intersting things. Using the omni output selectors one can request
statistics for some interesting latencies:
raj@tardy:~$ netperf -- -O ? | grep LAT
RT_LATENCY
