Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [10GMMF] TP3 - Receiver Sensitivity Clauses - Suggested Change to D1.0 12-22-04.pdf;Receiver S

Lew and all,

Nice work.

In the attached, see the "Word tracked changes" as suggested improvements.  Most of it is minor-technical and self explanatory, occasionally editorial.

We must avoid becksliding towards the "shall be tested" language.  To get away from it, think of these sections as definitions of what we mean by (in this case) stressed sensitivity, with a recipe that can be taken literally, but other approaches work too.

I've proposed a sentence that brings the table of (time, response) columns into the normative part.



> -----Original Message-----
> From:
> []On Behalf Of Lew Aronson
> Sent: 24 December 2004 00:50
> To:
> Subject: [10GMMF] TP3 - Receiver Sensitivity Clauses - 
> Suggested Change
> to D1.0 12-22-04.pdf;Receiver S
> TP3ers,
> Attached is a draft of an expanded / rewritten clause for the 
> comperhensive stressed sensitivity test.  I canalso proivide 
> a version which shows the changes relative to the current 
> D1.0, however that would exceed the 100k e-mail limit and my 
> understanding is that files are not being uploaded presently. 
>  Write to me directly if you would like the relative change version.
> A few general notes:
> Generally follows the organization and style of the 802.3ae 
> stressed receiver test.
> I have assumed that there is no sinusoidal jitter impairment 
> which I believe is the current consensus.
> I have reorganized the numbering a bit such that there are 
> not so many layers of clause hierarchy (not having a 
> superheading for the normative and informative sensitivity tests.
> The draft assumes we settle on the 4 peak equal dT implementation.
> It also has examples in graph and table form of the expected 
> test signal with an isolated one bit pattern.  These types of 
> examples are not normally included in an IEEE spec, but I 
> think they are of a lot of practical value here.
> Finally, I have provided a new block diagram which correct 
> some errors mistakes , takes out the SJ impairment and 
> includes the reference receiver for the signal characterization.
> One comment which has been made is whether we should define 
> the ISI impairment by the graph / table which I have as an 
> informative example.  I could support this as long as we 
> continue to use the ISI implementation model as a means for 
> determining the required IPR (that is we have an IPR which 
> can be accurately generated by a practical implementation).  
> Further, we should then have an informative note on that 
> implementation and the associated peak height parameters.  In 
> any case, the same information would be present and it would 
> just be a case of which we can normative and which is informative.
> What I don't think we should do is choose IPRs without 
> regards to the implementation.
> Lew