Rationale for revision
With reference to the following parameter to be used in the TSN time aware shaping (802.1 Qbv), the provided granularity does not seem to be good enough. For example, if I have 3.2ns (10G MAC with 32b datapath), I can represent the value using tenths of nanoseconds as 32, which is an integer: so, no problem. However, I can have a period which is 2.56ns (64b datapath, 25G MAC), which using tenths of nanoseconds will come to 25.6 and thus I can only represent 25 in the TickGranularity but not 25.6 ns , thus losing 0.6ns of granularity which is vital over the gating schedule of a few seconds. Please correct me if my interpretation is wrong. To make it future proof, I prefer the following. This helps me to solve the practical problems we might face while implementing the TSN in 25G MAC or future TSN MACs at higher throughputs. Two registers: TickGranulariyScale: Integer representing the scale of the granularity (ones, tenths, hundredths, thousandths etc) TickGranularity: Value represented by the above scale Let us take the following practical case: The idea is to arrive at the schedule where each gate is a common multiple of all the ports' ticks. Otherwise, the gate timing is not counted correctly in all the MAC ports, leaving some remainder leading to the drift in the gate timing on absolute timescale. If the application cannot read the MAC tick with a proper resolution, schedule calcuation will have considerable precision error. Consider 3 ports: 1G (MAC1 tick: 8ns), 10G (MAC2 tick: 3.2ns) & 25G (MAC3 tick: 2.56 ns) Through one-tenths resolution, the 'TickGranularity' specifies 80, 32 & 25 (cannot specify 25.6 in one-tenths. So, I lose the precision of 0.6) in one-tenths resolution. The application will configure the gate schedule with common multiple of (80, 32, 25): 800ns as the basic unit. Through one-hundreth resolution (with suggested register ' TickGranularityScale'), we can specifiy 800, 320, 256. Now, the application will configure the gate schedule with common multiple of (800, 320, 256): 6400ns as the basic unit, which is more approriate as the gate counting is an integer multiple of MAC ticks. It is quite possible that the same 25G MAC may have different ticks such as 2.56ns (64b) or 5.12ns (128b) depedning on the datapath widths. Also, some MACs such as 40G/100G may have 3 decimal MAC ticks depending on the datapath widths. If the schedules' internal gate timers need to work in proper synchronization with the MAC ticks (because there is no 1ns tick, which is why we have TickGranularity in the first place as explained in the Note of the clause 220.127.116.11.16), specifying the granularity along with its scale will make the original intent time-proof i.e., we donot need to change anything any time. I hope that our practical need of the additional regiter ' TickGranularityScale' is justified.
In clause 18.104.22.168.16: *** Original text: NOTE-While the state machine is documented on the basis of a nanosecond clock 'tick,' it is anticipated that real implementations will use a wide variety of clocks that differ in frequency accuracy and granularity. Hence, the management parameters specified in 12.29 allow a management station to discover the characteristics of an implementation's cycle timer clock (TickGranularity) and to set the parameters for the gating cycle accordingly. Modified text: NOTE-While the state machine is documented on the basis of a nanosecond clock 'tick,' it is anticipated that real implementations will use a wide variety of clocks that differ in frequency accuracy and granularity. Hence, the management parameters specified in 12.29 allow a management station to discover the characteristics of an implementation's cycle timer clock (TickGranularity expressed in the scale represented by TickGranulariyScale) and to set the parameters for the gating cycle accordingly. *** Also, Table 12-28 & 17-28 need to be updated with 'TickGranulariyScale' The object Ieee8021STParametersEntry needs to be updated with 'TickGranulariyScale' A new object ieee8021STTickGranularityScale needs to be defined. The object group 'ieee8021STObjectsGroup' needs to be updated with 'ieee8021STTickGranularityScale'.
Impact on existing networks
We can let the application know the exact MAC clock frequency of operation so that the overall shaper schedule across the ports can be designed with least precision impact.
|Affiliation:||Intel (Programmable Solutions Group)|