Greetings Laurent, John. I know that Teza technologies used to deal with automated trading.
CC'ing to Dave McAllister from Solace, they seam to background in hardware appliances for stock exchanges, just not sure if for internal infrastructure or external, trader related usage. Perhaps he could help. Dave, please join our conversation. On Fri, Jan 12, 2018 at 11:46 PM, Laurent Alebarde <[email protected]> wrote: > Thanks very much John. I will meet soon people with a powerfull and > innovative solution on top or underneath tcp that reducies significantly > latencies. Tests looks awesome. If you are interested, I will come back to > you. > > Back to my primary question, I understand the benefits of 0MQ for > scalability. I understand that for reliability, it guarranties that > messages are delivered fully or not at all, but it does not guarranty > delivery itself. So the application has to take care of it. > > But I don't understand its benefits for performances. And if it actually > improves performances, which ones precisely (latency ?) and how does it > works ? > > Laurent > > > Le 12/01/2018 à 12:56, John Muehlhausen a écrit : > > 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 <[email protected]> > 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 >> [email protected] >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > > _______________________________________________ > zeromq-dev mailing > [email protected]https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
