61883-6 audio packet size in simple_talker

[srinivasbanoth]

Hi,
In simple_talker example we see PKT_SZ as 100 which does not include CRC. But from this document (http://avnu.org/wp-content/uploads/2014/05/AVnu-AAA2C_Audio-Video-Transport-Protocol-AVTP_Dave-Olsen.pdf page 20) the PKT_SZ should be 98+4(CRC) i.e 102.
please may I know why the PKT_SZ taken as 100 in simple_talker instead of 102?

[pinealservo]

I'm not sure why it's 100 instead of 98 or 102. Are you experiencing any problems?

[Shrikant-M]

When packet size is set to 100, simple_talker is trasmitting 8000 frames in 1.016 seconds due to which we see audio underruns at the listener. But when we set packet size to 102, we see 8000 frames transmitted in 1 second and listener plays audio smoothly. So we wanted to know why in simple_talker the packet size is set to 100?

[pinealservo]

It is probably a bug, although I am not quite sure yet exactly which point the bug is at. PKT_SZ is used to both configure the hardware traffic shaper (this is most likely what caused your issue) and to define the size of buffers. I would have to look more deeply into the code to see whether both the traffic shaper configuration and the packet size are too small, or whether it's just a case of the arithmetic on the PKT_SZ to get the shaper config parameter being off.

Either way, if you would be willing to look into this in more detail and make a pull request that improves the way things are calculated, we'd be grateful for the contribution. Otherwise, I'll mark this as a bug and we'll look into it further as time allows.

[eric-mann]

what doesn't make sense is the assertion a bigger packet (102 bytes) results in a higher packet rate (?). Unless its some floating point to integer rounding issue.

[pinealservo]

Here's the relevant code that seems to cause that effect:

igb_set_class_bandwidth
        (&igb_dev, 125000/L2_PACKET_IPG, 0, PKT_SZ - 22, 0);

A bigger PKT_SZ results in a larger bandwidth allocation. If everything were correct, the actual frame size and bandwidth allocation would track one another and it wouldn't change anything, but somehow they're not.

For further reference, here's how the length gets set in the descriptor:

packet_size = PKT_SZ;

And later:

a_packet.len = packet_size;

Maybe there's not enough room in packet_size to hold the full CRC (I think it's 2 bytes short?), but the bandwidth calculation assumes it includes the full CRC, and the hardware tacks it on as it goes out? I'm not sure how the i210 works in this respect; does it write the CRC in at the end of the buffer and then write the buffer to the queue, or does it get generated in the hardware frame queue after the frame data is copied there? Maybe the hardware tacks it on and copies as much as there's room for back into the source buffer?

I haven't looked at the i210 manual yet, so that's all just speculation, but there's definitely something odd going on in the reported behavior.

[Shrikant-M]

As per the explanation from the issue(#216), we feel that it is most likely a bug in simple_talker. simple_talker is subtracting 22 bytes from PKT_SZ(100) without including CRC for bandwidth allocation

[MarcinMiklas]

I experienced similar issue when testing multichannel audio with avtp_pipeline. I had to add 1 to the packet size to get proper bandwidth reserved. Otherwise I get audio gaps on listener (audio underruns probably).

The issue is observed on two different AVB listeners. The listeners have different hardware, none is running Linux nor OpenAVB, just custom AVB implementation running in RTOS.

avtp_pipeline is using different igb_set_class_bandwidth2 for bandwidth reservation, but I made a test changing it to use igb_set_class_bandwidth and the effect is the same.

Probably some floating point calculations made in libigb are wrong. Unfortunately I don't have a time to check libigb implementation against i210 reference manual.

I use launchtime feature in my tests (see: #508), talker is gPTP grandmaster.

[MarcinMiklas]

I forgot to mention in previous comment that link speed is 100 Mbit/s.

More than year ago in the issue #183 about totally broken reservation for 100 Mbit/s link speed.
The big issue was fixed that time.

But during testing of that issue I also noticed that size of packet passed to igb_set_class_bandwidth must be increased to get precise 8000 packets per second. It seems that the issue is still there.

[eric-mann]

So at 100Mbps the reservation calculation is off by 1 byte (?). Or at 1Gbps too?

[MarcinMiklas]

I only noticed this problem on 100 Mbps, but I'm not testing 1Gbps scenario often.

Recently it was discovered when testing mutlichannel audio. For 24 channels it was working ok, without need to add +1 to size of packet. But for 44 channels and 12 channels I needed to add 1.

Devices handling 24, 44 and 12 channels are completely different (hardwarewise and softwarewise) so maybe for 24 channels the issue is there, but device is able to handle that situation somehow.

[intel-ethernet]

… hmmm … is this thru an AVB switch? isn’t there a requirement to allocate +1 byte on the MaxFrameSize TSpec parameter on SRP streams thru a switch (?). Looking through 802.1Q-2014 isn’t producing a hit, but I remember a lot of discussions in AVnu about it …

[jdkoftinoff]

In IEEE Std 802.1Q-2014 clause 35.2.4.2:
….
The totalFrameSize for a stream on an outbound Port is therefore the sum of the following three amounts (doubled if each frame is transmitted on the media twice):

a) MaxFrameSize (35.2.2.8.4(a));

b) perFrameOverhead (34.4) associated with the media attached to the port;

c) one (1) additional octet to account for slight differences (up to 200 ppm) in the class measurement interval between neighboring devices.

….

BTW, please note that no device should EVER rely on the bandwidth reservation / FQTSS to be the functionality to pace the transmit messages. This additional one octet is added in order for the bandwidth reservations to work across multiple switches even when their measurement interval has inaccuracies (these switches are not time aware, just participating in time sync protocol).

