[802.3_10SPE] [T1S-PREAMBLE] Comments on new preamble proposal
Hello 802.3cg Task Force,Hopefully this mail could be a starting point for a discussion. Thanks both Mr. Cordaro and Mr. Zerna for their contribution on this topic.
1. About the Problem
Honestly I'm not convinced that we really have a problem with current proposal, so I've made a simple model to estimate the effect of preamble robustness on the PHY perfromance.
- I assume the effective BER, that is the chance of mis-decoding a bit, to be proportional to the environmental noise.
- If any bit error occurs during data reception, the entire packet is discarded (wrong CRC), despite the preamble synchronization method used.
- If any bit error occurs during preamble detection, there's a chance the packet is not detected (lost) depending on synchronization method.
> for the sake of simplicity I assume that in current proposal any bit error in the preamble causes the packet to be lost (in reality we can actually withstand some errors during the first two 'J' symbols)
> I also assume the new proposed method to have 100% chance to properly synchronize, i.e. any bit error in the preamble never results in the packet to be lost
- With these assumptions, the chance for a packet to be discarded (PER) is 1 - (1 - BER)^N where N is the number of bits being transmitted
> For the current proposal, N is the total number of bits in a packet including the 64 bit preamble
> For the new preamble proposal, N is the the number of bits in a packet, excluding the preamble (because, as said, It is assumed not to cause a packet to be lost).
- The effective improvement yielded by the new preamble proposal can be estimated as the difference in PER between the two cases as a function of the BER.
- In the attached excel file this comparison is shown, along with the estimated number of packet lost for a BER test consisting of the transmission of 2470000 packets of the minimum and maximum allowed sizes.
> The BER column indicates the given bit error rate
> The PER column indicates the calculated packet error rate at given BER and packet size (above), for current T1S proposal
> the PER(PRE) column is the PER calculated for the new preamble proposal
> The PKTLOSS column reports the average number of packets lost for current T1S proposal for the 2470000 packet test
> The PKTLOSS (PRE) column it's the number of packets lost for the new preamble proposal
> The STDDEV column indicates the expected 3*sigma of the lost packets distribution
> the chart represents the PER vs BER for the two proposals
conclusions:
- looking at the numbers I would say the difference in PER in the two cases is negligible for bit error rates better than 10^-4 for both the min and max packet sizes.
- In other words, if the noise is too high the PER would suffer much more from CRC errors rather than mis-detected preambles
2. About the solution
Apart from my concerns about the problem, I have also some comments about the proposed solution.
- The new preamble consist of ternary symbols (+1, 0, -1), which don't represent Manchester encoded data
> The concept of '0' is well defined for the point-to-point PMD where the termination is always active and the medium is always driven. It's not really clear to me what happens for the multipoint PMD where the transmitters go to high impedance state.
> Although the preamble can be detected as indicated in slide #12, the DME decoder still need to find proper alignment which I'm not sure can be worked out by preamble synchronization alone. In fact, in current proposal the 'J' symbol allows for proper DME alignment because it starts (LSB first) with three zeroes (i.e. only clock transitions, no data transitions). Besides, the reason for having (at least) three 'J' symbols at the beginning of the preamble allows for the receiver to lose up to two 'J' symbols and still achieve synchronization on the unique sequence 'JK'.
- In slide #10 the autocorrelation should be made only on the JJJK sequence since this is the one the PHY really looks at. The rest of the preamble is for the MAC to handle.
- as depicted in slide #12 the detection of the preamble needs a correlator which actually inserts a 64 bit of latency. In my opinion such latency at 10Mbit/s is not negligible and affects PHY performance.
- I actually disagree that all these functions don't add complexity to the PHY. The T1S is supposed to be extremely cost-sensitive and I think we should not preclude implementations in coarse silicon technologies, where hundreds of gates actually make a difference in chip area and testing time.
- As a final consideration, in other standards like the 100base-T1 (which is supposed to work in automotive environments) the problem of the preamble has not been addressed, and the SSD insertion/detection is quite similar to current 10base-T1S solution.
Thank you very much for your attention,
Kind Regards,
Piergiorgio
Attachment:
t1s_ber_per.xlsx
Description: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet