iperf

iperf

[@ 2007-07-17 19:13 UTC (permalink / raw)]

Hi,

   I'm using iperf to make some DCCP tests and I'd like to know if it
is possible to make iperf client (with -c option) transmit packets
during certain duration and measure the throughput each x seconds.
I've used -t 3 (for instance) option, but iperf just connect, send
packets, show the results and finish its job. I'd like to continuous
take instant throughput for each x seconds, how to do this?

[]s
Leandro.

Re: iperf

[Ian McDonald]

On 7/18/07, ツ Leandro Sales <leandroal@gmail.com> wrote:
> Hi,
>
>    I'm using iperf to make some DCCP tests and I'd like to know if it
> is possible to make iperf client (with -c option) transmit packets
> during certain duration and measure the throughput each x seconds.
> I've used -t 3 (for instance) option, but iperf just connect, send
> packets, show the results and finish its job. I'd like to continuous
> take instant throughput for each x seconds, how to do this?
>
> []s
> Leandro.

From iperf --help
  -i, --interval  #        seconds between periodic bandwidth reports

I use this quite a bit and works perfectly. I've also modified iperf
to run continuously if you need that capability - available from my
web page.

Ian
-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: iperf

[Patrick]

Hi,

Quick question on iperf and kernel 2.6.22 (official and exp DCCP tree).
I use 2 computers + 1 netembox in between
Here are iperf cmd lines I use :
on dccpServer : # iperf -s -Xdccp -l1424
on dccpClient : # iperf -c dccpServer -Xdccp -l1424 -t30

On 2.6.22 kernel:
Without netem rate control, iperf result is about 95.0 Mbits/sec
With netem rate control at 1024Kbits/sec, iperf result could be
10Kbits/sec or 30Kbits/sec...

On 2.6.20 with Ian's patches:
Without netem rate control, iperf result is about 95.0 Mbits/sec
With netem rate control at 1024Kbits/sec, iperf result is about 950Kbits/sec.

netem cmd lines: (I also tried with delay and loss turned on)
tc qdisc add dev eth0 root handle 1:0 tbf rate 1024kbit buffer 10000 limit 30000
tc qdisc add dev eth1 root handle 1:0 tbf rate 1024kbit buffer 10000 limit 30000

Is anyone has a such low rate on 2.6.22 kernel? do you know why?

regards,
Patrick.


On 17/07/07, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
> On 7/18/07, ツ Leandro Sales <leandroal@gmail.com> wrote:
> > Hi,
> >
> >    I'm using iperf to make some DCCP tests and I'd like to know if it
> > is possible to make iperf client (with -c option) transmit packets
> > during certain duration and measure the throughput each x seconds.
> > I've used -t 3 (for instance) option, but iperf just connect, send
> > packets, show the results and finish its job. I'd like to continuous
> > take instant throughput for each x seconds, how to do this?
> >
> > []s
> > Leandro.
>
> From iperf --help
>   -i, --interval  #        seconds between periodic bandwidth reports
>
> I use this quite a bit and works perfectly. I've also modified iperf
> to run continuously if you need that capability - available from my
> web page.
>
> Ian
> --
> Web: http://wand.net.nz/~iam4/
> Blog: http://iansblog.jandi.co.nz
> WAND Network Research Group
> -
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: iperf

[Gerrit Renker]

Quoting Patrick:
|  Hi,
|  
|  Quick question on iperf and kernel 2.6.22 (official and exp DCCP tree).
|  I use 2 computers + 1 netembox in between
|  Here are iperf cmd lines I use :
|  on dccpServer : # iperf -s -Xdccp -l1424
|  on dccpClient : # iperf -c dccpServer -Xdccp -l1424 -t30

This iperf variant only sends at full/maximum speed, i.e. it will try aggressively
to stuff your link, until it is forced to slow down by the kernel. This generates
a lot of other problems - such as increase in delay, queue overflow etc.

I haven't done bandwidth tests during the last days, but if you are doing such tests
can you please compare with the constant-bitrate variant of iperf:

 * use original source 
   http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/zip/iperf-2.0.2.tar.gz
 * only needs patch #1 from
   http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/patches/
 
 * then try iteratively with the -b switch to increase the bandwidth, i.e.
    iperf -c dccpServer -l1424  -d -b1m		# 1Mbps CBR DCCP
    iperf -c dccpServer -l1424  -d -b5m         # 5Mbps
    iperf -c dccpServer -l1424  -d -b10m        # 10Mbps
  
