[zeromq-dev] epgm protocol question

Martin Lucina mato at kotelna.sk
Tue Apr 13 15:30:09 CEST 2010


sustrik at 250bpm.com said:
> Yes, you are using 1/5 of your link, but 100% of the bandwidth you've 
> assigned to the socket. If you data feed you want to send is 20Mb/s you 
> should set the rate slightly higher so that there's space for RDATA.

This is exactly the case we've been discussing with Steven over the last
few weeks. I guess we should have had that discussion on the list :-(

> However, my guess is that you are simply pushing data to the socket as 
> fast as possible. That way you are going to saturate the rate however 
> high you set it. In such case you are guaranteed your network won't be 
> overflowed (max is 20Mb/s) but you experience messages lost as there's 
> no spare rate available for RDATA.

The problem as I see it is that:

1. 0MQ by definition will publish as fast as the underlying transport
   allows it to.

2. There will always be some inherent packet loss on an ethernet LAN, even
   if it is 1%.

3. We (0MQ) are providing the application an abstraction of a pipe that you
   are explicitly allowed to send to as fast as possible. The underlying
   transport (OpenPGM) provides an interface to rate limit said pipe, and
   0MQ takes that at its word.

There is a conflict here: Should the application care about the underlying
properties of the transport and deal with it's own rate limiting? In my
opinion the answer is a resounding no.

> In theory, the rate could be spread between RDATA and ODATA (maybe two 
> different rate limits) but again: how would you establish the ratio?

That's a good question, but this needs to be done either on the 0MQ side or
on the OpenPGM side since the current situation is non-functional!

In my opinion the correct way to do this is to have OpenPGM
reserve e.g. 5% of the requested data rate for RDATA by default, with the
option to configure the reserved bandwidth amount for those who wish to
shoot themselves in the foot.



More information about the zeromq-dev mailing list