Le 17/06/2020 à 09:25, Peter Wong a écrit :
I think of 2 benefit by running tsn over rtnet + xenomai network driver
* better performance since xenomai delivering stringent real-time
guarantee and rtnet is smaller network stack
* xenomai rt application can run on tsn network
Is that right?
From my experience : The answer is no.
The kernel network stack has been rewritten in order being efficient to
achieve these tasks.
Furthermore , thanks to the way TSN (or ethercat) protocol works you
don't need a very hard realtime OS, allowing a bigger jitter for the RT
task using the network.
This is up to the nic hardware component to send the frame at the
programmed time . The only RT task requirement is that it should have
provided the frame to the nic interfaces before the next clock sync occurs.
Regards,
S.Ancelot
------------------------------------------------------------------------
*From:* Meng, Fino <fino.m...@intel.com>
*Sent:* Wednesday, June 17, 2020 2:08 PM
*To:* Jan Kiszka <jan.kis...@siemens.com>; Peter Wong
<tsnu...@outlook.com>; Lange Norbert <norbert.la...@andritz.com>;
Stéphane Ancelot <sance...@numalliance.com>; Xenomai
(xenomai@xenomai.org) <xenomai@xenomai.org>; Pirou, Florent
<florent.pi...@intel.com>; Gong, Xiaoyan <xiaoyan.g...@intel.com>; Pu,
Yanfeng <yanfeng...@intel.com>; Zhang, Wei E <wei.e.zh...@intel.com>
*Subject:* RE: TSN support on xenomai
>Sent: Tuesday, June 16, 2020 10:39 PM
>
>On 16.06.20 16:00, Peter Wong wrote:
>> Can we compile linuxptp (cobalt POSIX wrap) to run on RTnet + Xenomai
>> I210 driver so that we only need one NIC to run TSN on RTnet?
>>
>
>There is nothing like that upstream so far. Maybe Fino or Florent
>already have some plans, though I expect them to target newer hardware.
>
>Jan
We are working on TSN over Xenomai/Cobalt.
For example, have tested such simple case:
The synchronizing NIC is inside Linux domain, the TSN stack on vanilla
kernel,
Cobalt Thread share data to Linux thread first, then send out through
TSN stack,
Cyclic is 250us, 802.1Qbv enabled, single way, 5 minutes,
with some stress-ng workload and 100M noise traffic,
test result is identical with preempt-rt Linux, although this case may not
match real world scenario.
Our current target is find a BKM, let Xenomai app can use the TSN stack,
so the synchronizing NIC is stay in vanilla kernel.
Let TSN & RTNet merge into one NIC is not in current plan. But if found
real world use case really need it, we would like to working on it,
BR fino
>
>>
------------------------------------------------------------------------
>> *From:* Xenomai <xenomai-boun...@xenomai.org> on behalf of Jan Kiszka
>> via Xenomai <xenomai@xenomai.org>
>> *Sent:* Tuesday, June 16, 2020 5:44 PM
>> *To:* Lange Norbert <norbert.la...@andritz.com>; Stéphane Ancelot
>> <sance...@numalliance.com>; Xenomai (xenomai@xenomai.org)
>> <xenomai@xenomai.org>
>> *Subject:* Re: TSN support on xenomai
>>
>> On 16.06.20 11:41, Lange Norbert wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Xenomai <xenomai-boun...@xenomai.org> On Behalf Of Jan Kiszka
>>>> via Xenomai
>>>> Sent: Dienstag, 16. Juni 2020 10:58
>>>> To: Stéphane Ancelot <sance...@numalliance.com>; xenomai@xenomai.org
>>>> Subject: Re: TSN support on xenomai
>>>>
>>>> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
>>>> ATTACHMENTS.
>>>>
>>>>
>>>> On 16.06.20 10:55, Stéphane Ancelot via Xenomai wrote:
>>>>> Hi,
>>>>>
>>>>> This is natively supported in standard linux kernel
>>>>>
>>>>
>>>> Right. What is missing it linking the Xenomai timebase with that
of the kernel
>>>> so that we would benefit from Linux doing the sync for us already.
>>>
>>> But that means you can't use the synchronizing NIC with RTNet /
Realtime traffic.
>>>
>>> Regarding linking timebases, it would help (for various things)
>>> If you could easily read those various timebases from the kernel.
The rest can happen in
>>> userspace.
>>>
>>> I actually have 3: Linux Monotonic, Xenomai Monotonic, and a PPS
synchronized IEEE1588 clock,
>>> Cant fold them into one but sometimes need to map between these.
>>> Solved this by letting the NIC read out all 3 and providing them
to (Xenomai) userspace.
>>>
>>> Better would be a shared mmap (with 2 or more buffers), so that
Linux tasks can asynchronously get that info too.
>>>
>>
>> Latest Intel hardware supports mapping for the PTP time to the system
>> time (tsc) natively. You only need to read out the conversion
factors in
>> the end. That's what we want to have as well.
>>
>> If using that will create a conflict with using the NIC for RT traffic?
>> Likely. But that needs to be sorted out in the future, not only on
Intel hw.
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux
>>
>
>--
>Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>Corporate Competence Center Embedded Linux
