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

mlist user mlist.user8080 at gmail.com
Tue Dec 4 00:12:15 CET 2012


On 4 December 2012 10:10, mlist user <mlist.user8080 at gmail.com> wrote:
> 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: 1500):

[ ... ]



More information about the zeromq-dev mailing list