Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!UCBCMSA.BITNET!CLIFF
From: CLIFF@UCBCMSA.BITNET (Cliff Frost {415} 642-5360)
Newsgroups: comp.sys.proteon
Subject: Re:  4-into-6 coding, and the "clasic" pronet-80 problem
Message-ID: <9003200159.AA25775@devvax.TN.CORNELL.EDU>
Date: 20 Mar 90 01:59:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 48

Bob,
> From you description of the problem, is it correct to sum up that
> the problem is not one of wave-form deformation, but rather
> receiver time-base instability?  (ie, receiver can't be trusted
> to sample signal near the middle of the bit-time?)

Keep in mind what I said about grains of salt.  I *think* this is
correct, but I'm not an engineer by any means.  There may be more
than one thing going on, this is the only one we've gotten a handle on.

> Do you have the mapping table for the 4-> coding used by proteon?
> Can I get a copy?

I have a reprint of an article by Howard Salwen, Alan C. Marshall, and
Nathan K. Salwen.  I have no recollection of where it came from, you should
ask Proteon for a copy.  It's called "ProNET An 80 MBIT/S Token Ring
For High-Speed LAN Applications".

> Do any of the allowed codes result in strings of four zeros, four ones?

No.  I think you can get runs of 4 and 3, but not 4 and 4.

> I do not have any fiber equipment here to blame the problem on.
> I have 8 P4200s, sitting in the same room, connected to a
> ganged wire-center.  Intuition would lead one to believe
> that this would be a "piece of cake" installation.

Are you hinting something nasty about Proteon's Quality Assurance?

Or, are you asking for advice on how to proceed?   ;-)

I would try the file transfer method.  If it works you will be left
with the question: "is it the transmitter or the receiver?".  Ie--it
won't tell you exactly which p4200 is having the problem.  What you
do then is swap the p4200's positions in the wire center.  In the
"classic" case the problem follows one or the other.  In the nasty
case the problem goes away for a while or does something else weird.

> Are any of the pronet-80 interface statistics of any real use in
> locating the culprit?  Given the frequency and magnitude of the
> problem, I would hope that some parameter they report is usefull.

The "Output bad format" and "Input parity error" counters are
useful to watch.  Proteon will tell you a trouble-shooting method
that uses the Input parity error counter.  It has sometimes been
useful here, and I should have mentioned it.

        Cliff