DICElib was developed to synchronize video frames in a graphical cluster, so it was expected to have a high performance. Tests realized with it show that it's more than adequate for this use.
The test was ran in two Dual Pentium III 933MHz, 1GB RAM, optical Gigabit-Ethernet. Given a vector of integers (4 bytes), update the vector and synchronize the applications ten thousand times. We ran this test for several different vector sizes. The results proved that the time spent linear with the number of variables, proving that there's no overhead for large packets, and the time depends only of the amount of data to be transferred.
The results are quite good: even transferring 4000 variables (that is, 16kb of data) per frame, we achieved 550.1 updates per second. It is more than enough for video synchrony, and most virtual reality applications are likely to transfer only a few bytes of data, containing information such as position, orientation, etc. The highest update frequency was for 250 variables (which was the lowest number ran), with an average of 5988.0 updates per second. The bandwidth taken is small: only 8.8Mb/s. The limitation seems to be imposed by TCP/IP buffering constraints. The program used is in tests/bench.c.
Small applications, such as test/around.c and test/rotate.c were run in two and three nodes, and there was no noticeable difference in the synchrony, independent of the frame rate.