OnixS C++ CME Market Data Handler  4.4.1
API documentation
Frequently Asked Questions

Can more than one channel per Handler be processed? Or are multiple Handler instances necessary?

One instance of OnixS::CME::MDH::Handler processes market data for a single channel only. To process data from multiple channels multiple handler instances shall be created.

Permanent link to the answer

Is the Handler implicitly subscribed to all instruments of the specified channel? Will it receive security definitions for all instruments of this channel?

Yes, exactly.

Permanent link to the answer

How does instrument/group filtering work? Why would we want to do this?

Filtering (instrument selection) is useful when market data required for specific instruments only. Instrument selection is used like inclusive 'white list', e.g. if security A is selected, security-related events (members of OnixS::CME::MDH::SecurityListener) are raised for security A only.

If two or more securities are selected, events will be triggered only for those securities.

See also
Selecting Securities of Interest

Permanent link to the answer

How do we know whether the data delivered through onBookAtomicUpdate is the first or last change of a "transaction"? That is, how can it be determined that the order book is valid/consistent/not-crossed after a single onBookAtomicUpdate() call?

It's a bit more complicated with book consistency & up-to-date. Please, note that actually CME doesn't guarantee 100% book up-to-date on intermediate updates. It's guaranteed only after 'End of XXX quote' market event where XXX is real or implied. So you have to check this field to ensure the book is 100% up-to-date.

Actually it can be achieved by using book update callbacks of OnixS::CME::MDH::SecurityListener rather than atomic book update listening. They are publishing the books only on 'End of XXX quotes' market event giving guarantee books are consistent and up-to-date.

See also
OnixS::CME::MDH::SecurityListener, OnixS::CME::MDH::MarketDataListener

Permanent link to the answer

How to retrieve/receive the initial order book?

Any OnixS::CME::MDH::SecurityListener::onBookUpdate call will give you consistent order book state (except for Natural Refresh mode). If you need book state at startup you can just get snapshot at first call.

See also
Constructing And Copying Books

Permanent link to the answer

After switching the Operating System even the sample program is no longer able to receive market data (code=NoNetworkActivity). However, I am able to ping the CME router and iLink server. Any insight or suggestions on what may be going on here?

See Connectivity Troubleshooting.

Permanent link to the answer

If Handler joins while the market is busy, warnings (code=QueueOverflow) are reported. Is there any possibility to raise the configured limit, if so how?

When Handler performs book recovery, it caches all the data received on incremental feeds. When the market is busy, number of cached messages may exceed configured limit defined by OnixS::CME::MDH::HandlerSettings::recoveryQueueMaxSize parameter value. So, to avoid QueueOverflow warnings, it's necessary to increase value of the noted parameter.

Permanent link to the answer

What is the cause of 'QueueOverflow' warnings?

The cause is violation of sequence of received packets (gap) that wasn't restored after OnixS::CME::MDH::RealtimeFeedSettings::outOfOrderPacketMaxInterval number of packets of after OnixS::CME::MDH::HandlerSettings::lostPacketWaitTime elapsed. Violation of packet sequence can be caused by packets loss on different levels: CME environment issues, network connectivity issues, system or application issues.

Also, when Handler performs a large-scale recovery due to gap or while joining market lately, incremental packets are cached. In case of intensive data transmission, queue keeping incremental packets may reach its limit causing noted warning.

Please refer to our Lost multicast packets troubleshooting guide for more details.

See also
Connectivity Troubleshooting.

Permanent link to the answer

What's the difference between 'Book Atomic Update' and 'Book Update' events?

Book Atomic Update (OnixS::CME::MDH::SecurityListener::onBookAtomicUpdate) is an elementary action over a book and usually there're multiple atomic updates inside a single snapshot or incremental refresh. Also, book may not be valid between two atomic updates. Only when all atomic updates are processed from the single market event, book is considered as valid.

Book Update (OnixS::CME::MDH::SecurityListener::onBookUpdate) are raised exactly at a time when all atomic updates are processed and book appears to be valid and up-to-date.

See also
Building and Maintaining Books by Yourself

Permanent link to the answer

While processing market data for CME, I noticed that some instruments dividing by 100, some other by 10000 and others don't. How do I determine what value to scale the prices by?

Security definition sent by Market Data Platform contains fields

representing the multipliers to convert the CME Globex display price to the conventional price.

See also
CME Pricing documentaton.

Permanent link to the answer

Which latency is added by the Handler?

Minimal book update latency falls into 100-250 nanoseconds depending on hardware/operating system/network conditions. Please, contact Onix Sales for most recent official benchmark results.

Permanent link to the answer

What is Handler CPU consumption?

It depends significantly on many different parameters including network, hardware, operating system environment, market data rate and applied handler settings.

Permanent link to the answer

What is the expected maximum latency our callback implementation should have?

The smaller the better. It shall be microseconds to do not impact handler ability to process data on high tickers.

Permanent link to the answer

How are problems with market data indicated (book became invalid)?

All errors and warnings are reported through OnixS::CME::MDH::HandlerListener::onError and OnixS::CME::MDH::HandlerListener::onWarning callbacks respectively.

See also
Handling Issues Like Errors and Warnings

Permanent link to the answer

How can packet issues (back-pressure/queuing) be diagnosed?

Handler allows to trace packets as they are received by active feeds including out-of-order or duplicated packets (in contrast to market data listening which exposes packets passed through session rules). With the help of new OnixS::CME::MDH::FeedListener listener it's possible to write advanced diagnostic services.

See also
Listening for Activity on the Feeds

Permanent link to the answer