Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!sdd.hp.com!hplabs!hpcc01!hpcuhb!hpda!hpcupt1!hprnd!pat
From: pat@hprnd.HP.COM (Pat Thaler)
Newsgroups: comp.dcom.lans
Subject: Re: 802.3 AUI/MAU questions
Message-ID: <2230106@hprnd.HP.COM>
Date: 11 Aug 90 01:03:26 GMT
References: <9505@goofy.Apple.COM>
Organization: HP Roseville Networks Division
Lines: 101

> 
> 
> *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.

I checked data sheets of two serial chips.  Neither specified such a
requirement.  (One did specify such a requirement for its TTL inputs,
but not for its differential inputs, the CD and RX lines.  The other
had a VCC related requirement for its common mode voltage, but not
its differential voltage.  The inputs are normally transformer isolated
so the common mode voltage is established locally, not by the 
transmitter at the other end of the AUI.)  I don't recall data sheets 
for other serial chips I have worked with requiring protection from 
differential inputs when powered down.

I think it is fairly unlikely that a MAU would disturb the media in
the case you describe.  However, if you believe that a requirement
that the MAU not disturb the media during AUI faults should be added,
you could submit a revision request to the Maintenance Task Force of
IEEE 802.3.  Such a request should include the exact text you propose
adding or changing, the reason for the change, and the impact of the
change on existing implementations.  The Maintenance Task Force does
not write changes to the standard.  They evaluate whether the changes
are ready to ballot or need further work by the proposer.  When a
number of changes are ready for ballot, they manage the ballot process.
> 
> *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.

Yes, that is what I am saying.  
> 
> *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?

Reflections can result in jitter.  30 was not conservative.  Remember that
each of those 30 taps can have a mismatch in the cable impedance plus 
the effect of the tap impedance.  30 was worst case, it assumed the
worst node spacing and impedance mismatches.  Probability is very low
of actually getting this situation.
> 
> *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?

The carrier sense in the PLS is, simplistically speaking, the logical
OR of two conditions: signal quality error (SQE, aka collision detect)
on the CI pair or input on the DI pair.  If there are no transitions
on the DI pair for approximately 1.5 bit times, the PLS may sense
the DI pair's state as input_idle (if the DI pair is HI for 2 bit
times, that is the start of idle signal).  This signal cancellation
on DI happens only during collisions.  Receive mode collision detect
ensures that SQE will be present to keep carrier sense on if dropouts
occur on DI.

The effect of this on the network is a small loss of efficiency if
repeater MAUs have receive mode collision detect.  It
is not a serious problem.

I don't think that they were aware of the problem when the initial
802.3 standard was drafted.  When we wrote the repeater standard, 
we were aware of it and were aware that it had more effect on
repeaters than DTEs, so we made RX mode collision detect required
for repeater MAUs but didn't require it on 10BASE2 and 10BASE5
MAUs for DTEs.

Pat Thaler