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

mike.ford

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?

zoya faberov

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.