How to set ConflationInfo?

@Umer Nalla I set this variable but I don't think I get what the conflation logic. Something wrong with my request?

SENT: { "ConfInfoInUpdates":true, "ID":2, "Key":{ "Name":"/IBM.N" }, "View":[ "TRDPRC_1", "TRDTIM_1", "SALTIM", "EXCHTIM", "TRADE_DATE", "ACVOL_UNS", "BID", "ASK", "CURRENCY", "ASK_TM_NS", "BID_TM_NS" ] }

RECEIVED: [ { "DoNotConflate":true, "Fields":{ "ACVOL_UNS":212538, "ASK":138.63, "BID":138.6, "EXCHTIM":"16:23:04", "SALTIM":"16:23:04", "TRDPRC_1":138.61, "TRDTIM_1":"16:23:00" }, "ID":2, "Key":{ "Name":"/IBM.N", "Service":"ELEKTRON_DD" }, "SeqNumber":3518, "Type":"Update", "UpdateType":"Multiple" } ]

Hi @Xiao.Xiao

Can you confirm if the service you are consuming from is actually a truly Conflated service?

I do not have an ADS with a Conflated service to test with at this point in time - so cannot confirm this, but I suspect that the service you are consuming from is not conflated and therefore you do not receive any Conflation information in the Updates.

In the Refresh Message what do you see for Qos - Timeliness and Rate ?

You included an example update with the "DoNotConflate" attribute - which indicates that the update includes Trade data and therefore should not be conflated. This may also indicate that you are consuming from a JitConflated service i.e. Just-in-time conflated, meaning that quality is typically tick-by-tick, but if burst data occurs (or if a component cannot keep up with tick-by-tick delivery), multiple updates are combined into a single update to reduce traffic. This value is usually considered a lower quality than TickByTick

If you were consuming from a truly conflated service, then the Rate would be indicated as TimeConflated along with a RateInfo value indicating the Conflation interval.

Hi @Umer Nalla

thanks for the explanation, here is the Qos:

"Qos":{ "Rate":"JitConflated", "Timeliness":"Realtime" }

as you suspected...

So just to confirm my understanding:

• the gaps between consecutive timestamps in my original post, where the updates are around 30 seconds, are due to "burst data occurs" (?) Is it possible for users to control the update interval in some way?
• the behavior we see here indicates that I don't have conflated service to start with
• even if I had, the conflation cannot be configured by users but the Market Data team

Hi @Xiao.Xiao

• The gaps could be because you are using a View and the updates to the fields in your view are not occuring more often and / or that particular RIC is not that active. It could also be because Msg Packing is enabled on the ADS you are connecting. I am not a TREP expert and you have not provided enough data - so cannot confirm if this is the cause.
• You are most likely connecting to a Bandwidth optimised Trade Safe feed which is i.e. upto 3 (non-trade) Updates a second + all Trade updates
• If you are connecting to ERT in Cloud, then the Trade Safe BoN feed is all that is currently available. If you are connecting to a TREP, you can ask your Market Data team to configured a different conflation rate service for you.

A user cannot configure the conflation rate from his application - since it can require considerable processing power for the TREP components to Conflate data - and so it left in the hands of the Market Data team to configure, so they can access the potential impact on performance etc before adding a conflated service.

thanks @Umer Nalla, may I have one more follow up on the first point? I really appreciate that!

The gaps has been there regardless of the variation of query I sent. For the example, these gaps were observed without using VIEW and the RIC I was looking at is IBM.N durning market hours - I was surprised that a constantly traded big cap like IBM only have a few updates...

Please let me know how to check the enabled MsgPacking, but this is the response from the authentication step:

RECEIVED: [ { "Domain":"Login", "Elements":{ "MaxMsgSize":61430, "PingTimeout":30 }, "ID":1, "Key":{ "Elements":{ "AllowSuspectData":1, "ApplicationId":"256", "ApplicationName":"ADS", "AuthenticationErrorCode":0, "AuthenticationErrorText":{ "Data":null, "Type":"AsciiString" }, "AuthenticationTTReissue":1561480846, "Position":"10.194.238.132/u6065010-tpm-a.ten.thomsonreuters.com", "ProvidePermissionExpressions":1, "ProvidePermissionProfile":0, "SingleOpen":1, "SupportBatchRequests":7, "SupportEnhancedSymbolList":1, "SupportOMMPost":1, "SupportOptimizedPauseResume":0, "SupportPauseResume":0, "SupportStandby":0, "SupportViewRequests":1 }, "Name":"AQIC5wM2LY4SfcxRdBbl%2B8dgyd%2BWx0aChwHOX0vyMMQa05E%3D%40AAJTSQACNDAAAlNLABQtODAwODE1MjU3ODgzODY3MDg1MAACUzEAAjM4%23" }, "State":{ "Data":"Ok", "Stream":"Open", "Text":"Login accepted by host ads-premium-az2-blue-9-main-prd.use1-az2." }, "Type":"Refresh" } ]

Hi @Xiao.Xiao

Based on the most recent bit of information you have provided, you are connecting to ERT in Cloud and this operates a Bandwidth optimized Tradesafe conflation as I described earlier i.e. a upto 3 Updates a second - but it wont conflate Trade type updates - so you will receive all Trades even if that exceeds the 3 update limit.

If you believe you are missing information, you should raise a ticket with the Content helpdesk and ask them to confirm the tick history for your instrument.