For a deeper look into our Elektron API, look into:

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
21 0 2 5

sink_driven_src -Q option replaying data from rmdstestclient with-m option

In the install manual for test tools in the sink_driven source section

-Q capt_datafile

"If you use –Q to play back market data, when running rmdstestclient you must use its –m option (for
prepending timestamps to log events)."

In the rmdstestclient -m is used to add timestamps to a log file, specified with the -l option which is not the file that is used as the input. https://developers.refinitiv.com/article/quick-start-guide-recording-and-playback-elektron-data. I can't understand why the -m option is needed when capturing data, how is this timestamp used.

The reason for asking is we are looking with sink_driven_src to vary the update rate for different subscription requests and can't see a way of doing this.
Is the rate at which sink_driven source fixed by command line arguments of -Q -M -D -T or -p for all subscriptions? I presume -p option is the same as just -Q when you don't want the rate to vary?

elektronrefinitiv-realtimeelektron-sdksink-driven-source
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

@mike.ford

Thank you for your participation in the forum. Are any of the replies below satisfactory in resolving your query? If yes please click the 'Accept' text next to the reply that best answers your question. This will guide all community members who have a similar question. Otherwise please post again offering further insight into your question.

Thanks,

-AHS

Upvotes
Accepted
32.2k 40 11 20

Hello @mike.ford,

Glad to share my understanding.

I use infra tools as developer, so my usage pattern and angle of understanding are slanted toward developer uses of the tools :) Market data engineers tend to use the infra tools wider.

There are two main modes of replaying test data:

1. Actual data that was recorded.

2. Generated test (made-up) data.

The first way is intended to be bale conduct end-to-end and sub-path infra latency testing. This is why timestamps need to be recorded with the messages.

---

Do not think you can vary update rate per subscription request.

---

The intended use, for limited performance testing, is to vary the update rates via -U, -D, -M and -T. Allowing to start replay at a low rate and gradually increase to higher replay rates.

I either do -p, for steady publish rate, or -U -D -M -T together, for increasing rate, depending on the use case.

---

-Q defines if you use recorded or generated data.


Hope this helps.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
79.2k 251 52 74

@mike.ford

Another option to replay recorded data is Replay Service from TradeWeb. I found that it has an option to replay with the original rate.

You can contact their Sales team for more information. The contact information is available on that page.


1595212928515.png (10.1 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.