Do you get a higher speed this way? If yes, then the low speeds are likely due to
queue overflow, otherwise there is another reason. There have been a lot of changes
in the netdev kernel, the test tree has not been changed.

|  
|  On 2.6.22 kernel:
|  Without netem rate control, iperf result is about 95.0 Mbits/sec
|  With netem rate control at 1024Kbits/sec, iperf result could be
|  10Kbits/sec or 30Kbits/sec...
|  
|  On 2.6.20 with Ian's patches:
|  Without netem rate control, iperf result is about 95.0 Mbits/sec
|  With netem rate control at 1024Kbits/sec, iperf result is about 950Kbits/sec.
|  
|  netem cmd lines: (I also tried with delay and loss turned on)
|  tc qdisc add dev eth0 root handle 1:0 tbf rate 1024kbit buffer 10000 limit 30000
|  tc qdisc add dev eth1 root handle 1:0 tbf rate 1024kbit buffer 10000 limit 30000
|  
|  Is anyone has a such low rate on 2.6.22 kernel? do you know why?
|  
|  regards,
|  Patrick.
|  
|  
|  On 17/07/07, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
|  > On 7/18/07, ツ Leandro Sales <leandroal@gmail.com> wrote:
|  > > Hi,
|  > >
|  > >    I'm using iperf to make some DCCP tests and I'd like to know if it
|  > > is possible to make iperf client (with -c option) transmit packets
|  > > during certain duration and measure the throughput each x seconds.
|  > > I've used -t 3 (for instance) option, but iperf just connect, send
|  > > packets, show the results and finish its job. I'd like to continuous
|  > > take instant throughput for each x seconds, how to do this?
|  > >
|  > > []s
|  > > Leandro.
|  >
|  > From iperf --help
|  >   -i, --interval  #        seconds between periodic bandwidth reports
|  >
|  > I use this quite a bit and works perfectly. I've also modified iperf
|  > to run continuously if you need that capability - available from my
|  > web page.
|  >
|  > Ian
|  > --
|  > Web: http://wand.net.nz/~iam4/
|  > Blog: http://iansblog.jandi.co.nz
|  > WAND Network Research Group
|  > -
|  > To unsubscribe from this list: send the line "unsubscribe dccp" in
|  > the body of a message to majordomo@vger.kernel.org
|  > More majordomo info at  http://vger.kernel.org/majordomo-info.html
|  >
|  -
|  To unsubscribe from this list: send the line "unsubscribe dccp" in
|  the body of a message to majordomo@vger.kernel.org
|  More majordomo info at  http://vger.kernel.org/majordomo-info.html
|  
|  

Re: iperf

[Burak Gorkemli]

Hi Patrick,

I had the same results with you, and I was planning to report them as soon as I found some time.

I have used Gerrit's tree, same configuration with you, and ended-up with the same results. I am currently using 2.6.20 with Ian's patches, and it performs well, as you have reported.

Best,
Burak

----- Original Message ----
From: Patrick <patrick.andrieux@gmail.com>
To: Leandro Sales <leandroal@gmail.com>; DCCP Mailing List <dccp@vger.kernel.org>
Sent: Thursday, July 19, 2007 3:42:13 PM
Subject: Re: iperf

Hi,

Quick question on iperf and kernel 2.6.22 (official and exp DCCP tree).
I use 2 computers + 1 netembox in between
Here are iperf cmd lines I use :
on dccpServer : # iperf -s -Xdccp -l1424
on dccpClient : # iperf -c dccpServer -Xdccp -l1424 -t30

On 2.6.22 kernel:
Without netem rate control, iperf result is about 95.0 Mbits/sec
With netem rate control at 1024Kbits/sec, iperf result could be
10Kbits/sec or 30Kbits/sec...

On 2.6.20 with Ian's patches:
Without netem rate control, iperf result is about 95.0 Mbits/sec
With netem rate control at 1024Kbits/sec, iperf result is about 950Kbits/sec.

