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

RE: [802.3ae_Serial] - link model modification requests




Tom,
I'm glad that you were able to arrive at numbers in agreement with table
52-10 in D3.4 by setting the connection insertion loss back to 1.5 dB across
the fiber types for 10GBASE-S. The fact that some cells for connection loss
contained an additional amount of loss, the source of which may be
attributable to some prior agreement, points to the need for a more direct
way of handling these types of variables, lest they become lost in
obscurity. This enforces the need for separate "unallocated margin" and
"additional loss" input cells. 

I am in favor of your suggestion to clarify the parameter description in
tables like 52-10 by changing the "Allocation for penalties" entry to
"Allocation for penalties and margin". After all that is exactly what the
values represent.

Regards,
Paul Kolesar

> ----------
> From: 	Lindsay, Tom[SMTP:tlindsay@xxxxxxxxxxxxxxxxxxxx]
> Sent: 	Friday, November 30, 2001 5:02 PM
> To: 	Kolesar, Paul F (Paul)** JV  **; 802.3ae Serial
> Subject: 	RE: [802.3ae_Serial] - link model modification requests
> 
> All - 
> 
> I want to close on this portion of Paul's initial email. My  motivation
> for doing so is not technical, but purely for documentation.
> 
> If I apply the equations implied below to the spreadsheet as it
> currently exists (10GEPBud3_1_16a.xls), I do NOT get anything close to
> what is in the document (D3.4).
> 
> Looking further, I discovered that cell L7 includes 1.5 dB connector
> losses plus another number. I do not know where these other numbers came
> from, but they appear to be inputting the anticipated values for
> additional_insertion_loss_allowed. This is in conflict with the
> equations implied below, which say that
> additional_insertion_loss_allowed should be an output or result.
> 
> If I remove the extra number in cell L7 and then apply the equations
> below, then everything works exactly per D3.4 (within 0.1 dB anyway,
> possibly due to roundoff). I would like this approach to be implemented
> in the spreadsheet.
> 
> Also, the table row named Allocation_for_penalties is not simply
> penalties, but adds unallocated_margin after additional
> _insertion_loss_allowed is subtracted. For documentation, it would sure
> be more clear if that row is renamed to
> Allocation_for_penalties_and_other margin. I understand the desire to
> not give the impression that more margin is available, but I also do not
> want anyone to think they can develop/incur penalties beyond the values
> in column V.
> 
> Note1: other than renaming the row, these comments do not affect the
> standard, only the spreadsheet as documentation and general purpose
> tool. I do NOT plan to submit comments on this topic this time around,
> but do plan to during sponsor ballot.
> 
> Note2: I have only checked Table 52-10 (-S). I have not checked any of
> this for -LX4 and -E variants.
> 
> Comments?
> Tom
> 425/672-8035 x105
> 
> 
> -----Original Message-----
> From: Lindsay, Tom 
> Sent: Tuesday, November 27, 2001 4:43 PM
> To: 'Kolesar, Paul F (Paul)** JV **'; 802.3ae Serial
> Subject: RE: [802.3ae_Serial] - link model modification requests
> 
> 
> Paul - sorry about being myopic on clause 52 and the loose usage of
> "PMD".
> 
> If what we say below is true, then the reserved margin value is
> pre-determined and would be an input to a new cell that would result in
> allowable additional loss as an output. The cell would appear in each
> sheet of multiple-fiber group supported by a common PMD (did I say that
> right?). The cell equations would be of the form:
> 
> fibertype_unallocated_margin - reserved_margin
>   where
> reserved_margin = min(all_unallocated_margins_for_that_PMD)
> 
> I agree this would be better isolated from an input cell that reserves
> additional loss for splitters, etc.
> 
> So do I understand what you are after?
> 
> Tom
> 425/672-8035 x105
> 
> -----Original Message-----
> From: Kolesar, Paul F (Paul)** JV ** [mailto:pkolesar@xxxxxxxxxx]
> Sent: Tuesday, November 27, 2001 2:43 PM
> To: 802.3ae Serial; Lindsay, Tom
> Subject: RE: [802.3ae_Serial] - link model modification requests
> 
> 
> Tom,
> Yes you are correct. I would like to offer a clarification on your first
> statement. I believe you meant to say 
> > 1. "Additional loss" was only for -S, since it is the only variant
> that
> > supports multiple fibers (not PMDs).
> > 
> 	The LX4 PMD would also falls into this category, since it
> supports
> multiple fiber types as well.
> 
> 	Paul
> 
> > ----------
> > From: 	Lindsay, Tom[SMTP:tlindsay@xxxxxxxxxxxxxxxxxxxx]
> > Sent: 	Tuesday, November 27, 2001 5:24 PM
> > To: 	Kolesar, Paul F (Paul)** JV  **; 802.3ae Serial
> > Subject: 	RE: [802.3ae_Serial] - link model modification requests
> > 
> > Paul -
> > 
> > I apologize for not completely understanding your rationale. To
> attempt
> > clarification, I would like to 1st step back a few revisions (I think
> it
> > was in St. Louis) and recall how this began.
> > 
> > 1. "Additional loss" was only for -S, since it is the only variant
> that
> > supports multiple PMDs.
> > 2. Unallocated margin was hidden and deemed "not available" for adding
> > insertion loss or distance.
> > 3. The values for Additional loss were derived by 1st determining
> which
> > PMD had the least unallocated margin and then subtracting that value
> > from the unallocated margins of the other PMDs. The PMD with the least
> > unallocated margin was 2000 MHz-km, so it got 0 dB of Additional loss.
> > 4. In other words, "reserved margin", as you name it, was really the
> > unallocated margin for the PMD with the lowest value.
> > 
> > Is my recollection correct? Is this still what we are trying to do?
> > 
> > Tom
> > 
> > -----Original Message-----
> > From: Kolesar, Paul F (Paul)** JV ** [mailto:pkolesar@xxxxxxxxxx]
> > Sent: Tuesday, November 27, 2001 10:25 AM
> > To: '802.3ae Serial'; 'Dawe, Piers (Agilent)'
> > Subject: RE: [802.3ae_Serial] - link model modification requests
> > 
> > 
> > 
> > Piers,
> > on the call today you mentioned that you were considering adding an
> > input
> > cell to the link model to account for splitter loss in EFM. You
> > suggested
> > that this cell could also serve the purpose of defining the additional
> > loss
> > allowed for 10G PMDs and thereby indirectly resolve my request for a
> new
> > cell to allocate reserved margin. 
> > 
> > I've had a chance to think about the solution you suggested and
> believe
> > it
> > would be a sub-optimal compromise. While I agree that such a cell
> could
> > serve both purposes, it has a drawback in the case of substituting for
> a
> > reserved margin cell. The drawback stems from the fact that we have
> > chosen
> > to apply a fixed amount of reserved margin to each PMD type across all
> > fiber
> > types that support it. The  resultant additional insertion loss
> > allowance
> > varies by fiber type. Thus, while a single value applies for reserved
> > margin
> > for each PMD across all fiber types, with the approach you suggested
> > multiple values are needed for additional loss allocation, one for
> each
> > fiber type. This could require a separate worksheet for each PMD/fiber
> > combination, a complexity that I would rather avoid. It also means
> > needing
> > to tweak the additional loss entry to a value that results in the same
> > margin at the specified link length for all fiber types supporting a
> > particular PMD. I'd rather have the link model do the calculations.
> It's
> > less obscure and less error prone. 
> > 
> > I think a cleaner approach would be to insert two new cells, one for
> > each
> > purpose. The additional loss cell would be used to allocate a fixed
> > amount
> > of loss (e.g. for splitters). The reserved margin cell would be used
> for
> > making a portion of the power budget unavailable. The present "margin"
> > column could be re-titled to "available margin", which under present
> > philosophy would be used to fill in 10GbE table entries described as
> > "additional insertion loss allowed". 
> > 
> > I hope this explanation makes my points sufficiently clear. If not, or
> > if
> > you have another view, please respond.
> > 
> > Regards,
> > Paul Kolesar
> > 
>