Site menu Master Dissertation

Master Dissertation

SCTP performance test - loopback interface

Scenario: SOLDIER computer using loopback connections

Throughput - variation of message size

Protocol10100100010000
Unix8900938707186022452172
UnixM498043640218084438726
TCP116441153206435221030614
TCPM180216030128220265872
SCTP138415842108626228040
SCTP, UDP style133415584109066228040
SCTP UDP style, v.213441316098902282236

Message size in bytes, throughput em kbps (1kbps = 1000 bits/s).

Raw TCP performance is (not surprisingly) a lot better than SCTP, because SCTP has a lot more overhead: message separation, CRC-32c checksum, memory copies for message processing, and two context switches per message.

But the difference between TCP and SCTP almost vanishes when we use TCPM and UnixM. Message separation has a surprisingly high cost.

UNIX sockets were included just for completeness. It is interesting to note that TCP is faster than UNIX sockets for small messages.

We made an informal test disabling CRC-32c checksum in SCTP (numbers not shown in this page). Althrough CRC-32c is generally pointed as culprit for SCTP lower performance, the CRC-32c suppression improves throughput only by 10-15%.

Latency - variation of message size

Protocol10100100010000
UnixM18,518,527,0104,0
TCPM26,528,534,0112,5
SCTP52,052,572,5265,5
SCTP, UDP style52,554,573,5267,0
SCTP, UDP style, v.252,055,575,0266,0

Message size in bytes, latency in µs

With most latencies serialized, SCTP had twice the latency of TCPM. The lksctp-tools library is not the culprit; the extra latency is caused by the kernel.

Using either TCP or UDP style API delivers the same SCTP performance.

Throughput and latency - variation of stream count

Messages of 100 bytes were used for these tests. The graphics show that throughput and latency are not affected by the number of streams of a SCTP association.