netem cmd lines: (I also tried with delay and loss turned on)
tc qdisc add dev eth0 root handle 1:0 tbf rate 1024kbit buffer 10000 limit 30000
tc qdisc add dev eth1 root handle 1:0 tbf rate 1024kbit buffer 10000 limit 30000

Is anyone has a such low rate on 2.6.22 kernel? do you know why?

regards,
Patrick.


On 17/07/07, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
> On 7/18/07, ツ Leandro Sales <leandroal@gmail.com> wrote:
> > Hi,
> >
> >    I'm using iperf to make some DCCP tests and I'd like to know if it
> > is possible to make iperf client (with -c option) transmit packets
> > during certain duration and measure the throughput each x seconds.
> > I've used -t 3 (for instance) option, but iperf just connect, send
> > packets, show the results and finish its job. I'd like to continuous
> > take instant throughput for each x seconds, how to do this?
> >
> > []s
> > Leandro.
>
> From iperf --help
>   -i, --interval  #        seconds between periodic bandwidth reports
>
> I use this quite a bit and works perfectly. I've also modified iperf
> to run continuously if you need that capability - available from my
> web page.
>
> Ian
> --
> Web: http://wand.net.nz/~iam4/
> Blog: http://iansblog.jandi.co.nz
> WAND Network Research Group
> -
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iperf

[Patrick]

