Sequence number mismatch and time schedule is too fast

[KnutSchrader]

Running the test applications shows a lot of error messages like:
“dbc mismpatch: expected .., got ..”
Sequence number mismatch
The test app stopps after some seconds.

In addition the delta t of the class a audio / video stream have a much too small time.
Expected 125 or 250 ys . Wireshark shows: round about one microsend.

Setup:
Ptp4l and phy2sys
Two linux pcs with two i210 plugin cards
Fedora 30 with latest kernel: 5.1.11-300.fc30.x86_64

Test app: ieciidc-listener and – talker
Parameter –d 91:E0:F0:00:00:01
-i ens1
-m 2
-p 3

Full command line (run as root):
./ieciidc-listener -d 91:e0:f0:00:00:01 -i ens1 | gst-launch1-0 -e -q filesrc location=/dev/stdin ! tsdemux ! decodebin ! videoconvert ! autovideosink

[andrew-elder]

@KnutSchrader - exactly what test applications are you running?

I'm not sure that ptp4l has been tested with avtplib - anyone?

[KnutSchrader]

phc2sys, ptp4l on both targets
talker side:
gst-launch-1.0 -e -q vodeotestsrc pattern=ball ! x264enc ! mpegtsmux ! filesink location=/dev/stdout | ieciidc-talker -d 91:e0:f0:00:00:01 -i ens1 -m 2 -p 3
listener:
./ieciidc-listener -d 91:e0:f0:00:00:01 -i ens1 | gst-launch1-0 -e -q filesrc location=/dev/stdin ! tsdemux ! decodebin ! videoconvert ! autovideosink

[KnutSchrader]

in detail: linuxptp version 2.0

[craiggunther]

Quick question about your wireshark captures. Is it possible you have not disable interrupt coalescing (or moderation) on your wireshark capture Ethernet interface? That can cause some strange timestamping to occur, with bursts of packets, followed by a pause, followed by another burst. One way to do a quick check is to capture a couple of minutes of A/V packets, then divide the capture duration by the number of A/V packets and see if you come somewhere near the timing you expect. If so, you can look back through the trace and look for long pauses between the bursts as I have described. If you have this problem then look up wireshark and interrupt coalescing/moderation for you network interface and see how to turn it off. - Craig On Wednesday, June 19, 2019, 7:22:45 AM MDT, KnutSchrader <notifications@github.com> wrote: Running the test applications shows a lot of error messages like: “dbc mismpatch: expected .., got ..” Sequence number mismatch The test app stopps after some seconds. In addition the delta t of the class a audio / video stream have a much too small time. Expected 125 or 250 ys . Wireshark shows: round about one microsend. Setup: Ptp4l and phy2sys Two linux pcs with two i210 plugin cards Fedora 30 with latest kernel: 5.1.11-300.fc30.x86_64 Test app: ieciidc-listener and – talker Parameter –d 91:E0:F0:00:00:01 -i ens1 -m 2 -p 3 Full command line (run as root): ./ieciidc-listener -d 91:e0:f0:00:00:01 -i ens1 | gst-launch1-0 -e -q filesrc location=/dev/stdin ! tsdemux ! decodebin ! videoconvert ! autovideosink — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[KnutSchrader]

I have checked the coalescing. ethtool shows it is off (sender and receiver). I have checked the number of frames per second: there is a varation from (mostly) 2862 to 3599 packets. Whenever there are 1588 packets there is a "pause" of 70 or 80 milliseconds in between the "change" from a 1722 packet to a 1588 packet. And it seems that there are packets dropped, because of the "sequence mismatch" error output.

[aguedes]

Hi folks, sorry about the delay to jump into this. I was on vacations, and this discussion got buried in the tons of emails I had when I got back :)

The rationale behind the code provided in examples/ is more to show examples of how to use libavtp APIs than to be real-world AVTP applications. With that mindset, we kept the examples as simple as possible. For instance, talker examples don’t control the transmission time and this explains why the transmission deltas don't align with the SR Class streams as you verified.

That said, I think you'd be interested in knowing that GStreamer now features an AVTP plugin which can be leveraged to implement AVB applications. The plugin (which uses libavtp to handle packetization) implements several AVB functionalities, including transmission timing. You can find a step-by-step guide on how to use the GStreamer AVTP plugin in https://tsn.readthedocs.io/avb.html.

[aguedes]

Hi @KnutSchrader, I believe we addressed this issue so I'm closing it. Feel free to re-open it in case something is still not clear.