Hi @nikita.ou

The rmdstestclient tool is a highly performant one written using a low latency API UPA/ETA - that it is why we use it for our performance testing.

If rmdstestclient is connecting to the same ADS across the same network + route etc as the downstream consumer then you should not be seeing much difference in time of receipt - if anything I would expect the downstream application to potentially process the data slightly later - unless it is also written in our low latency API (most are not).

If you are seeing 2-5 secs delays that is concerning and you should investigate with your internal market data team / network team and our TREP or Elektron Realtime support teams.

However, the apparent delay could be because you receive an Update which contains a field that has not actually changed since the previous update but has been included in the update for whatever reason. So, it may be that you had BID_TIME in a previous update a 2-3 seconds ago and the field + value is repeated in the most recent update even though it has not changed. Whilst the Elektron feed does generally not include an FID in an update unless it has changed there may be situations where this can happen.

When you are testing please log all the timestamps and when you do see a delay compare the value with previous values - to confirm it is indeed a unique field update. This data could also come in useful if you do need to investigate further with our support teams.

Hi @nikita.ou

Not a TREP expert but I know that the TREP Performance documents explain their test methodology in considerable detail.

One example is the TREP 3.0.2 Performance results document e.g. a small extract:

For throughput testing, the sink_driven_src utility was used to generate update traffic, and the rmdstestclient utility was used to consume the updates....... The infrastructure was tuned for low latency and the publisher embeds timestamps into selected updates, which the subscriber uses for latency calculations. In this scenario, the publisher and subscriber must be running on the same node for accurate timestamps.

As you will note, having the consumer and provider on the same box ensures the timestamps are in sync.

You will need to create a MyRefinitiv login in order to download the above document.

UPDATE: There is also a link for a more recent Performance Document for the test done on more recent hardware.

Ji @nikita.ou

Apologies if I misunderstood your requirement. My take was that you were trying to measure the latency introduced by your TREP infrastructure as a tick traverses across the system - from the moment it is pushed out of the Elektron device to when it reaches the consumer. Using the method described above would have allowed publishing of dummy RICS with an embeded timestamp. By having the sink_driven_src(publisher) and rmdstestclient(consumer) on the same physical device you can ensure the time delta calculations are valid and not affected by clock differences between two devices.

If however, you are talking of the latency from when an exchange publishes an update to when it is received by a consumer at your site - IMHO there are too many other factors at play to arrive at a truly accurate latency measurement.

Please provide more details about exactly which latency measurement you are trying to calculate i.e from which start point to which endpoint.

However, assuming, you do wish to obtain some indicative or relative value, then a field such as BID_TIME would not be very accurate. You would be better off using an _MS or _NS field such as TIMACT_NS, BID_TIM_NS, QOUTIM_NS etc. which provide millisecond/nanosecond accuracy. However, these are not available for all RICs / exchanges etc.

You say you don't see the same result as what the downstream application sees. Is your rmdstestclient instance running on the same server as the downstream application? Does rmdstestclient show a greater latency that the other application or smaller latency? Please expand.