Hi Michel, Question was about the latency to wake up a quiet thread blocking on a select. The answer was already given to me: busy spinning. I was able to pull down the latency to around 60 micros for a a single packet. As you increase the number of packets it goes down exponentially to 10 micros. I even get some packets doing the round trip in 8 micros.
Does ZeroMQ support some kind of reliable UDP for a publisher-subscriber / one-to-many asynchronous messaging system? -J On Sat, Aug 25, 2012 at 12:24 PM, Michel Pelletier < [email protected]> wrote: > On Thu, Aug 23, 2012 at 1:12 PM, Julie Anderson > <[email protected]> wrote: > > > > Hi, > > > > <Java NIO UDP benchmark results snipped> > > > So my questions for the community are: > > > > 1 - Is my minimum time of 13 micros with average of 19 micros optimum for > > this round trip packet test. It looks like I am beating ZeroMQ by far so > I > > may be missing something here. From this benchmark it looks like ZeroMQ > has > > a 49 micros avg time (99% percentile) on a standard kernel => > > http://www.zeromq.org/results:rt-tests-v031 > > It seems to me that you are comparing two very different things here. > The time to send a udp packet back and forth in a tight single > threaded selector loop is definitely going to be faster than a message > being sent back and forth using tcp as 0mq does, and then add on top > the overhead of 0mq managing the message across a thread boundary from > your application code to the core library. The udp approach is going > to be faster, by far. Of course it doesn't seem likely your NIO code > offers the same feature set as the 0mq library does from a messaging > framework point of view. > > > 2 - Is there anything I can do to improve the selector reaction time > when I > > spin a single or very few messages? 150 micros does not look good. Or > should > > I assume that on a prod environment the selector will never be quite? > > So is this a Java NIO question? Or are you asking how our 49ms beats > your 150? I think you meant "quiet" instead of "quite", but I'm still > confused as to the question. Maybe post your benchmark code and we > can get some insight into what you're asking. > > -Michel > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
