Hello @duncan_kerr,

I would guess that the issue with replay has to do with how you record the data.

Let me include the command lines that work for me, hopefully, you will be able to use the same by adapting to your environment:

1. record_mbp.bat:

.\rmdsTestClient.exe -h myadshost -S ELEKTRON_EDGE –ct rssl -md 8 -f mbp_items.txt -dfile "C:\Program Files\Reuters\Elektron\Elektron-SDK\Ema\etc\RDMFieldDictionary" -m -X -v -of mbp_capture.txt -l mbp_capture.log

2. see the capture looks ok

3. replay_mbp.bat

.\sink_driven_src.exe -S ELEKTRON_EDGE -C 100000 -E rssl -N 14003 -U 1 -K -Q mbp_capture.txt

4. Consume MbP with test client ( in my case, port 14003 as to be distinct from other testing)

Zoya - my record command is:

rmdstestclient -S XXXX -f oslo.pp -h hostl -p 14002 -ct rssl -u ******* -rf 8 -I 1 -m -rbias 20 -I 1 -obf file.bin -md 7

when I replay that file & try to alter the replay speed I get a core dump from sink_driven_src. What I am trying to do is to record a L2 MBO and then replay it in a loop with a fixed replay rate. So the crash looks like this (note if I remove the -ipr 100 it stops core dumping):

# version

# ads3.4.0.L1.linux.tis.rrg/linux7_x86_64

sink_driven_src -S XXXX -v -U 1 -K -N 14002 -ik -bdf file.bin -ipr 100

Initialized RSSL library.

begin CPU time: 0.011497 sec user, 0.030660 sec system

Total number of messages processed: 980

end CPU time: 0.013251 sec user, 0.034454 sec system

.

Loaded pkts: 0 items: 44 images: 96 image_length: 0 unsol images: 0 updates: 875 update_length: 0 memory (MB): 0.565347

setup_updates: cfg_cfg_ticks_per_second=100 cfg_ticks_per_second=100 usec_per_tick=10000 updates_per_tick=0 extra_updates=1 max_updates_to_pack=10

Server fd=4: New client fd=5 newSession

Session 5 In Progress

sessionAct fd=5

RSSL Login Request from User : twsadmin

Sending Login Response

Sent Login Response Success

RSSL Source Directory request

SockOptions: TCP_NODELAY=0 SNDBUF=2626560 RCVBUF=1061488 bytes

UPA peer component version: 78fc1e330e6|78fc1e330e6

Sending Source Directory

Sent Source Directory

Received open request for TEL.NO|7 on streamId 8.

/users/is/dukerr/bin/rmdstest: line 153: 5215 Segmentation fault (core dumped) $TOOLS/sink_driven_src -S XXXX -v -U 1 -K -N 14002 -ik -bdf file.bin -ipr 100

Hi @duncan_kerr,

When you replay at one per second -U 1, it looks like your test subscriber is able to connect and see the updates?

Then you try to introduce -ipr and it crushes?

My understanding of Infra Tools is limited to common developer use cases, so let me explain as I understand it. There are two modes, we can either replay recordings, such as you were doing, or we can generate completely pre-determined bogus traffic. -ipr is for this second approach.

If you like to modify the rates while testing, I would test with -U -M -D and -T options, please see the the Infra Tools guide document.

---

I would like to add on the topic of performance testing, just in case it will be of help, that the primary intention of Infra Tools is infra verification, by market data engineers, operations, etc. For heavy performance testing, especially of level 2 data sets, it is not explicitely designed, and there is only so far that you can take infra tools in that direction. For many use cases it suffices.

If my guess is correct and you are looking to performance test, look at Perf tools that came with ESDK in Examples\PerfTools. That will take you much further, in terms of achievable publication rates, and there is code included and doc describing. If you are looking to take it even further then that, you may wish to look at ReplayService. That is a separate product designed for heavy performance testing and error condition testing.