[zeromq-dev] EPGM Congestion Control

[Steven McCoy]

On 13 May 2011 21:40, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Michael,
>
> > 2. Correct me if I am wrong but I thought EPGM was PGM implemented over
> > UDP. If this is correct then after you create the datagram socket you
> > can set the option IP_MULTICAST_TTL via setsockopt. I do not believe
> > this is currently available in 0MQ. Is that correct?
>
> It's up to Steve to decide here. Does it make sense to set TTL in
> context of PGM? What does the spec say? Is it exposed in OpenPGM API?
>
> If so, there's no problem in adding it to 0MQ API.
>
>
It is available as a PGM socket option, PGM_MULTICAST_HOPS as per

http://code.google.com/p/openpgm/wiki/OpenPgm5CReferencePgm

It's presently hard coded inside ZeroMQ to 16, if you have Cisco hardware it
is recommended not to set it to 1.

https://github.com/zeromq/zeromq2-1/blob/master/src/pgm_socket.cpp#L329

> 3. Yes, I could provide a patch. I plan on using 0MQ to distribute
> > multiple prices feeds. It’s not realistic to batch prices until you have
> > a full UDP packet before sending them. This would add latency where it’s
> > not desired. I am assuming there is a timer tied to the queue which is
> > performing this limit. Is that timer configurable and what is the
> > default time interval?
>
> Ah. I thought you want the interoperability rather than low latency.
>
> No there's no timer. The messages are pushed to the network immediately,
> if possible. The only case when message batching happens is when
> publisher publishes them faster then the network is able to accept them.
> In such case there's no latency impact. Thus, sending one message per
> packet is unlikely to improve the performance.
>
>
 To reiterate for Michael, this is how ZeroMQ provides high performance.
 Messages are only delayed when the socket pushes back, your latencies are
driven by NIC performance and any interrupt coalescing.  Timers are only
used when the transport fails, other messaging systems are effectively
re-implementing NIC interrupt coalescing and it is the synchronisation
overhead between the application and sending thread that significantly harms
performance as is discussed in the ZeroMQ whitepapers:

http://www.zeromq.org/area:whitepapers

Back to PGM congestion control, this is an actual technology and it has
support inside OpenPGM, however current testing has shown a probable
protocol flaw that limits effective throughput to 10,000 messages per
second.  There are no ZeroMQ bindings to enable PGM congestion control as I
don't consider it fit for production.  It probably requires a long research
project with ns-2 or ns-3 to resolve.

There is even a PGM congestion control dedicated for wireless networks which
considers radio signal interference patterns, but no support for that is
planned until regular congestion control is more resilient at high speeds.

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110514/74972271/attachment.htm>