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) ?
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.
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.
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).
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?
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.
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.
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
SupportBatchRequests Initial Open: Yes
SupportBatchRequests Reissue: Yes
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) ?
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.
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.