[zeromq-dev] Comparing OpenDDS and ZeroMQ Usage and Performance
sustrik at 250bpm.com
Thu Jun 24 21:53:39 CEST 2010
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
10.201.200.72 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