Ninja + Zenfire vs Ninja + TT feed

Discussion in 'Order Execution' started by hanzahar, Aug 15, 2008.

  1. Last october they effectively doubled the trade-ticks they transmit. They unbundled ticks that were previously aggregated into single transactions. See:

    http://www.cmegroup.com/globex/files/EquityFuturesEnhancements.pdf

    CME speaks about 20% increase in bandwith utilization, but it was more likle 50%. I can see how software, that is already on the edge performance-wise, can run into problems.
     
    #111     Jan 18, 2010
  2. This has always bothered me:

    "Equity futures now send milliseconds in iLink timestamps, as options and FX futures do today. FIX/FAST timestamps will always default to “000” milliseconds and should not be relied upon by customers"

    Basically they say they are able to process order messages in 1/100 of a second. But they purposely omit milliseconds from their time stamps...

    Message Response time from 2008 to 2009
    ES From 16.95ms to 9.45ms
    6E From 11.73 to 3.90 ms

    Page 49: http://www.cmegroup.com/globex/files/CustForum_2009_Q4_ChicagoNY.PDF


     
    #112     Jan 18, 2010
  3. jeb9999

    jeb9999

    That 14 milliseconds for Globex has to be outdated. As far as I know the Globex data update rate is faster than the Globex trade matching rate.

    From the Globex Fact Sheet (September, 2009): "We execute customer trades in under 7 milliseconds on average, with some markets trading in 2.5 milliseconds"

    What are all the platform developers going to do when the Globex trade time (and data update rate) goes under 1 millisecond?
     
    #113     Jan 18, 2010
  4. I agree, it was more like 50% or even more as there was definitely a very noticeable difference.
     
    #114     Jan 18, 2010
  5. They might consider to create better software... perhaps
     
    #115     Jan 18, 2010
  6. CME Autocert only requires a platform to process 10 transactions per second. CME's Autocert Performance testing has a limit of 70 TPS. This was where the 14ms limit came from.

    Price feeds are multicast, capable of delivering quotes substantially faster than your platform can process and execute orders.


     
    #116     Jan 18, 2010
  7. Pocket I am curious. You said the price is output at almost max rate for a message pump..

    Obviously you are talking about UI. My question - what are you going to display with rate of 700 messages / sec? What user can possibly need at that speed? What is the point to display it if no human brain can process it? Dont you think that beyound 25-50ms threshold there is nothing to explore in terms of UI?

    The other question - 700 messages/sec - is it limit of one pump or as a total for all pumps in Windows? I mean - you can start another window with separate pump. Will it duplicate the limit?
     
    #117     Jan 19, 2010
  8. That was kind of my point.

    The message pump limits were from a ms document: http://msdn.microsoft.com/en-us/library/aa140060(office.10).aspx





     
    #118     Jan 19, 2010
  9. are you reffering to this?

    "The number of times that a single topic can be updated seems to be limited by the number of times that Excel checks for Microsoft Windows® messages, which is at most 700 times per second. Since some of the messages have higher priority than RTD does, Excel effectively gets about 200 updates per second."
     
    #119     Jan 19, 2010
  10. Yes... Old dated document but the principles apply to Windows GUI and Real Time event based processing.


     
    #120     Jan 19, 2010