I am migrating an application to Eikon, and I am getting some serious issues with the time series subscription. This is my first encounter with Eikon and TR in general (although I have experience with other platforms), so I think this might simply be a case of teething issues.
What I'm trying to achieve is fairly simple. My application acts as a gateway for other applications (for simplicity, let's call them clients) to receive minute-by-minute OHLCV pricebars of a set of stocks. Upon startup, each client connects to the gateway, which then sets up an input and output thread, through which my clients instruct the gateway to request time series subscriptions for a list of stocks, (unless a subscription already exists for that stock). When a pricebar is received, it is sent to each client that wants to receive it.
However, I'm having some issues, and I can't quite pinpoint the causes.
1) I don't know when a pricebar is 'finished'. All I know is when a new bar arrives, from the 'NewPoint' UpdateType. Because of this, I have two options: consider the pricebar 'closed' at 0 seconds past the minute [according to my local machine time, perhaps risking loss of information], or use the 'NewPoint' property of a new bar as a signal to consider the current pricebar as closed (which I use, and justify because the 'NewPoint' bar has no OHLC data). On this assumption, the first price bar to 'complete' always does so around 5 seconds after its quoted time, whereas I need it to arrive as soon as possible.
2) The second to arrive in a given minute comes at any point between that time and 35 seconds past the minute, if it arrives at all. When I have, for example, 4 stocks' time series subscribed, after ten minutes I only have pricebars for one or two stocks coming in every minute, with the remaining two simply not arriving (the receiving function on the gateway application simply isn't called for that stock). What I'm looking for is every pricebar to arrive for the full duration of the market hours, and within e.g. the first second of each minute.
Unfortunately, the guide only gives a limited range of examples (e.g. a single subscription).
A) Perhaps I should be loading all stocks into a single subscription, rather than creating separate subscriptions for each stock? I am storing the subscriptions in a list, just incase they don't stay alive otherwise.
B) Or maybe there are problems with the Eikon API in a threaded application? The requests are performed by the "input" threads for each respective client.
C) I am creating the subscriptions on the same TimeSeriesDataService. Whilst I can't see any reason for this to be out of the ordinary, could this be the source of my problems?
D) On the assumption that I can't achieve my requirements with a time series subscription, I have decided to start looking into forming my own pricebars from RealTimeData, forming OHLCV bars every minute. This data seems to be very useful, and I'm reasonably comfortable with this idea. As I'm looking at both price and volume, I use SetupDataRequest. I need slight clarification so that I am not operating under any assumptions - do the trade fields, e.g. TRDPRC_1, ALWAYS become TRDPRC_2 in the following update, or is it possible that multiple 'fresh' trades occur in a single update? Is the RealTimeData subscription guaranteed to always contain every trade?
Thanks for any help. I can provide a MWE on request, but I've hopefully provided enough information.
1
●1 ●1 ●3
Eikon .Net API - Multiple time series subscriptions are causing problems
39.2k
●75 ●11 ●27
Hi @JMCQ,
1. You're right, this API does not provide a notification when the bar is closed. NewPoint is an indicator that a new bar starts being built. It's not a good indicator that the old bar is closed in the sense that the new bar starts being built only when the new update arrives. For less liquid instruments you may have prolonged periods of time without any updates. In this case the NewPoint will not appear for seconds, minutes, hours or even days. And yes, this results in gaps in 1 minute summarization of the timeseries for less liquid instruments. For illustration see for example 1 minute chart of <KZT=> in the Chart app in Eikon. However it sounds like the instruments you're looking at are updated very frequently. If you can rely that the instruments you're interested in update at least once a second, then you can use NewPoint as a trigger to close the previous bar, and the time lapse between the end of the interval and the NewPoint trigger will not be more than a second. The consistent five second lapse that you observed is likely to be due to the difference between your local machine clock and that of the Thomson Reuters timeseries service. If you cannot rely on the instruments you watch to consistently update with the frequency ensuring that the time lapse between interval end and NewPoint is acceptable, then I'm afraid your only option is to use your local machine clock to close the bar. You will need to calibrate your local machine clock based timer as close as you can to that of the Eikon timeseries service. And as a contingency you can perhaps also add the code to correct closed bar, if contrary to expectations you receive an update for ExistingPoint after the bar is closed.
2. I would very strongly recommend single threaded architecture for the code retrieving data from Eikon using Eikon .NET SDK. The reason is that Eikon .NET SDK assemblies have a dependency on single apartment threaded COM library. There's no gain in efficiency in multithreaded architecture, as all the work has to converge on a single thread in the COM library. While multithreaded architecture may be convenient for your use case, from experience it may lead to problems like the one you describe, which are extremely hard to troubleshoot.
A) You cannot use single subscription for multiple RICs. Each subscription is for one RIC only.
B) As per above I would strongly recommend to do all data retrieval from Eikon on a single thread.
C) You should indeed use single TimeSeriesDataService. Single TimeSeriesDataService is not the source of the problem you experienced.
D) This depends on your market data infrastructure, which may include market data conflation. If you have local market data infrastructure you should direct this question to your company's market data department. Assuming you have no local market data infra and your Eikon connects to Thomson Reuters infrastructure over the Internet, then you can rely on every trade coming in as a separate update and on TRDPRC_1 being rippled to TRDPRC_2 following a trade. Bid and ask quotes are conflated by Thomson Reuters hosted market data infra to 330 milliseconds. But the conflation is trade safe. Trades are not conflated.
Thank you very much for your detailed response. It looks like this will be very helpful for me - it gives me a lot to work with. I will try out some possible approaches and see how it goes. Thanks again!
66
●4 ●7 ●12
@Alex Putkov, you repeat on saying that you recommend a single threaded approach. As you are well aware multi-threaded architecture is sometimes unavoidable. Imagine a message bus that receives data requests from a client. Hence it is completely up to system resources whether that request arrives on the same thread as the Reuters API has been initialized on or not, causing tons of issues. We have both gone through multiple posts and requests in case you remember. Finally someone helped me "fix the code" via a dedicated background thread on which a dispatcher is initialized and run. This fixed the problem when running the instance on a console app (non WPF UI thread), but does not work now on WPF. Nor does it work when working with real time data.
I think I am not alone in saying that we EAGERLY await the release the Rest API that you have been promising. Do you have any update on when this will be the case?
