* rtping differences between master and slaves @ 2018-11-23 10:51 Mauro Salvini 2018-11-23 11:49 ` Jan Kiszka 0 siblings, 1 reply; 5+ messages in thread From: Mauro Salvini @ 2018-11-23 10:51 UTC (permalink / raw) To: xenomai 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. Thanks in advance, regards Mauro ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: rtping differences between master and slaves 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 0 siblings, 1 reply; 5+ messages in thread From: Jan Kiszka @ 2018-11-23 11:49 UTC (permalink / raw) To: Mauro Salvini, xenomai 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. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: rtping differences between master and slaves 2018-11-23 11:49 ` Jan Kiszka @ 2018-11-23 12:49 ` Mauro Salvini 2018-11-23 12:55 ` Jan Kiszka 0 siblings, 1 reply; 5+ messages in thread From: Mauro Salvini @ 2018-11-23 12:49 UTC (permalink / raw) To: Jan Kiszka, xenomai 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? Thanks in advance, regards Mauro > > Jan > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: rtping differences between master and slaves 2018-11-23 12:49 ` Mauro Salvini @ 2018-11-23 12:55 ` Jan Kiszka 2018-11-23 13:21 ` Mauro Salvini 0 siblings, 1 reply; 5+ messages in thread From: Jan Kiszka @ 2018-11-23 12:55 UTC (permalink / raw) To: Mauro Salvini, xenomai 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. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: rtping differences between master and slaves 2018-11-23 12:55 ` Jan Kiszka @ 2018-11-23 13:21 ` Mauro Salvini 0 siblings, 0 replies; 5+ messages in thread From: Mauro Salvini @ 2018-11-23 13:21 UTC (permalink / raw) To: Jan Kiszka, xenomai 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-11-23 13:21 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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.