[zeromq-dev] high frequency trading

John Muehlhausen jgm at jgm.org
Fri Jan 12 12:56:57 CET 2018


Proximity is most important because milliseconds can be eliminated in
network hops.

On the hardware side you want to use something like Solarflare or Myricom
("kernel bypass") network cards.  In the former case at least, you (or a
lib like 0mq) can use the same sockets API via LD_PRELOAD of OpenOnload.

In order for OpenOnload to acclerate 0mq's internal signaling system, you
need to hack it to use pipe(), which is a fairly trivial change.  The goal
is to turn all kernel signaled waits into polling waits.  (Look at what it
means to bypass the scheduler and affinitize threads to cores... thread to
core mapping becomes 1:1.)

All of that said, I have abandoned 0mq for this purpose, because it is too
heavyweight to chase the last microseconds of delay out of a system.  The
ideas in the "multithreading magic" paper are spot on, but a more efficient
implentation is needed, and I'm not aware of an open source communications
layer at this point.  (Shops in this line of work do have proprietary
solutions.)

-John

On Fri, Jan 12, 2018 at 1:31 AM Laurent Alebarde <l.alebarde at free.fr> wrote:

> Hi,
> I read in some places that in its infancy, 0MQ was aimed at high frequency
> trading. From what I can read, this field first requirement is on hardware,
> short links (proximity) and algorithm. I would like to understand more
> please what makes 0MQ good for robust and rapid transactions ?
> Regards,
> Laurent
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180112/6771cdbe/attachment.htm>


More information about the zeromq-dev mailing list