RTI Monitor not monitoring large messages

5 posts / 0 new
Last post
Offline
Last seen: 7 years 5 months ago
Joined: 10/21/2012
Posts: 18
RTI Monitor not monitoring large messages

Hello,

I am coming up to speed with the RTI Monitor tool and I am using it to monitor the performance of a couple of test applications; one publisher and one subscriber.

I've managed to get things to work. Kind of...

My problem is that the monitor application seems to provide no feedback at all when the size of data samples is more than about 8.5K.

Small data samples are detected fine, but once they grow past this limit, monitor reports no samples received by the subscriber, even though the subscriber is actually receiving the data.

Any ideas what is going on here?

Dallas

Organization:
Keywords:
Fernando Garcia's picture
Offline
Last seen: 4 months 1 week ago
Joined: 05/18/2011
Posts: 199

 

Hi Dallas,

In the RTI Monitor Getting Started Guide you can find a troubleshooting section that illustrates common problems using Monitor. One of them is not receiving monitoring data for entities when data is larger than what is supported by the default transport settings. 

In Monitor, transport settings and the maximum type-code serialized size are left at the default values. If you are not receiving monitoring data, maybe it's because there are inconsistent transport settings or inconsistent maximum type-code serialized size settings between Monitor and your application. You can change Monitor's QoS settings in <installation directory>/config/rtimonitor_qos_profiles.xml. There, you will find the type-code serialized size under participant_qos.resource_limits and transport settings under participant_qos.property.

Fernando.

Offline
Last seen: 7 years 5 months ago
Joined: 10/21/2012
Posts: 18

Thanks Fernando. 

That's useful information. I've now had a read about, and tinkered with the settings that the guide mentions but I'm not convinced that this is my problem. 

The type_code_max_serialised_length parameter limits the size of the type code, not the size of the user data in each sample. In my case, the type code is actually quite small, basically a dozen or so metadata fields (some long, some longlong, some float) followed by a sequence<char>. The sequence varies in size from sample to sample, but I would imagine that the size of the type code would not change.

The manual also mentions the possiblility of incompatible transport settings. But given that some data seems to be monitored OK, I can't see that this would be a problem either. 

When the two test applications run, all samples published are succesfully received by the subscriber. However, the Samples Received Counts/Bytes/Throughput values displayed by the RTI Monitor oscilate between sensible values and zero, depending on the size of the user data published. This oscillation takes place over several tens of seconds so I'm not looking at any sort of sampling error here either.

Any more ideas?

rose's picture
Offline
Last seen: 2 years 8 months ago
Joined: 08/22/2011
Posts: 148

Hello Dallas, 

I think the problem is with the data size, not the typecode size.

With reliable data that is larger than default transport settings (which are 9K by default, but you can increase these up to 64K), you are forced to use the asynchronous publisher to write data.  The Monitoring Library doesn't support gathering statistics for data that is sent asynchronously.

Thank you!

Rose

Offline
Last seen: 1 month 1 week ago
Joined: 09/23/2018
Posts: 62

[NOTE]

Version 5.3.0 has partial support for DataWriterProtocolStatus statistics when publishing asynchronously: 

(CORE-7658 Add support for subset of asynchronous publisher statistics)

pushed_sample_count
pushed_sample_count_change
pushed_sample_bytes
pushed_sample_bytes_change

pulled_sample_count
pulled_sample_count_change
pulled_sample_bytes
pulled_sample_bytes_change