• Mike Altman resumed previous presentation (http://ieee802.org/3/ap/public/signal_adhoc/altmann_s1_1004.pdf)  concentrating on slides #11, #12 related to the treatment of aggressors.
  • NEXT, FEXT
    • [John S.]           One way to deal with NEXT and FEXT is to simulate the forward and crosstalk paths.  From these simulations you can get PDFs and by convolving them a resulting PDF could be generated that could be used to analyze the system.
    • [Mike A.]           Would the results not be Gaussian?
    • [John S.]           Probably not, because the number of interfering signals is small.
    • [Rich M.]           It’s probably OK to limit the number of interferers.
    • [Mike A.]           That would almost imply treating them as deterministic signals then, not Gaussian. How does StatEye deal with xtalk?
    • [?]                    It has both deterministic and random components.
    • [Adam H.]         StatEye convolves the pdf of xtalk and signal
    • [Mike A.]           So, for our purposes, it would be OK to consider xtalk as having Random and Deterministic components?
    • [Dimitri]             All the time we have tried to describe xtalk as a deterministic effect we have had poor results.
    • [?]                    Especially in a multilane situation where you may have many interferers.
    • [Mike A.]           I would like to conduct a straw poll to determine if we feel that there is a need to consider a mixed random/deterministic scenario. The three alternatives to consider are: (A) xtalk is random, (B) xtalk is deterministic, (C) has both random and deterministic components.
    • [Petri]               If we are looking for worst case, treating xtalk as a deterministic signal will yield  worst case results.
    • [Brian]               Sometimes we look for worst case, sometimes we look for statistics. I sometimes get confused when the two things are combined. Mike, how would you see it treated?
    • [Mike A.]           My idea was simple: given an eye at the equalizer input, deterministic components of xtalk will subtract from the height of the eye, while the random components will add on to noise.
    • [Rich M.]           Is this discussion really justified? If one signaling scheme turns out to be a clear winner, it probably makes no difference.
    • [John d’A]         Are assuming that all aggressors are of the same data type (as opposed to considering 1G, 3G etc)
    • [Joe A]              These are lower frequency so should not have an effect.
    • [Mike A.]           Signal types that are not part of the 802.3ap standard are to be considered as part of  the environmental noise (TTL, USB, FC etc.). The most likely source of xtalk are the three signaling schemes described in the 802.3ap.
    • [John S.]           I would support that. For example in ATCA NEXT should be of the same nature as the one under test, but one of the FEXT aggressors could be one of the other two signal natures.
    • [Fulvio S.]          What about equalization assumptions in the transmitters associated with these aggressors? Should all be equal? What if one of the aggressors is of different nature?

STRAW POLL #1: Next/Fext treatment should be : A. Random, B. Deterministic, C. Both

• A  = 9
• B  = 1
• C  = 16

STRAW POLL #2: Should we use Next/Fext mask to determine total xtalk effects (yes) or should we use measured data (no)?

• Yes: 2
• No:  21
• Abstained: 2

Straw Poll #3 : dropped

Straw Poll #4 : Aggressor signaling types:

• A. aggressors are 10 G serial (14)
• B. aggressors are 802.3ap types (5)
• C. treat Next/Fext to encompass wider signal universe (1)
• Abstained (1)
  • [Fulvio S.]          As for the transmitter equalization assumptions I propose we use same setting as forward path.
  • [John S.]           Alternatively we could use max boost settings.
  • [John d’A]          In general I have observed that adjacent channels are pretty similar

Straw Poll #5: For the purpose of Next/Fext transmitter definition use same equalization settings as forward path (A) or something else (B):

• A. 14
• B.   0

 

• Thermal noise discussion
  • [Vivek]              the 1.4 nv/sqrt[Hz] seem too low.
  • [John S.]           the number is accurate for 100 ohm resistor, but is it what we want to use?
  • [Vivek]              in 10GBT we have use 31.6 nv/sqrt[hz] or 140 dbm/Hz.

 

Some more discussion ensued but since the time is over, Mike A. decides to table the discussion for the next signaling ad-hoc call.

 

Attendance:

 

Joe	Abler
Michael	Altmann
Majid	Barazande-Pour
Amir	Bar-Niv
Joe	Caroselli
John	D'Ambrosia
Doug	Day
Ali	Ghiasi
Healey	Adam
Mike	Lerer
Cathy	Liu
Mary	Mandich
Richard	Mellitz
Charles	Moore
Pravin	Patel
William	Peters
Petre	Popescu
Shannon	Sawyer
Brian	Seemann
Jimmy	Sheffield
Jeffrey	Sinsky
Fulvio	Spagna
Apoorv	Srivastava
John	Stonick
Dmitri	Taich
Vivek	Telang
Schelto	van Doorn
Brian	Von Herzen
Chris	Wittensoldner