Recorder not recording everything

1 post / 0 new
Offline
Last seen: 1 month 3 weeks ago
Joined: 03/12/2018
Posts: 32
Recorder not recording everything

I'm running rtirecorder on a dedicated linux node while sending DDS traffic from another dedicated linux node.  I'm monitoring traffic with a PC running wireshark. 

Later, I analyze the sql recording on the recording system, and compare it to the wireshark trace, and I have determined that the recorder is not recording everything.  The data rate is about 50 MB/s, with a 50K packet travelling over DDS every millisecond.

What can I do to make the recorder not drop packets?

Background:

It seems like the traffic has some ebbs and flows, relatively speaking: On wireshark, I see consistent once-a-millisecond traffic for a few milliseconds, then a small delay of three milliseconds, followed by three or four packets within the same millisecond period.  I think this is where the recorder drops things.

When I run the data sender, I use a xml file that determines that the participant qos is using the Generic.StrictReliable.LowLatency builtin profile, with 16MB buffers:  "dds.UDPv4.builtin.send_socket_buffer_size=16777220" and "dds.UDPv4.builtin.recv_socket_buffer_size=16777220"

In this same xml clause, I've got a UDPv4 feature  "parent.message_size_max" value 65507.

The datawriter qos here has a feature I'm not sure about, max_blocking_time, set to 100000 nanoseconds.

On the recorder, there is a USER_QOS_PROFILES.xml in my current working directory when I run it.  I always run it with a recorder xml file that details recording features. 

When I run the recorder, I always get the following error

~/rtirecord -cfgFile RecorderConfig.xml.rx -cfgName DDSReceiverRecorder
...
exception:[RECORDERXmlManager_loadDefaultCfgFile@244]:Failed to find valid default configuration file
RTI Recorder started
Recording to file DDSReceiverRecording.dat_9_0

If it matters, the USER_QOS_PROFILES.xml file has the same descrition of the data as the sender, but there are some additional fields with my data type followed by ".Recorder" , which describe the reliability kind as DDS_BEST_EFFORT_RELIABILITY

Is this last reliability entry ordering the recorder to drop packets if necessary?

I'm assuming there is a buffer size knob somewhere that will increase the recorder's buffer size?  

FYI the network is not set up to use jumboframes. I understand this would help, but this particular adapter does not like having its MTU set to 9000, as I've done with other adapters in the past.  The error rate shoots up, and throughput slows way down.