Hi @luxiangyuan

Looking at the information provided so far, it looks like what you are observing is to do with the fact that you are connecting to a Trade safe Conflated service and the difference in trading / quote activity between the two RICs : /3800.HK and /6178.HK

A Trade safe conflated means that the service does not send out every tick update to your application (to reduce traffic between your application and the server). It collects any field updates during the configured time period and then sends out a single timed update periodically. Because it is Trade Safe, it will also send out any Trades immediately (without waiting for the next timed updated).

As you will note from the Tick history extracts that I have attached for the two RICs, the last time /6178 had a Quote or Trade was 06:54:30 and the next one was at 6:56:02.

However, /3800 was much more active during that period and had several Quotes including one at 06:55:16.

So, in your extract you received a conflated update for 3800.HK at some point after 6:55:16 and you then also received a conflated update for 6178.HK shortly after. But that conflated update did not have any recent Quote or Trade values - so the most recent TRDTIM_1 would be for the last Trade that took place on 6178.HK - which was at 06:54:30

If you go through your Update history for 6178 - you should have received other updates before the one in your log above.

2018-12-21-12-49-22-6178hkcsv.png

Hi @luxiangyuan

For Content type queries, I recommend you contact the Content Helpdesk - who will be able to explain the time differences you observed.

As far as the Elektron APIs are concerned, they will send the data to your application in the order they receive the data from the server.

If the Content helpdesk cannot explain your observation, then please attach some more of your output here - showing several updates before and several after the ones you posted - for those two instruments.

Hi @luxiangyuan

I understand from Content Helpdesk that you contacted them and your quote-log values do not tie up with the Tick History database we hold.

Therefore, if you still have more of your output from a few minutes before the above quote-log please attach here.

Also, please add XmlTraceToFile =1 your EMAConfig.xml file config entry for whichever Consumer config definition you are using. If you are not using EMAConfig then just add to the DefaultConsumer as shown below.

 .... 
<DefaultConsumer value="Consumer_1"/> 
<ConsumerList> 
<Consumer> 
      <Name value="Consumer_1"/> 
      <Channel value="Channel_1"/> 
      <Logger value="Logger_1"/> 
      <Dictionary value="Dictionary_1"/> 
      <XmlTraceToFile value="1"/> 
</Consumer> 
.... 
....

Please ensure the EMAConfig.xml is in the working directory of your application.

Once you have done that, please rerun your application and upload the XML Trace file (You can remove any username/password / ip address etc from the trace if any is present). If you are able to observe the same disordering scenario when you run your app with the XMLTrace enabled, then also include the relevant quote-log too from the new run. This way I can compare what the API receives from the server and what your application is then receiving in the UpdateMsgs.