[netperf-talk] bidirectional transfer with SCTP_RR

[Rick Jones]

Frank Schuster wrote:
> Hello,
> 
> I have a question to the bidirectional transfer test with SCTP_RR and the
> burst (-b) option. I tried first the bidirectional test with TCP_RR from the
> manual page and it works succesful.
> The output is shown:
> netperf -t TCP_RR -H 192.168.1.101 -- -b 6 -r 32K -s 256K -S 256K
> TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.101 (192.168.1.101) port 0 AF_INET : first burst 6
> Local /Remote
> Socket Size   Request  Resp.   Elapsed  Trans.
> Send   Recv   Size     Size    Time     Rate         
> bytes  Bytes  bytes    bytes   secs.    per sec   
> 
> 225280 225280 32768    32768   10.00     345.59   
> 225280 225280
> 
> But then I thought I can do the same with SCTP_RR but netperf says: Invalid option "-b"
> netperf -t SCTP_RR -H 192.168.1.101 -- -b 6 -r 32K -s 256K -S 256K
> netperf: invalid option -- 'b'
> SCTP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.101 (192.168.1.101) port 0 AF_INET : first burst 0
> Local /Remote
> Socket Size   Request  Resp.   Elapsed  Trans.
> Send   Recv   Size     Size    Time     Rate         
> bytes  Bytes  bytes    bytes   secs.    per sec   
> 
> 225280 225280 32768    32768   10.00     125.50   
> 225280 225280
> 
> So I have to question about this.
> 1.) What really means the option -b in the test specific option?

In the case of SCTP_RR, it means nothing because burst mode was not implemented 
in the SCTP tests in src/nettest_sctp.c

> 2.) How can I do a SCTP bidirectional test?

In *theory* the "omni" tests will work with (basic) sctp, and they have burst 
mode support in them.  Given that I've only really beat on the omni tests with 
TCP and UDP there may be some bugs lurking in there.

Otherwise, if the omni+sctp combination is too troublesome, getting a 
bidirectional single-connection SCTP test would require someone porting the mods 
from TCP_RR to SCTP_RR.

I cannot recall if there is an SCTP_MAERTS test.  If there is, then running two 
netperfs, one SCTP_STREAM and one SCTP_MAERTS, following the ideas behind 
running aggregate tests.

Plan C (or would this be D?) would be to start netperf TCP_STREAM tests from 
either end, and determine the aggregate throughput via means outside of netperf.

happy benchmarking,

rick jones

> 
> Regards
> Frank
> ______________________________________________________
> GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://movieflat.web.de
> 
> _______________________________________________
> netperf-talk mailing list
> netperf-talk at netperf.org
> http://www.netperf.org/cgi-bin/mailman/listinfo/netperf-talk