Chronological Thread 

< Chronological >      < Thread >

---

On 08 Sep 2014, at 22:51, Jerry Jerry
<jerry.jerry2008 AT gmail.com>
wrote:

> Hello everyone,
>
> I'm Jerry and I'm trying to evaluate the libsctp implementation. I did some
> simple tests on the latest version of sctplib (1.0.15) using the examples
> in /sctplib/programs/. The test program I used is testsctp.
Hi,

please note that the sctplib is not developed anymore. We do some bugfixes
from time to time.
Please also note that the implementation was not written for performance.
>
>
> Here are some of my tests, observations as well as questions:
>
> 1. First, I try to test the throughput between two Linux PCs equipped with
> 1Gbps NIC.
>
> On sender side (192.1.1.2), I used the following command:
> ./testsctp -i -l 8096 -T 200 192.1.1.3
>
> On receiver side (192.1.1.3):
> ./testsctp -i
>
> The 'out-of-box' performance, in terms of throughput and CPU utilization,
> are about 90Mbps, and 85%.
>
> To compare with TCP, I made a similar simple client/server programs,
> where I could get about 900Mbps throughput and 15% CPU utilization. This is
> beyond my expectation as I thought SCTP should at least match what TCP
> could achieve for a simple case like this, or at lease it shouldn't be far
> behind TCP.
If you compare kernel implementations you will figure out that SCTP normally
requires more CPU resources than
TCP does. Using ethernet cards supporting the CRC computation helps, but
things like TSO or so are not supported for SCTP.
>
> So, based on this simple test, it looks to me that there is much room for a
> program using sctplib to improve. I'm wondering if there is any 'hidden'
> parameters or ways to tune up the throughput using sctplib? Or any tricks I
> could apply, or anything I may have missed...
>
>
>
>
> 2. My second and third question are about a strange behavior found during
> my test.
>
> On sender side, if I specify the number of packets to be sent (instead of
> the time duration to send), the sender can only successfully sends out 1667
> messages if I specify a larger number.
>
> E.g., ./testsctp -i -l 8096 -n 10000 192.1.1.2
>
> Here, one bug in testsctp.c is that packetNumber is defined as unsigned
> short so I modified to unsigned long, otherwise, it won't take input of a
> large number to send.
>
> Later, I turned on verbose (actually very verbose), it surprised me that
> even I only specify to send 10 messages, the receiver will send back 103
> messages. The verbose information shows these 103 messages were sent out by
> receiver from queueStuatusChangeNotif(), where based on my understanding,
> it means these 103 messages are user messages but not control messages from
> the lib, but where did these messages come from a receiver?
>
> 3. I made further tests by modifying some constants used in testsctp.c:
> #define DEFAULT_LENGTH 8096
> #define DEFAULT_NUMBER_OF_MESSAGES 1024
> #define DEFAULT_PORT 5001
> #define MAXIMUM_NUMBER_OF_LOCAL_ADDRESSES 1
> #define MAXIMUM_NUMBER_OF_ASSOCIATIONS 1
> #define MAXIMUM_NUMBER_OF_IN_STREAMS 1
> #define MAXIMUM_NUMBER_OF_OUT_STREAMS 1
> #define MAXIMUM_PAYLOAD_LENGTH 8096
> #define SEND_QUEUE_SIZE 10000
> #define RECV_QUEUE_SIZE 10000
>
> Then, I sent 5 messages from the sender:
> ./testsctp -i -V -n 5 192.1.1.2
>
> This time, the receiver sends back 1667 messages of 8096 bytes. Again, I
> see this magic number of '1667', and this leads me to ask why is number,
> and why the receiver sends back 1667 messages back?
No idea. I haven't used testsctp. If I remember it correctly, it was
contribution of someone...
>
>
>
> Your help on these questions would be greatly appreciated very much!
You might want to look at usrsctp, an port of the FreeBSD kernel stack to
userland.

Best regards
Michael
>
> Sincerely,
> Jerry
> _______________________________________________
> sctp-discussion mailing list
> sctp-discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/sctp-discussion

---

• [SCTP-Discussion] Questions on SCTP performance and a strange behavior, Jerry Jerry, 09/08/2014
  • Re: [SCTP-Discussion] Questions on SCTP performance and a strange behavior, Michael Tuexen, 09/09/2014

---

Archive powered by MHonArc 2.6.19+.