Jump to content
OpenSplice DDS Forum
nnnnn15

Roundtrip example - Vary number of publishers and subscribers?

Recommended Posts

I am in the middle of evaluating the full version of OpenSplice DDS.

Would running multiple instances of the ping and pong examples in the Round trip example constitute an efficient method to measure the Round-trip time for a varying number of publishers and subscribers?

For example, I would have 2 instances of pong (Publisher) running in 2 separate terminals and have 2 corresponding ping (subscriber) terminals to demonstrate the performance between 2 publishers and subscribers. I am not fully sure if this is a valid method of testing this sort of scenario.

If this is not suitable and there are no other facilities to test this type of experiment would writing my own modified versions of ping and pong be the best course of action?

Share this post


Link to post
Share on other sites

Hi,

Although the bundled throughput example is perfectly suitable to measure 1-to-n distribution (as you can start as many subscribers as you want), the roundtrip-example is currently 'crafted' to measure the roundtrip between 2 applications (ping and pong).

However as the used 'pattern' is that the 'ping' writes in the 'ping' (DDS_)partition and the 'pong' subsequently in the (DDS_)pong partition, you could easily add those partition-names to the command-line parameters as currently there's an 'initialize' routine that takes both partitions as a parameter:

int ping(int argc, char *argv[])
{
    unsigned long payloadSize = 0;
    unsigned long long numSamples = 0;
    unsigned long timeOut = 0;
    DDS_boolean pongRunning;
    struct timeval startTime;
    struct timeval time;
    struct timeval preWriteTime;
    struct timeval postWriteTime;
    struct timeval preTakeTime;
    struct timeval postTakeTime;
    struct timeval difference = {0, 0};
    DDS_Duration_t waitTimeout = {1, 0};
    unsigned long long i;
    unsigned long elapsed = 0;
    DDS_boolean invalid = FALSE;
    DDS_boolean warmUp = TRUE;

    /** Initialise entities */
    Entities e;
    initialise(&e, "ping", "pong"); // here you could apply the provided cmd-line parameters for the to-be-used-partitions

int pong(int argc, char *argv[])
{
    DDS_Duration_t waitTimeout = DDS_DURATION_INFINITE;
    unsigned int i;

    /** Initialise entities */
    Entities e;
    initialise(&e, "pong", "ping"); // here you could apply the provided cmd-line parameters for the to-be-used-partitions

    printf("Waiting for samples from ping to send back...\n");

By doing that you could even 'chain' multiple pong's where only the 'last' one in the chain sends its data back to the 'originating' Ping's read-partition.

Hope this helps .. 

Share this post


Link to post
Share on other sites

PS> as you'r using the 'full' evaluation version, you also have the bundled Tuner and Tester tools.

Using the Tester's browser you can easily see the used partitions by the 'ping' and 'pong' applications, here's a screenshot of both the Tester as well as the running ping/pong (on my windows-10 laptop exploiting 'single-process' execution-mode i.e. communicating over the loopback interface, noting that when I'd run that same test using 'federated deployment' the measured roundtrip-time would be only 22 us. or so as in that case shared-memory would be exploited rather than the loopback-interface :) ):

image.png

Share this post


Link to post
Share on other sites

Thank you for the helpful information.

However, I don't fully understand how you would stack the entities of ping and pong in the code example.

Would this mean you could add initial parameters such as "ping2" and "pong2" to indicate further partitions (pubs & subs) running on the example? 

I am currently trying to manipulate this example in java to have more instances than the initial 2 applications.

Apologies if I misunderstood a clear concept.

Share this post


Link to post
Share on other sites

To recap, my proposal was about chaining rather than 'stacking', so lets suppose we have 1 ping and 3 pongs: pong1, pong2, pong3

  • ping writes to 'ping' partition (by default)
  • pong1 reads from 'ping' partition: ínitialize ("pong1","ping")
  • pong1 writes to 'pong1' partition
  • pong2 reads from 'pong1' partition: initialize ("pong2","pong1")
  • pong2 writes to 'pong2' partition
  • pong3 reads from 'pong2' partition: initialize ("pong", "pong2")
  • pong3 writes to 'pong' partition
  • ping reads from 'pong' partition (by default )

So if you create a 'pong' version that takes the commandline-parameters to fill the 2 parameters of the ínitialize() procedure, you're all set and have created a chain ..

.. and of course, if you'd add the 2 partition-parameters also to the commandline of 'ping' you can create multiple pairs that each use 'their own 2 partitions' for pinging and ponging :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...