Hi, Martin Sustrik <sustrik <at> 250bpm.com> writes:
> > Michael, > > > I've never seen this kind of latency for 1KB messages, but then again I've > > only used 0MQ on Linux. I don't have access to a system with a real-time > > kernel, but I'd be willing to try to duplicate the raw buffer comparison > > tests on Linux w/ Ethernet and 20Gb Infiniband. It will be a couple of > > weeks before I can get around to it though. > > That would be great. Thanks! > > Martin > 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. 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. 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. Best Regards, Don Busch Principal Software Engineer Object Computing, Inc. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
