[zeromq-dev] general strategy for sending data over epgm

[mlist user]

Hi Justin,

On 4 December 2012 09:19, Justin Karneges <justin at affinix.com> wrote:
> On Monday, December 03, 2012 09:59:12 PM Ian Barber wrote:
>> On Mon, Dec 3, 2012 at 8:50 PM, mlist user <mlist.user8080 at gmail.com> wrote:
>> > Hi Andrew,
>> >
>> > On 4 December 2012 07:47, Andrew Hume <andrew at research.att.com> wrote:
>> > > i'm not sure what the issue is.
>> > > if the rate is small and the messages are large, then yes, you need to
>> >
>> > sleep
>> >
>> > > large amounts.
>> >
>> > How would you figure out you need to sleep X second?
>>
>> Are you setting the RATE sockopt yourself and then trying to manage the
>> pace at which you send on top of that?
>
> Slightly OT, but I wonder if RATE might be a useful feature to allow for all
> PUB sockets (and maybe just all sockets), rather than restricted to pgm only.
>
> It seems to me that you want to use RATE when you need to slow down sending
> but can't depend on receiver feedback. This is a problem at the pattern level,
> not the transport level.

I have modified my src.

Currently testing a single {key:'foo', value:"49mb /dev/zero"} and
have the following:

mcast_sender.py:    	
        self._sock.setsockopt(zmq.SNDHWM, 200 * 1024)
    	self._sock.setsockopt(zmq.SNDBUF, 64*1024)
	self._sock.setsockopt(zmq.RATE, 1000)
        (no sleeps)

mcast_receiver.py:
    	s.setsockopt(zmq.RCVHWM, 200*1024)
    	s.setsockopt(zmq.RCVBUF, 64*1024)
	s.setsockopt(zmq.RATE, 1000)
        (no sleeps)

The multicast is happening at full throttle (mtu: 1452):
10:07:42.641075 IP 172.16.255.3.33096 > 224.0.0.1.5555: UDP, length 1452

I think it's looking good so far but removing those sleeps makes the
code much more predictable.
Thanks