The pacing of your packets is normally based on your media’s clock rates. i.e.: For example, send 6 samples @ 48 kHz every time you have 6 samples available to be packetized and sent. The extra octet added to the bandwidth calculations compensates for not only the different clocks in the different switches, but also for your media clock being +/- 100ppm. You can calculate the extra bandwidth available via my AVB Bandwidth Calculator. For instance, one stream with one channel @ 48 kHz IEC 61883-6 AM824 format (click calculate on https://abc.statusbar.com/ https://abc.statusbar.com/ ) The "Largest Octets per frame (inc. all overhead)” field comes out to 103. This includes the extra octet. 1 / 102 = 9,800 PPM. so we have loads of budget for faster/slower 48 kHz media clocks.

Another option for a Talker that transmits multiple streams in different media clock domains via subtype 0 IEC 61883-6 AM824 format - in that case it may make sense to send each stream’s packet every 125 microseconds but then send either 5, 6, or 7 samples per packet depending on how many samples were collected at that point. This allows you to decouple the packet transmission schedule and class based traffic shaping from the various different media clocks. Most devices don’t need to do this fancy multi-media clock functionality.

Regards,
Jeff

On Nov 7, 2016, at 11:20, intel-ethernet [email protected] wrote:

… hmmm … is this thru an AVB switch? isn’t there a requirement to allocate +1 byte on the MaxFrameSize TSpec parameter on SRP streams thru a switch (?). Looking through 802.1Q-2014 isn’t producing a hit, but I remember a lot of discussions in AVnu about it …

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #492 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAMgDd0HjBMNFqrX-d6C4DdRmELfvcLnks5q73nsgaJpZM4KPnpw.

[jdkoftinoff]

Oh, to also clarify: The two options I posted below are known as “Non Blocking, Synchronous packetization” vs “Non Blocking, Asynchronous packetization”. Synchronous packetization in my example would be always 6 samples, and then would have a total packet overhead of 99 octet times, including the extra octet. Asynchronous packetization requires bandwidth allocation for a 7th sample, hence the 103 octet times needed. The bandwidth allocation difference between async and sync totally depends on the number of channels in the ethernet frame.

On Nov 7, 2016, at 18:33, Jeff Koftinoff [email protected] wrote:

In IEEE Std 802.1Q-2014 clause 35.2.4.2:
….
The totalFrameSize for a stream on an outbound Port is therefore the sum of the following three amounts (doubled if each frame is transmitted on the media twice):

a) MaxFrameSize (35.2.2.8.4(a));

b) perFrameOverhead (34.4) associated with the media attached to the port;

c) one (1) additional octet to account for slight differences (up to 200 ppm) in the class measurement interval between neighboring devices.

….

BTW, please note that no device should EVER rely on the bandwidth reservation / FQTSS to be the functionality to pace the transmit messages. This additional one octet is added in order for the bandwidth reservations to work across multiple switches even when their measurement interval has inaccuracies (these switches are not time aware, just participating in time sync protocol).

The pacing of your packets is normally based on your media’s clock rates. i.e.: For example, send 6 samples @ 48 kHz every time you have 6 samples available to be packetized and sent. The extra octet added to the bandwidth calculations compensates for not only the different clocks in the different switches, but also for your media clock being +/- 100ppm. You can calculate the extra bandwidth available via my AVB Bandwidth Calculator. For instance, one stream with one channel @ 48 kHz IEC 61883-6 AM824 format (click calculate on https://abc.statusbar.com/ https://abc.statusbar.com/ ) The "Largest Octets per frame (inc. all overhead)” field comes out to 103. This includes the extra octet. 1 / 102 = 9,800 PPM. so we have loads of budget for faster/slower 48 kHz media clocks.

Another option for a Talker that transmits multiple streams in different media clock domains via subtype 0 IEC 61883-6 AM824 format - in that case it may make sense to send each stream’s packet every 125 microseconds but then send either 5, 6, or 7 samples per packet depending on how many samples were collected at that point. This allows you to decouple the packet transmission schedule and class based traffic shaping from the various different media clocks. Most devices don’t need to do this fancy multi-media clock functionality.

Regards,
Jeff

On Nov 7, 2016, at 11:20, intel-ethernet <[email protected] mailto:[email protected]> wrote:

… hmmm … is this thru an AVB switch? isn’t there a requirement to allocate +1 byte on the MaxFrameSize TSpec parameter on SRP streams thru a switch (?). Looking through 802.1Q-2014 isn’t producing a hit, but I remember a lot of discussions in AVnu about it …

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #492 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAMgDd0HjBMNFqrX-d6C4DdRmELfvcLnks5q73nsgaJpZM4KPnpw.

[MarcinMiklas]

Two devices are connected directly without switch. I'm just playing WAV file and using igb launch time feature, so media clock is not an issue.

If there is a good justification for adding 1 to MaxFrameSize I will just create patch for avtp_pipeline.

---

From: intel-ethernet [email protected]
Sent: 07 November 2016 20:20
To: AVnu/Open-AVB
Cc: Miklas, Marcin; Comment
Subject: Re: [AVnu/Open-AVB] 61883-6 audio packet size in simple_talker (#492)

... hmmm ... is this thru an AVB switch? isn't there a requirement to allocate +1 byte on the MaxFrameSize TSpec parameter on SRP streams thru a switch (?). Looking through 802.1Q-2014 isn't producing a hit, but I remember a lot of discussions in AVnu about it ...

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/492#issuecomment-258934514, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AM9TGgpOxqHb7Tj7gnfvPutJ-9g25vxvks5q73nvgaJpZM4KPnpw.