Ericsson

Ericsson AB    
Home
 
· Home
· Product Info
· Licensing
· Consulting
· Training
· Documentation
· Publications
· Contact Info
· Licensees Area

· User Conferences
· Workshops
· Open Source

For comments or questions about this site, contact us.
     

Erlang/OTP R7 - speed test of new inet driver


Measurements

A sequence of messages of the same size is sent on a socket, and the time is measured for the whole sequence. Then the size of the message is doubled and the number of messages in the sequence is halfed, to keep the total amount of data fairly constant (approx. 4 MByte). And so on...

The messages contain all bytes of equal value, and no checking of the contents at the time of reception is done, as this would create a lot of overhead. The messages are received in passive mode.

The measurements has been done on two Sun Ultra 10 running Solaris 7, iluvatar (local) and gorbag (remote), connected with a 10 Mbit/s Ethernet. The Erlang/OTP releases were R6B-patched and R7A. There is no reason to assume that R7B should perform different from R7A.

The plots have the message size on the X-axis, and either the time or the bandwidth (bytes per second) on the Y-axis.

The code doing the measurements can be found here. It was invoked from this makefile with: make test.

Test type

  • Echo test: One message at the time is sent on the socket. It is echoed at the other end, and when the message has been returned, the next message is sent.
  • Flow test: Messages are sent as fast as the Erlang runtime system allows. At the receiving end the messages are just received and wasted.

Server node type

  • Local: The server node, i.e the node that echoes or receives, is on the same machine as the client node, i.e the node that sends and measures the time.
  • Remote: The server node is on another machine than the client node.

Number of sockets

  • Single: Just one socket is tested. It has one client-server process pair at the socket ends.
  • N parallel: N sockets are tested in parallel between the client and server nodes. Each socket has got a client-server process pair. The time is measured as the mean time for all sockets.

Data type

  • List: The messages are lists of bytes.
  • Binary: The messages are binaries.

Results

I will not show all plots in this document, to prevent the reader from falling asleap, but plots for all test combinations do exist in this very directory. It should not be hard for the curious to find and identify them.

Echo tests

The improvements are not astonishing in the echo tests. Most of the time is probably consumed by process scheduling, also on the server side. For remote tests, the network transfer time seems to be dominant.

Note that the plots have latency on the Y-axis, so the lower the better.


The new driver is about 25% faster. This is probably because one intermediate process has been removed. The same also applies to binaries.

When the server is on a remote node, this improvement is not noticable. It probably disappears in the TCP/IP protocol overhead on the host machine.


Here the new driver is about 50% faster. In this case there are 16 intermediate processes less in the new system, so it probably has faster process scheduling. For binaries, this effect is not as pronounced, but the [16 parallel] is faster than [single].


In this case, the scheduling improvements becomes measurable (about 40%), at least for small binaries. The corresponding test for lists show the same result.


Flow tests

In the flow tests, the improvements are more noticeable. There are some peculiarities for remote tests, though, where the new system seems faster only for small messages. Anyone who figures out why will receive honour and gratitude.

Note that the plots have bandwidth on the Y-axis, so the higher the better.


The new driver seems to be 2 to 3 times faster. The corresponding figure for binaries is almost 2 times.


Here the new driver is some 3 times faster for small binaries, but about 25% slower (i.e 0.75 times faster) for big ones. We find this strange. The same also applies to lists, also with a break-even at about 200 bytes.


For [flow test, 16 parallel] the results are as in the previous tests. The new driver is almost 3 times faster, but for remote tests of messages larger than 200 bytes it is some 20% slower. Weird. This plot shows [remote, list].


UAB/F/P Raimo Niskanen
raimo.niskanen@uab.ericsson.se
Updated: 2000-09-28