Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!bu.edu!snorkelwacker!apple!apple.com!yarak
From: yarak@apple.com (Dennis Yarak)
Newsgroups: comp.dcom.lans
Subject: Re: 802.3 AUI/MAU questions
Message-ID: <9620@goofy.Apple.COM>
Date: 8 Aug 90 00:01:43 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc
Lines: 63
References:<9505@goofy.Apple.COM> <2230104@hprnd.HP.COM>


Thanks for the response, Pat.  Perhaps I could bother for a little more 
clarification?

You state:

*The normal state of lines from a powered down DTE would
*be the same as that from a non-transmitting DTE -- 0 V, so I am not
*sure what you are concerned about.

I see a potential problem with the DTE's circuits being banged on by the 
still-powered MAU when DTE's silicon has no VCC.  Usually chips (SIA or 
all-in one controller like SONIC) are specified  max. voltage at any pin = 
VCC + 0.5 Volts, so when VCC=0, the CD and RX lines from the MAU could 
cause this to be violated.  Technically this represents an AUI fault, so 
according to the standard the MAU need only work upon removal of the 
fault--so if,  for example, the MAU objected to having its CD and RX lines 
protected (say via diodes to VCC and ground on the host, causing short 
circuits), and mucked up the backbone in so doing, it wouldn't be a 
violation of the standard.  I recognize this is hypothetical and takes a 
rather extreme view of what might happen, but it does seem to be 
overlooked in the standard.

*The numbers that went into the 10BASE2 standard were the
*actual ones from the worst-case calculation.  Perhaps, you are leaving
*out the effect of sending-end overshoot or impulse response of the 
*collision detect filter.  Perhaps you are not calculating for the
*worst case situation.

I had left out signal overshoot but am considering how best to model it... 
 At any rate, are you saying that the topology constraints were developed 
considering worst-case for ALL parameters?  That would be useful 
information.

*The node count limitation was more
*based on the potential for reflections from the nodes and from cable
*impedence mismatches at each node adding and causing bit errors than
*on the effect of the nodes on the collision threshold.

Yes, this was the specific thing I was modeling.  It really seems that 30 
is conservative.
Does jitter enter in anywhere in this consideration?

*If the receiving nodes do not have receive mode collision detect, they
*then fail to detect carrier during the cancelation.  Without accurate
*carrier sense, the deferral algorithm does not work properly.

Gee, I hadn't heard this before.  The manufacturers don't say anything 
about this.  I was under the impression that carrier sense was set 
independently from collision thresholds, so moving one doesn't necessarily 
move the other in the implementations I've seen.  If bad things happen, 
shouldn't the standard just have insisted on RX mode collision detect for 
all implementations?

Anyway, I really do appreciate your responses here on 802.3 questions.  
It's great (and rare)to have the real experts on the net who take the time 
to straighten us out.

Regards,
  

Dennis Yarak
Now at Apple.