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 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. Ack. > 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. Martin _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