Applying only patch #1 doesn't work... patch #2 correct the error.
PerfSocket.cpp: In function 'void MakeSocket(thread_Settings*)':
PerfSocket.cpp:89: error: 'IPPROTO_UDPLITE' was not declared in this scope
make[2]: *** [PerfSocket.o] Error 1
make[2]: Leaving directory `/root/iperf-2.0.2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/iperf-2.0.2'
make: *** [all] Error 2

It could be good to not have 2 iperf dccp patched version, one Ian
patched, one Gerrit patched ?

This way gives me the same results.
Without control rate, it works at the maximun rate (1Mbps, 5Mbps, or 10Mbps).
Using netem as middle box limiting at 1024 Kbits/sec, iperf result is
still not what I expected... it goes from 15 Kbits/sec to 60Kbits/sec.

Patrick.


On 19/07/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> Quoting Patrick:
> |  Hi,
> |
> |  Quick question on iperf and kernel 2.6.22 (official and exp DCCP tree).
> |  I use 2 computers + 1 netembox in between
> |  Here are iperf cmd lines I use :
> |  on dccpServer : # iperf -s -Xdccp -l1424
> |  on dccpClient : # iperf -c dccpServer -Xdccp -l1424 -t30
>
> This iperf variant only sends at full/maximum speed, i.e. it will try aggressively
> to stuff your link, until it is forced to slow down by the kernel. This generates
> a lot of other problems - such as increase in delay, queue overflow etc.
>
> I haven't done bandwidth tests during the last days, but if you are doing such tests
> can you please compare with the constant-bitrate variant of iperf:
>
>  * use original source
>    http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/zip/iperf-2.0.2.tar.gz
>  * only needs patch #1 from
>    http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/patches/
>
>  * then try iteratively with the -b switch to increase the bandwidth, i.e.
>     iperf -c dccpServer -l1424  -d -b1m         # 1Mbps CBR DCCP
>     iperf -c dccpServer -l1424  -d -b5m         # 5Mbps
>     iperf -c dccpServer -l1424  -d -b10m        # 10Mbps
>
> Do you get a higher speed this way? If yes, then the low speeds are likely due to
> queue overflow, otherwise there is another reason. There have been a lot of changes
> in the netdev kernel, the test tree has not been changed.
>
> |
> |  On 2.6.22 kernel:
> |  Without netem rate control, iperf result is about 95.0 Mbits/sec
> |  With netem rate control at 1024Kbits/sec, iperf result could be
> |  10Kbits/sec or 30Kbits/sec...
> |
> |  On 2.6.20 with Ian's patches:
> |  Without netem rate control, iperf result is about 95.0 Mbits/sec
> |  With netem rate control at 1024Kbits/sec, iperf result is about 950Kbits/sec.
> |
> |  netem cmd lines: (I also tried with delay and loss turned on)
> |  tc qdisc add dev eth0 root handle 1:0 tbf rate 1024kbit buffer 10000 limit 30000
> |  tc qdisc add dev eth1 root handle 1:0 tbf rate 1024kbit buffer 10000 limit 30000
> |
> |  Is anyone has a such low rate on 2.6.22 kernel? do you know why?
> |
> |  regards,
> |  Patrick.
> |
> |
> |  On 17/07/07, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
> |  > On 7/18/07, ツ Leandro Sales <leandroal@gmail.com> wrote:
> |  > > Hi,
> |  > >
> |  > >    I'm using iperf to make some DCCP tests and I'd like to know if it
> |  > > is possible to make iperf client (with -c option) transmit packets
> |  > > during certain duration and measure the throughput each x seconds.
> |  > > I've used -t 3 (for instance) option, but iperf just connect, send
> |  > > packets, show the results and finish its job. I'd like to continuous
> |  > > take instant throughput for each x seconds, how to do this?
> |  > >
> |  > > []s
> |  > > Leandro.
> |  >
> |  > From iperf --help
> |  >   -i, --interval  #        seconds between periodic bandwidth reports
> |  >
> |  > I use this quite a bit and works perfectly. I've also modified iperf
> |  > to run continuously if you need that capability - available from my
> |  > web page.
> |  >
> |  > Ian
> |  > --
> |  > Web: http://wand.net.nz/~iam4/
> |  > Blog: http://iansblog.jandi.co.nz
> |  > WAND Network Research Group
> |  > -
> |  > To unsubscribe from this list: send the line "unsubscribe dccp" in
> |  > the body of a message to majordomo@vger.kernel.org
> |  > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> |  >
> |  -
> |  To unsubscribe from this list: send the line "unsubscribe dccp" in
> |  the body of a message to majordomo@vger.kernel.org
> |  More majordomo info at  http://vger.kernel.org/majordomo-info.html
> |
> |
>


-- 
-------
Patrick ANDRIEUX
email : patrick.andrieux@gmail.com

Re: iperf

[Ian McDonald]

On 7/20/07, Patrick <patrick.andrieux@gmail.com> wrote:
> Applying only patch #1 doesn't work... patch #2 correct the error.
> PerfSocket.cpp: In function 'void MakeSocket(thread_Settings*)':
> PerfSocket.cpp:89: error: 'IPPROTO_UDPLITE' was not declared in this scope
> make[2]: *** [PerfSocket.o] Error 1
> make[2]: Leaving directory `/root/iperf-2.0.2/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/root/iperf-2.0.2'
> make: *** [all] Error 2
>
> It could be good to not have 2 iperf dccp patched version, one Ian
> patched, one Gerrit patched ?
>
I agree. I think only thing missing from Gerrit's is my continuous
patch which should apply on top of his I'm guessing.

I might just go do some iperf hacking now and see what I can find...

Ian
-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: iperf

[Ian McDonald]

On 7/20/07, Patrick <patrick.andrieux@gmail.com> wrote:
> Hi,
>
> Quick question on iperf and kernel 2.6.22 (official and exp DCCP tree).
> I use 2 computers + 1 netembox in between
> Here are iperf cmd lines I use :
> on dccpServer : # iperf -s -Xdccp -l1424
> on dccpClient : # iperf -c dccpServer -Xdccp -l1424 -t30
>
> On 2.6.22 kernel:
> Without netem rate control, iperf result is about 95.0 Mbits/sec
> With netem rate control at 1024Kbits/sec, iperf result could be
> 10Kbits/sec or 30Kbits/sec...
>
> On 2.6.20 with Ian's patches:
> Without netem rate control, iperf result is about 95.0 Mbits/sec
> With netem rate control at 1024Kbits/sec, iperf result is about 950Kbits/sec.
>
> netem cmd lines: (I also tried with delay and loss turned on)
> tc qdisc add dev eth0 root handle 1:0 tbf rate 1024kbit buffer 10000 limit 30000
> tc qdisc add dev eth1 root handle 1:0 tbf rate 1024kbit buffer 10000 limit 30000
>
> Is anyone has a such low rate on 2.6.22 kernel? do you know why?
>
> regards,
> Patrick.
>

