Links

GitHub

Open HUB

Quick Links

Download

STREAMS

SIGTRAN

SS7

Hardware

SCTP

Related

Package

Papers

Manual

Manual Pages

References

Conformance

Performance

Design

Status

FAQ

Operating System

TLI

SOCKSYS

XTI

Sockets

LDL

strinet

STREAMS

Kernel

Performance

Applications

SS7 Stack

ISDN Stack

SIGTRAN Stack

VoIP Stack

MG Stack

SS7/ISDN Devices

IP Transport

Embedded Systems

Operating System

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

STREAMS INET Driver

Description: OpenSS7 Documentation Performance.

Test Results

I used to worry about the inet(4) driver, that does STREAMS over Sockets, would perform poorly compared to Sockets alone. After all, the Stream head was placed over a socket using a driver and data was copied 4 times (from user to message block, message block to socket buffer, socket buffer to message block, and message block to user).

I even went to the extent of writing a purely STREAMS-based UDP driver (udp2(4)) to test out comparisons with a direct approach versus the XTIoS (STREAMS over Sockets) approach taken by the inet(4) driver (primarily concerned about the ability to perform when processing RTP within a STREAMS stack in the kernel). I also was considering writing a purely STREAMS based TCP implementation, but did not want to go to the work without getting a handle on what performance gains could be achieved. Also, it would always be nice to settle the Sockets vs. STREAMS dispute visa vi performance. So, I modified the netperf package to handle both Sockets and STREAMS comparisons for UDP, TCP and SCTP and did a little performance tuning on the strinet and strsctp packages and performed the tests.

Now, I had performed some performance comparisons using the netperf package previously and had not seen any staggering differences between Sockets and STREAMS using the XTIoS approach. In fact, it was seen in early results that STREAMS performed at about 40% compared to Sockets (similar to the initial pipe performance tests).

So what happened? I found an error in the STREAMS flow control flag handling that caused service procedures to be scheduled on each message (largely defeating STREAMS flow control). streams-0.9.2.3 has this correction and that is the release that has been used for the current testing. To say the least, the current results show dramatic performance advantage using STREAMS instead of Sockets.

UDP

Performance testing of both the inet(4) STREAMS over Sockets approach to UDP and the udp2(4) purely STREAMS based approach to UDP providing improvements over Linux Sockets UDP using Linux Fast-STREAMS. udp2(4) exhibited 40% to 60% improvement over Sockets UDP over a wide range of message sizes. The inet(4) STREAMS over Sockets approach even outperformed Sockets alone on some tests.

For an overview of the results, see the UDP Performance Page.

TCP

Performance testing of both the inet(4) STREAMS over Sockets approach to TCP and the sctp(4) purely STREAMS based approach to SCTP providing improvements over Linux Sockets TCP using Linux Fast-STREAMS. sctp(4) exhibited 300% improvement over Sockets TCP over a wide range of message sizes. The inet(4) STREAMS over Sockets approach to TCP outperformed Sockets by a staggering 200% to 250% on UP machines.

For an overview of the results, see the TCP Performance Page.

SCTP

For an overview of the results, see the STREAMS SCTP Performance Page.

Last modified: Mon, 25 Jun 2007 12:25:10 GMT  
Copyright © 2014 OpenSS7 Corporation All Rights Reserved.