Hi Takashi,
On Mon, 2018-09-03 at 10:24 +0900, Takashi Sakamoto wrote:
Hi,
On Sep 1 2018 08:18, Guedes, Andre wrote:
I have another concern of buffering in a perspectives of delay of task scheduling.
The interval of task scheduling for this plugin is decided mainly by the value of 'frames_per_pkt', given by users. In your documentation, the value is 6[1]. Of cource this is an example but in this case the interval is calculated as 125us at 48.0kHz. In my opinion, task scheduling in Linux kernel brings deadline misses for the interval, in most cases such as major Linux distribution on usual personal computers. When considering about the fact that recent motherboards implements Intel I210/220 series, it's better to care for the low- level realtime systems, in my opinion.
Agreed.
To mitigate this scheduling issue, a follow-up patchset will extend the plugin to leverage the ETF qdisc [1] which will be available on next kernel release. The idea is: instead of sending one AVTP packet at every interval, the plugin will send several AVTP packets at once, configuring their Tx time accordingly, so it can "sleep" for longer periods of time. The goal is to ease on task scheduling by offloading packet transmissions to the NIC.
A feature to queue packets with a transmission timing is mandatory for applications to implement this kind of time-awareness packet transmission protocol on general purpose operating system which has less guarantees of its real-time capability.
In a case of IEC 61882-1/6 on IEEE 1394 bus, controllers of 1394 OHCI[1] allows applications to queue several packets to corresponding isochronous cycle. As a result, the controller can transfer each packet at each isochronous cycle.
From my curiousity, would I ask you to explain about usage of the ETF 'qdisk' for this kind of applications?
That patchset introduces the SO_TXTIME sockopt which enables user-space applications to specify when a given packet should be transmitted. The ETF qdisc ensures that packets from multiple user-space applications are sent to the network controller in the right order (earlest txtime first). The controller then sends packets to the network at the txtime configured by the user.
In the AAF plugin case, it will prepare several AVTPDUs, configure their txtime so the transmission interval is respected, and offload them to the kernel/NIC.
How relevant hardware guarantees timing of transmission for queued packets?
In [1] you can find some performance measurements. The highlight is "Using so_txtime, the peak to peak jitter is about 100 nanoseconds, independent of the period."
Or network stack on Linux kernel govern the transmission timing in the proposed patchset?[2].
If the NIC doesn't support the scheduled transmission feature, yes, the kernel govern the transmission.
Hope this clarifies.
Regards,
Andre