Question - what do you get on an unpatched 2.6.20 kernel? I think this
is my patches making it work well but want to verify that it's not
just something breaking between 2.6.20 and 2.6.22.

I'll try and replicate this later.

Ian
-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: iperf

[Ian McDonald]

On 7/20/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> Quoting Patrick:
> |  Hi,
> |
> |  Quick question on iperf and kernel 2.6.22 (official and exp DCCP tree).
> |  I use 2 computers + 1 netembox in between
> |  Here are iperf cmd lines I use :
> |  on dccpServer : # iperf -s -Xdccp -l1424
> |  on dccpClient : # iperf -c dccpServer -Xdccp -l1424 -t30
>
> This iperf variant only sends at full/maximum speed, i.e. it will try aggressively
> to stuff your link, until it is forced to slow down by the kernel. This generates
> a lot of other problems - such as increase in delay, queue overflow etc.
>
I still think that DCCP CCID3 should respond gracefully in this
circumstance, not collapse. We have congestion control and we
shouldn't go down to virtually nothing. TCP works fine, older versions
of DCCP work fine. I've got to research what is going on for sure
though. Might be time to use dccp_probe as well and work out what's
going on?

Are others aware of dccp_probe? - this is quite useful for looking at
problems like this.

> I haven't done bandwidth tests during the last days, but if you are doing such tests
> can you please compare with the constant-bitrate variant of iperf:
>
>  * use original source
>    http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/zip/iperf-2.0.2.tar.gz
>  * only needs patch #1 from
>    http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/patches/
>
>  * then try iteratively with the -b switch to increase the bandwidth, i.e.
>     iperf -c dccpServer -l1424  -d -b1m         # 1Mbps CBR DCCP
>     iperf -c dccpServer -l1424  -d -b5m         # 5Mbps
>     iperf -c dccpServer -l1424  -d -b10m        # 10Mbps
>

I will try these out - going to play with iperf for a bit now...

Ian
-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: iperf

[Ian McDonald]

On 7/20/07, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
> I agree. I think only thing missing from Gerrit's is my continuous
> patch which should apply on top of his I'm guessing.
>
> I might just go do some iperf hacking now and see what I can find...
>
> Ian

OK. I've hacked my iperf version around a bit to get closer to Gerrit's.

What I've done:
- ported more of his code over
-- renaming/shifting code
-- fix service code handling to allow network byte order and correct name
-- merged using -b option for DCCP (NB gives an error at end but seems
to be working OK)

Our code still differs a bit e.g. I don't support UDP Lite yet.

So if you want unlimited run time and -b together then you want my
tree, otherwise Gerrit's is probably better. I'm sure Gerrit can port
my unlimited run time easily to his tree if he wants.

My patches are at:
http://wand.net.nz/~iam4/iperf/

Ian
-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: iperf

[Gerrit Renker]

|  OK. I've hacked my iperf version around a bit to get closer to Gerrit's.
|  
|  What I've done:
|  - ported more of his code over
|  -- renaming/shifting code
|  -- fix service code handling to allow network byte order and correct name
|  -- merged using -b option for DCCP (NB gives an error at end but seems
|  to be working OK)
This is an error - you need to support the -b option on the server as well. The
reason is that iperf, like ttcp, uses a kind of handshake to terminate datagram 
test runs. You didn't describe the error - was it something like `did not receive the
last ack after 10 tries'? If yes then the code needs to support -b on the server
as well. The bandwidth measurements are otherwise not accurate.

|  
|  Our code still differs a bit e.g. I don't support UDP Lite yet.
Are these the only differences? If yes then I am all for combining one patch 
and uploading it to the description of regression testing.

Over the time I have using -b (even if it does not solve the present problem
with bandwidth) a very useful diagnosis tool, iperf at full speed generates
a lot of noise.

Re: iperf

[Gerrit Renker]

Thank you for testing this - the patch had been all in one and apparently 
I have made a bad job of splitting it up into separate patches. 

