Master Dissertation
Master Dissertation
Scenario: SOLDIER computer using loopback connections
| Protocol | 10 | 100 | 1000 | 10000 |
|---|---|---|---|---|
| Unix | 8900 | 93870 | 718602 | 2452172 |
| UnixM | 4980 | 43640 | 218084 | 438726 |
| TCP | 11644 | 115320 | 643522 | 1030614 |
| TCPM | 1802 | 16030 | 128220 | 265872 |
| SCTP | 1384 | 15842 | 108626 | 228040 |
| SCTP, UDP style | 1334 | 15584 | 109066 | 228040 |
| SCTP UDP style, v.2 | 1344 | 13160 | 98902 | 282236 |
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%.
| Protocol | 10 | 100 | 1000 | 10000 |
|---|---|---|---|---|
| UnixM | 18,5 | 18,5 | 27,0 | 104,0 |
| TCPM | 26,5 | 28,5 | 34,0 | 112,5 |
| SCTP | 52,0 | 52,5 | 72,5 | 265,5 |
| SCTP, UDP style | 52,5 | 54,5 | 73,5 | 267,0 |
| SCTP, UDP style, v.2 | 52,0 | 55,5 | 75,0 | 266,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.
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.