All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Salvini <mauro.salvini@smigroup.net>
To: Jan Kiszka <jan.kiszka@siemens.com>, xenomai <xenomai@xenomai.org>
Subject: Re: rtping differences between master and slaves
Date: Fri, 23 Nov 2018 14:21:27 +0100	[thread overview]
Message-ID: <1542979287.2348.7.camel@smigroup.net> (raw)
In-Reply-To: <f4af8e4f-25fa-1845-1525-f5a0c76e00d9@siemens.com>

On Fri, 2018-11-23 at 13:55 +0100, Jan Kiszka wrote:
> On 23.11.18 13:49, Mauro Salvini wrote:
> > On Fri, 2018-11-23 at 12:49 +0100, Jan Kiszka wrote:
> > > On 23.11.18 11:51, Mauro Salvini via Xenomai wrote:
> > > > Hi all,
> > > > 
> > > > I'm trying RTNet (an old version: 0.9.13) on Xenomai (yet
> > > > another
> > > > old
> > > > version, 2.5.6: unluckily I cannot move to newer versions).
> > > > 
> > > > My setup has 3 identical nodes on isolated RT network: cycle
> > > > time
> > > > of
> > > > 5000us, master with slot offset 0, slave A with slot offset
> > > > 200us
> > > > and
> > > > slave B with slot offset 400us; network is configured using
> > > > rtnet
> > > > utility script.
> > > > 
> > > > Using rtping I observe two different behaviors on slaves and
> > > > master.
> > > > 
> > > > For example, pinging slave A from B:
> > > > 
> > > > ...
> > > > 64 bytes from 10.0.43.91: icmp_seq=1 time=7777.7 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=2 time=7846.3 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=3 time=7966.6 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=4 time=8096.6 us
> > > > ...
> > > > 64 bytes from 10.0.43.91: icmp_seq=15 time=9461.7 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=16 time=9604.2 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=17 time=4719.5 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=18 time=4844.7 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=19 time=4968.3 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=20 time=5124.4 us
> > > > ...
> > > > 64 bytes from 10.0.43.91: icmp_seq=53 time=9215.4 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=54 time=9331.5 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=55 time=9461.0 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=56 time=9585.3 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=57 time=4712.5 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=58 time=4847.0 us
> > > > 64 bytes from 10.0.43.91: icmp_seq=59 time=4967.2 us
> > > > ...
> > > > 
> > > > so time varies between a minimum equal to time distance between
> > > > two
> > > > slots and a maximum equal to this time plus cycle duration.
> > > > This
> > > > can
> > > > makes sense supposing that Linux timer used to generate ping
> > > > request in
> > > > rtping.c slowly drifts from real-time timer that governs tx
> > > > slot,
> > > > so
> > > > the duration changes between requests depending on when request
> > > > happens
> > > > into the TDMA cycle. Same behavior if I ping A from B or if I
> > > > ping
> > > > master from A or B.
> > > > 
> > > > On master I instead observe this (pinging slave A or B
> > > > equally):
> > > > 
> > > > ...
> > > > 64 bytes from 10.0.43.89: icmp_seq=1 time=2434.1 us
> > > > 64 bytes from 10.0.43.89: icmp_seq=2 time=2443.1 us
> > > > 64 bytes from 10.0.43.89: icmp_seq=3 time=2438.7 us
> > > > 64 bytes from 10.0.43.89: icmp_seq=4 time=2450.0 us
> > > > 64 bytes from 10.0.43.89: icmp_seq=5 time=2447.9 us
> > > > 64 bytes from 10.0.43.89: icmp_seq=6 time=2450.6 us
> > > > 64 bytes from 10.0.43.89: icmp_seq=7 time=2428.5 us
> > > > 64 bytes from 10.0.43.89: icmp_seq=8 time=2442.8 us
> > > > 64 bytes from 10.0.43.89: icmp_seq=9 time=2442.3 us
> > > > ...
> > > > 
> > > > ping duration is constant into a rtping execution (changes
> > > > between
> > > > different executions).
> > > > 
> > > > So I'm puzzling about this difference and I wonder if this is
> > > > normal or
> > > > if there could be problems.
> > > > 
> > > 
> > > As you are running RTmac/TDMA: The latency is affected by when
> > > during
> > > some cycle
> > > you issue the ICMP request. This is not synchronized with the
> > > cycle,
> > > so you will
> > > see random shifts there already. Furthermore, if station A has a
> > > time
> > > slot
> > > before station B and A issues the ping, B may have a change to
> > > reply
> > > in the same
> > > cycle. If you change roles, this is surely not possible, thus you
> > > get
> > > different
> > > round trip times.
> > 
> > Thank Jan for quick answer.
> > 
> > Yes, I understood your explanation, that perfectly clarify rtping
> > between A and B.
> > 
> > Instead, about the constant ping duration when master pings a
> > slave: is
> > due to the fact that on master ICMP requests are synchronized with
> > the
> > cycle?
> 
> I don't recall the details, but chances are high that, because the
> master drives 
> the TDMA cycle, its rtping loop happens to remain in sync with that
> cycle.

Ok, thank you very much Jan.

Regards.

Mauro



      reply	other threads:[~2018-11-23 13:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-23 10:51 rtping differences between master and slaves Mauro Salvini
2018-11-23 11:49 ` Jan Kiszka
2018-11-23 12:49   ` Mauro Salvini
2018-11-23 12:55     ` Jan Kiszka
2018-11-23 13:21       ` Mauro Salvini [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1542979287.2348.7.camel@smigroup.net \
    --to=mauro.salvini@smigroup.net \
    --cc=jan.kiszka@siemens.com \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.