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

Re: [10GMMF] TP3 call Meeting Minutes Dec 14



Hi Piers -
 
The text that caught my eye was line 54 on page 13 of D1.0, where it explicitly defines "six" tests within this subclause. (And a single overload test shows up again in the informative test). It does not use the words "shall test", so I agree it does not make them all mandatory. But for our document, I'm asking if we think six (plus one) is really the right number; if not, we should write this differently. I'm hoping the number can be reduced.
 
I agree that we may not know how to resolve this now without more study, and it should not consume much time until we know more. I mainly wanted to raise the issue so that is does get studied.
 
On your technical point, with no connector loss, would we not expect both somewhat less modal noise and less dispersion?
 
Tom
 
----- Original Message -----
From: Piers Dawe
Sent: Friday, December 17, 2004 10:07 AM
Subject: Re: [10GMMF] TP3 call Meeting Minutes Dec 14

Mike reported:

> Tom presented thinking that at present we have to test for
> overload conditions both in the informative sensitivity test
> and the stressed Rx sensitivity test.

The draft says "The receiver under test shall satisfy the comprehensive stressed receiver ... overload".  Note "shall satisfy" not "must be tested".  We didn't hear any reason why not satisfying these conditions would be acceptable.

Either these are readily satisfied, in which case the burden is light, or they aren't, in which case an explicit requirement is the more necessary.  At present, the committee doesn't know which.  Mike suggested keeping just the "simple" overload requirement: the disadvantage with this is that the "simple" requirement is informative, and we need a normative overload requirement.

If the draft is neither incomplete nor incorrect in this area, I suggest we spend our time, for now, on the other areas where improvement IS needed.  Later, when we have some reports of overload testing in practice, we can refine it.

One small wrinkle does occur to me: bad-frequency-response channels are (nearly?) always ones with connector offsets.  Connector offset with power near the outside of the core is associated with loss.  Modal noise is strongly correlated with connector loss.  So, we are not likely to experience maximum power, bad frequency response AND high modal noise together.  But reducing the noise loading for the overload criterion may not make much difference in practice.

Piers

> 5. Informative Rx Sensitivity Testing
>
> Tom raised a point that we need to check that we are
> describing the end condition and not defining implementation
> choices in the test. This would lead to us defining a nominal
> rise time (around 129ps) rather than specifying a BT filter
> with a given bandwidth. Piers felt that it was ok as it was
> currently written. Piers and Tom agreed to look over it again

Tom's right, my apologies.  For the normative receiver test, we even have a NOTE saying that other implementations are OK.  The informative one needs rewording - whether we want to describe the TP3 signal by risetime, bandwidth or both.

Piers

> -----Original Message-----
> From: owner-stds-802-3-10gmmf@ieee.org
> [mailto:owner-stds-802-3-10gmmf@ieee.org]On Behalf Of Michael Lawton
> Sent: 16 December 2004 11:16
> To: STDS-802-3-10GMMF@listserv.ieee.org
> Subject: [10GMMF] TP3 call Meeting Minutes Dec 14
>
...
> 4. Overload proposal
>
> Tom presented thinking that at present we have to test for
> overload conditions both in the informative sensitivity test
> and the stressed Rx sensitivity test. There was some
> discussion around whether this could be reduced to a test
> that would be acceptable. Piers and Tom had views on this and
> agreed to keep working on this.
>
> 5. Informative Rx Sensitivity Testing
>
> Tom raised a point that we need to check that we are
> describing the end condition and not defining implementation
> choices in the test. This would lead to us defining a nominal
> rise time (around 129ps) rather than specifying a BT filter
> with a given bandwidth. Piers felt that it was ok as it was
> currently written. Piers and Tom agreed to look over it again
>