The error is due to a missing header include (I ported UDP-Lite in 2.6.20
but system headers are not that recent), will fix that and upload a clean
patch set.
|  Applying only patch #1 doesn't work... patch #2 correct the error.
|  PerfSocket.cpp: In function 'void MakeSocket(thread_Settings*)':
|  PerfSocket.cpp:89: error: 'IPPROTO_UDPLITE' was not declared in this scope
|  make[2]: *** [PerfSocket.o] Error 1
|  make[2]: Leaving directory `/root/iperf-2.0.2/src'
|  make[1]: *** [all-recursive] Error 1
|  make[1]: Leaving directory `/root/iperf-2.0.2'
|  make: *** [all] Error 2
|  
|  It could be good to not have 2 iperf dccp patched version, one Ian
|  patched, one Gerrit patched ?
Agree, will look at Ian's patches when I have some time and confer with Ian.

Thanks again.

Re: iperf

[Gerrit Renker]

Thanks everyone for sending test reports.

|  Question - what do you get on an unpatched 2.6.20 kernel? I think this
|  is my patches making it work well but want to verify that it's not
|  just something breaking between 2.6.20 and 2.6.22.
Fully agree here: I am not sure that these problems are necessarily due to a DCCP 
problem and actually would like to put the following question to the list - 
   - to what extent should the DCCP test tree track 
     the latest developments on the netdev tree?

My understanding that it is a good thing to track netdev, but it will make debugging
a bit more laborious. It is an acknowledged issue that there are still many bugs 
outstanding in 2.6.21/22, and I have been experiencing many crashes during the last
month which vanished mysteriously a couple of days/revisions later.

You can help us and hopefully other developers by supplying as much information as
you can get:
 * use constant bitrate and full byte-blast of iperf
 * use dccp_probe (as suggested by Ian, CBR produces much less noise in the output)
 * use different hardware (Wifi, 10mpbs, 100mbps, bluetooth, other arches)

I will also try and replicate this. Please provide as detailed information as you can.

Re: iperf

[Gerrit Renker]

Ian,

I also cleaned up my patch set to
 * completely remove UDP-Lite from all other patches
 * shift UDP-Lite to the end (as fourth patch)
 * I have shamelessly stolen your `continuous' patch and integrated as patch #3
 * result (patches 1..3) compiles without error or problems on a brandnew 
   installation of linux (with unmodified kernel headers)
 * I haven't had time to look through your code, but I think we should put
   out one combined client for testing purposes.

I am not fussy who's it is we are using - the code is after all yours. I just
polished it a bit up and made sure that the -b switch also works for DCCP.

And I have found it quite a useful switch for testing, indeed.

Results are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/patches/
       (src:   http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/zip/ )
Gerrit

Quoting Ian McDonald:
|  OK. I've hacked my iperf version around a bit to get closer to Gerrit's.
|  
|  What I've done:
|  - ported more of his code over
|  -- renaming/shifting code
|  -- fix service code handling to allow network byte order and correct name
|  -- merged using -b option for DCCP (NB gives an error at end but seems
|  to be working OK)
|  
|  Our code still differs a bit e.g. I don't support UDP Lite yet.
|  
|  So if you want unlimited run time and -b together then you want my
|  tree, otherwise Gerrit's is probably better. I'm sure Gerrit can port
|  my unlimited run time easily to his tree if he wants.
|  
|  My patches are at:
|  http://wand.net.nz/~iam4/iperf/
|  
|  Ian

Re: iperf

[Ian McDonald]

Hi there Gerrit,

I agree it's best to have one code base and yours looks great now.
There's no need for anyone to use mine now really.

A lot of it isn't actually mine and was originally contributed by
others - I just picked it up and ran with it.

The only comment on your version is that you remove WIN32 code, and
rename some existing options. I had a hope that the code could get
merged upstream but my emails to the iperf list haven't succeeded in
this (probably because the CAIDA project has no funding).

Ian

On 7/21/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> Ian,
>
> I also cleaned up my patch set to
>  * completely remove UDP-Lite from all other patches
>  * shift UDP-Lite to the end (as fourth patch)
>  * I have shamelessly stolen your `continuous' patch and integrated as patch #3
>  * result (patches 1..3) compiles without error or problems on a brandnew
>    installation of linux (with unmodified kernel headers)
>  * I haven't had time to look through your code, but I think we should put
>    out one combined client for testing purposes.
>
> I am not fussy who's it is we are using - the code is after all yours. I just
> polished it a bit up and made sure that the -b switch also works for DCCP.
>
> And I have found it quite a useful switch for testing, indeed.
>
> Results are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/patches/
>        (src:   http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/zip/ )
> Gerrit
>
> Quoting Ian McDonald:
> |  OK. I've hacked my iperf version around a bit to get closer to Gerrit's.
> |
> |  What I've done:
> |  - ported more of his code over
> |  -- renaming/shifting code
> |  -- fix service code handling to allow network byte order and correct name
> |  -- merged using -b option for DCCP (NB gives an error at end but seems
> |  to be working OK)
> |
> |  Our code still differs a bit e.g. I don't support UDP Lite yet.
> |
> |  So if you want unlimited run time and -b together then you want my
> |  tree, otherwise Gerrit's is probably better. I'm sure Gerrit can port
> |  my unlimited run time easily to his tree if he wants.
> |
> |  My patches are at:
> |  http://wand.net.nz/~iam4/iperf/
> |
> |  Ian
>


