[zeromq-dev] Comparing OpenDDS and ZeroMQ Usage and Performance

Martin Sustrik sustrik at 250bpm.com
Thu Jun 24 21:53:39 CEST 2010

Hi Don,

First of all, thanks for doing the benchmarks and writing the paper!

> I wrote the paper.  If you'd like to run the tests on a faster box with an RT 
> kernel, that would be great.  That's why the source code is attached, and the 
> paper encouraged users to build the code and run the tests themselves.

I don't think the RT kernel would make a difference. RT kernel is good 
for eliminating latency peaks, however, average latency tends to be the 
same or even worse than with non-RT kernel.

> The laptop I ran them on is really old and slow, and the paper stated as such, 
> so the raw numbers aren't worth much. It's the relative numbers that are more 
> interesting. I needed a Windows box for the .NET comparisons.

I see. That can possibly mean that there's no Win platform performance 
regression as I thought, just that the computer was slow.

I'll check on my box. Just to be sure: It was run on a single box and resolved into TCP loopback interface, right?

> The point of the paper is that the decision to use ZeroMQ or OpenDDS depends
> a lot on what you're using it for.  If all you're doing is sending raw buffers 
> over the wire, and your collection of participating processes doesn't change 
> throughout the execution of the system, then ZeroMQ will be faster than 
> OpenDDS.  But if you are sending something like C++ structs, then you have to 
> build that capability on top of ZeroMQ one way or another and that will kill
> any performance advantage that ZeroMQ has.  Also, if your system consists of 
> processes that intermittently come and go, then OpenDDS can handle that right 
> out of the box whereas you'd have to build it on top of ZeroMQ.  OpenDDS also 
> has a load of QoS capabilities that the article doesn't really talk much 
> about, capabilities that you'd have to build on top of ZeroMQ if you 
> want them.


> So to summarize, I guess, we'd encourage users to look at their full end-to-end 
> use cases to figure out what they really need.  If they find themselves wanting 
> to build things on top of ZeroMQ that are already in OpenDDS, then they most 
> likely eliminate the performance advantage of ZeroMQ while also creating a lot 
> of extra work for themselves.
> But, yes, I certainly encourage people to take the code and build and run it 
> themselves. ZeroMQ looks like an interesting product.


More information about the zeromq-dev mailing list