Using rtiddsping

6 posts / 0 new
Last post
Offline
Last seen: 10 years 4 months ago
Joined: 02/05/2013
Posts: 16
Using rtiddsping

Hello-

I am attempting to use rtiddsping to diagnose an issue in communications where publication occurs on a VxWorks box and subscription occurs on a Windows machine.

To learn the tool, I’m presently just running some tests across two Windows machines.

Rtiddsping offers the command line options “typeName” and “topicName”.  It appears that this could allow me to substitute the default NddsPingData type (which consists of a single long) with my own type.  I’ve tried this by defining a new type in XML but it seems the only change is to the name of the topic and the name of the type.  I’ve verified rtiddsping is reading the correct USER_QOS_PROFILES.xml file containing the type definition.

I’d like to use rtiddsping to send a buffer of data and experiment with QoS settings as I increase the size of that data.

Can you elaborate on these two options to rtiddsping?  Can rtiddsping be used with a type of my own?

Thanks-
Todd

Offline
Last seen: 10 years 4 months ago
Joined: 02/05/2013
Posts: 16

After looking at this further, I understand it is non-sensical to expect rtiddsping to access members of a new user-provided type.  That said, can you still comment on the purpose of the typeName & topicName options?

Thanks- Todd

Gerardo Pardo's picture
Offline
Last seen: 17 hours 41 min ago
Joined: 06/02/2010
Posts: 601

Hi Todd

The purpose of allowing the configuration of the typeName and topicName is to provide flexibility in setting up less trivial scenarios. Say you wanted to setup a situation where one rtiddsping application is sending data to 2 subscribes and a separate rtiddsping publisher sends data to 3 rtiddsping subscribers. Using the -topicName  you can make each rtiddsping pubisher send data on a different TopicName and hence communicate only with the rtiddsping subscribers that use that same TopicName.  

This helps also test configurations of RTI technologies like the RTI Routing Service, the Recording Service, etc.

We also allow setting dfferent TypeNames as a way to test out scenarios where the TypeName affects the processing of the data. For example a RTI Routing Service can have routes configured to forward data based on the TypeName or a regular expression on the type name, etc.

That said, the 'scenario' creation capabilities of rtiddsping are quite limited. You cannot configure the schema of the data published or the values, or  publish more than one Topic, etc. etc. riddsping is really suited for very simple tests...

If what you want is to set up more complex scenarions and control the schema of the data publish, the number of topics, DataWriters and DataReaders, their QoS, the content of the data, or subscribe to multiple topics, or a mix, etc. We do provide a different tool called rtiddsprototyper which does all this and might fit what you are looking for. It is bundled with the regular RTI DDS distribution and can be found in the same directory as rtiddsping. Here is a quote from the RTI DDS Prototyper Getting Started Guide:

RTI Connext Prototyper is a tool to accelerate RTI Connext DDS application development and scenario testing. It provides RTI Connext DDS application developers with a quick and easy-to-use mechanism to try out realistic scenarios on their own computer systems and networks, and get immediate information on the expected performance, resource usage, and behavior of their system.

With the traditional approach, if you want to try a specific DDS distributed application design and determine Key Performance Indicators (KPIs), you would have to spend significant time and effort to develop a custom prototype that could determine KPIs such as:

  • The memory a particular application is likely to use.
  • The time it will take for discovery to complete.
  • The system bandwidth the running application will consume.
  • The CPU usage it will take for a particular application to publish its data at a certain rate, or to receive a certain set of Topics.
  • The impact of changing data types, topics, Quality of Service, and other design parameters.

RTI DDS Prototyper significantly simplifies this process. Instead of writing custom code, you can:

  1. Describe the system in an XML file (or files),
  2. Run RTI DDS Prototyper on each computer, specifying the particular configuration for that computer, and
  3. Observe the behavior of the running system and read the KPIs from the RTI Monitor tool.

Regards,

Gerardo

 

Offline
Last seen: 10 years 4 months ago
Joined: 02/05/2013
Posts: 16

Thanks for your quick response, Gerardo.

I had forgotten about that tool.

I read through the Prototyper manual and tested it out.  The scenario I am trying to test involves transmitting large reliable data.  I am able to model this well using Prototyper.  The only issue is that the subscriber side attempts to dump the received data to the console.  I'm starting with an array of ~500KB might so this subscriber handling isn't going to work for me.

I will write a simple test outside of prototyper.

As feedback, ultimately I'd love to see an echo test with a configurable payload size and record of round-trip times.  This is almost rtiddsping and almost prototyper.

Thanks!

-Todd

Gerardo Pardo's picture
Offline
Last seen: 17 hours 41 min ago
Joined: 06/02/2010
Posts: 601

 Hi Todd,

Do you need this only in Windows?  We are working on some enhancements to rtiprototyper with scriptiing capabilities allowing you to handle the received data differently and examine it without necessarily printing to the console...  This will not be ready for a couple of months but we may be able to get you setup with some "experimental"  version as long as you only need it in a fairly standard platform and are willing to deal with experimental software...

As to the echo test. It is interesting. We had discussed internally in the past something that sounds similar.  The idea was to run N programs in different computers taht would ping each other and automatically report in a matrix the  matrix of latencies from each pair of computers.  Unfortunately we never had a good opportunity to resource this... But I am still hoping  we will get around to doing something like this soon... I think it is simple to do and would be quite useful...

Gerardo

 

Offline
Last seen: 10 years 4 months ago
Joined: 02/05/2013
Posts: 16

Gerardo-

To answer directly, we have immediate need for such tooling to help diagnose problems we are seeing.

The internal tool you've considered does sound interesting though its perhaps more then we need ourselves currently.  The problem we are having is specific to playing with QoS around reliable delivery of large data.  Just having a "datasize" option to rtiddsping would suffice.  I don't even care about it being my data structure.

The problems we are seeing are specific only to publishing from a VxWorks platform.  This is not a simple & standard platform.  That said, if your experimental prototyper can run on Windows and subscribe to publications from a non-experimental prototyper on VxWorks (which I expect it probably could), then it would indeed be useful to us.

FYI, I've been working with Mark H for some other things and he is familiar with our project, as are others in your organization.

Thanks you for your prompt response.

-Todd