-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: iperf

[Ian McDonald]

On 7/21/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> My understanding that it is a good thing to track netdev, but it will make debugging
> a bit more laborious. It is an acknowledged issue that there are still many bugs
> outstanding in 2.6.21/22, and I have been experiencing many crashes during the last
> month which vanished mysteriously a couple of days/revisions later.
>
I would suggest tracking from about rc3 or rc4 on each release and
then that way you have a slightly more stable kernel and things are
ready for merge at the next window if we are ready and Arnaldo is
ready.

-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: iperf

[Ian McDonald]

On 7/21/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> |  OK. I've hacked my iperf version around a bit to get closer to Gerrit's.
> |
> |  What I've done:
> |  - ported more of his code over
> |  -- renaming/shifting code
> |  -- fix service code handling to allow network byte order and correct name
> |  -- merged using -b option for DCCP (NB gives an error at end but seems
> |  to be working OK)
> This is an error - you need to support the -b option on the server as well. The
> reason is that iperf, like ttcp, uses a kind of handshake to terminate datagram
> test runs. You didn't describe the error - was it something like `did not receive the
> last ack after 10 tries'? If yes then the code needs to support -b on the server
> as well. The bandwidth measurements are otherwise not accurate.

Yes it was. That makes sense now.
>
> |
> |  Our code still differs a bit e.g. I don't support UDP Lite yet.
> Are these the only differences? If yes then I am all for combining one patch
> and uploading it to the description of regression testing.
>
Yes it was, apart from I hadn't picked up all your tidyups.

-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: iperf

[Gerrit Renker]

Thanks - what I did is put the whole thing into a useable format. 

There is now a combined iperf source tarball which has 
     (1) DCCP support, 
     (2) -b switch for CBR mode, 
     (3) TCP pluggable congestion control, and 
     (4) continuous test runs 

all integrated. With the exception of (2), most of these are from your 
patches. The combined tarball comes via

wget http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/iperf/zip/iperf-2.0.2_DCCP-patched-CBR-continuous.tar.bz2

I have added description on the CBR mode on the DCCP testing pages on

 http://linux-net.osdl.org/index.php/DCCP_Testing#Testing_with_constant_bitrate


The UDP-Lite variant of iperf has been banned into the UDP-Lite tarball.

|  The only comment on your version is that you remove WIN32 code, and
|  rename some existing options. I had a hope that the code could get
|  merged upstream but my emails to the iperf list haven't succeeded in
|  this (probably because the CAIDA project has no funding).
I fully agree with your comment, but there were reasons - I figured that it will
take a long time until Windows supports both DCCP, plug-able TCP congestion control,
and UDP-Lite; and I found that the code (if it is going to be used under Lunix only)
is much more readable. I can separate out the windows changes into a standalone 
patch, but for the moment I'd much rather put in effort into the test tree.

There is only one flag change:
 * -d  /  --dualtest   becomes `-2' / `--dualtest'
 * -d  /  --dccp       becomes the new switch for DCCP

The other additions were
 * -A <algo>  chooses TCP congestion control algorithm
 * -b now works for UDP and DCCP in the same manner

 
Gerrit