Documented how media and network payload is calculated#619
Conversation
Signed-off-by: Sithideth Viengkhou (Riedel) <sithideth.viengkhou@riedel.net>
| $$ | ||
|
|
||
| Equivalent integer form used in MXL implementation: | ||
| - `v210LineBytes = ((w + 47) / 48) * 128` |
There was a problem hiding this comment.
@mlefebvre1 It's per line, so I think the original is correct.
| - `frame_width = 1920` | ||
| - `frame_height = 1080` | ||
| - `frame_rate = 25` | ||
| - `mtu = 1400` (transport assumption used in this document) |
There was a problem hiding this comment.
for RoCEv2 it should be one of 1024,2048 or 4096
same comment for all other examples
| - `providerWireOverheadBytes = 82` | ||
|
|
||
| Provenance of `providerWireOverheadBytes`: | ||
| - This constant is a modeled, per-packet on-wire cost for the `rdma_rocev2` provider profile. |
There was a problem hiding this comment.
We are not talking about provider profiles anywhere else. So maybe we could reword this to a more informal:
| - This constant is a modeled, per-packet on-wire cost for the `rdma_rocev2` provider profile. | |
| - This constant is a modeled, per-packet on-wire cost for the verbs provider using RoCEv2. |
| Interpretation: | ||
| - Use `providerMtuOverheadBytes` to compute payload capacity per packet (`mtu - overhead`). | ||
| - Use `providerWireOverheadBytes` to compute true wire-rate amplification (`packetsPerSecond * overhead`). | ||
| - Keeping both constants separate avoids mixing MTU-budget math and on-wire transmission-time math. |
There was a problem hiding this comment.
I think this remark is not really necessary 😄
| --- | ||
|
|
||
| ## Practical Notes | ||
| - For audio, wire bandwidth is ptime-sensitive because packet count and per-packet overhead change with ptime, even when raw media byte rate is constant. |
There was a problem hiding this comment.
We should explain what ptime means in our context (I guess you mean the commit batch size?), because ptime sounds a lot like PTP, but it has nothing to do with that.
There was a problem hiding this comment.
how about 'a audio grain duration is the semantical equivalent to what 2110 refers as ptime'?
There was a problem hiding this comment.
Maybe you could add "packet time", just to clarify: 'a audio grain duration is the semantical equivalent to what 2110 refers as ptime (packet time)'.
Signed-off-by: Sithideth Viengkhou (Riedel) <sithideth.viengkhou@riedel.net>
4 participants
Details
Documented how media and network payload is calculated.
Separation of Media and Network overhead
Initially addresses RoCE/RDMA
Example:
assume IPV4, No VLAN tagging
All numbers are appoximation
Backport requirements
Should be part of V1.1