SSL(MarketFeed) vs RSSL(OMM) message size reduction

NWM

Hello Team,

We currently have SSL(MarketFeed) consumer application on Linux developed using older version of RFA C++. Approximately real-time data for 50K~60K RICs are consumed/processed by the application. As the volumes have increased, we are seeing an increase in the peak utilization of the bandwidth b/w the application and ADS(Peak usage for few mins at various times of day is 600Mb~700Mb out of total bandwidth of 1G).

We are investigating the possibility of migrating to RSSL(OMM) to prevent hitting the max bandwidth usage.

--Are there any real stats available to show what is the reduction in message size of updates if using RSSL(OMM)?

--By how much can the bandwidth util be reduced with RSSL(OMM) ?

Thank you.

Regards

umer.nalla

Hi @NWM

I don't have any detailed charts I can share but as example below is a summary of monitoring bandwidth peaks over a 48hr period for the same data across SSL(MF) and RSSL(OMM) transport.

The above is a result of consuming a watchlist of instruments on ELEKTRON_DD using both an MF and OMM consumer for 48 hours and recording the peaks. The figures are in Mbps.

As you can see, for this particular watchlist, the OMM peak bandwidth used less than 20% of the MF peak bandwidth. Again, your savings may vary - based on your particular mix of instruments and their update msg sizes etc.

umer.nalla

Hi @NWM

Although the exact bandwidth reduction can vary depending on the nature of the data, figures are around 50% (or higher) reduction in typical image and update size for OMM compared to MF.

You can also typically expect 45% or higher increase in throughput based on the same hardware.

Gurpreet

In addition to the stats provided by Umer, you can configure the ADS to limit the number of fields being sent to your application by eliminating unused fields and reducing bandwidth (provided other apps are not consuming from that server as well).

NWM

@Umer, @Gurpreet

Thank you for the responses. As you mentioned, limiting the FID distribution at ADS side may be difficult due to other apps using the other FIDs.

Are there any reports with real numbers, charts demonstrating the comparison b/w SSL & RSSL that can be shared?

Also, are there any tools available that I can use to test / compare the SSL/RSSL message update size and throughput?

Thank you

Regards

Gurpreet

Hi @NWM, I don't have any tools ready, but you should be able to use one of the Elektron SDK consumer samples, to get an estimate of data requirements.

An OMM based application can utilize field filtering feature in ADS -- the app can request a "Dynamic View" specifying the list of fields in subscription request, thereby reducing the bandwidth on the fly.

There are gzip and LZ4 compression levels available in ADS, which can reduce bandwidth at an expense of CPU.

NWM

@Umer, @Gurpreet

Thanks a lot for your responses.

does 'rmdsdtestclient' tool has option to capture/monitor update rate in order to calculate the peak bandwidth usage?

Regards.

umer.nalla

Hi @NWM

rmdstestclient has multiple command line parameters including a few related to statistics.

For example the following will request the items specified in the file vodrics and output statistics every 1 second. The relevant parameter is '-I 1' - capital letter 'i' and 1 for the interval.

rmdstestclient -S ELEKTRON_DD -f vodrics -h ads1 -p 14002 -ct rssl -u umer.nalla -I 1  -l log.out

For further details on the above and other stats related parameters please refer to the documentation for rmdstestclient - online version can be found here.

NWM

Hi @Umer

Thank you for the example.

The output is something like below

UPA server component version: ads3.2.1.L1.linux.tis.rrg 64-bit
Setting rmds connection 0x1e1a370
Connection list count is 1
SupportStandby: 0
SupportBatchRequests Initial Open: Yes
SupportBatchRequests Reissue: Yes
SupportBatchClose: Yes
SupportViewRequests: Yes
SupportOptimizedPauseResume: 0
Received Field Dictionary refresh message (Data Length: 616032).
Received Enum Dictionary refresh message (Data Length: 120913).
updr 4.00 updl 82 imgr 5.00 imgl 1291
updr 2.00 updl 113 imgr 0.00 imgl 0
updr 4.00 updl 101 imgr 0.00 imgl 0
updr 1.00 updl 104 imgr 0.00 imgl 0
updr 5.00 updl 88 imgr 0.00 imgl 0
updr 3.00 updl 94 imgr 0.00 imgl 0
updr 1.00 updl 105 imgr 0.00 imgl 0
updr 9.00 updl 103 imgr 0.00 imgl 0
updr 22.00 updl 108 imgr 0.00 imgl 0
updr 8.00 updl 105 imgr 0.00 imgl 0
updr 18.00 updl 104 imgr 0.00 imgl 0
updr 113.00 updl 109 imgr 0.00 imgl 0
updr 16.00 updl 105 imgr 0.00 imgl 0
updr 5.00 updl 102 imgr 0.00 imgl 0

I suppose "updr" is update rate per second? And "updl" is the update message size (in bytes) ?

Thanks.

umer.nalla

Hi @NWM

According to the rmdstestclient documentation 'updr and imgr calculations are taken by dividing the updates received during the
display interval by the size of the interval. Results are then rounded up.'

I don't have any documentation on the the 'updl' value - but I expect it is also a similar averaged value for each update. The data size units are in bytes.

NWM

Hi @Umer,

Thank you for your responses for this case. Will check using rmdstestclient.

NWM

Hello @Umer,

The application is built with RFA C++ ver 6.4.0, using SSL/MF format.Compression (zlib/level 3) is enabled in ADS.

-Is compression supported at SSL/MF level in the RFA API?

-are there settings in RFA config file to ensure application requests compression data?Could not find compression related parameters in RFA development guide so please advise.

Thanks.

umer.nalla

Hi @NWM,

As per the RFA config guides, only RSSL type connections support compression.