henry@utzoo.UUCP (Henry Spencer) (03/25/87)
I'm just in the process of activating some long-dormant PDP11 Ethernet
hardware, and have hit a problem. The hardware is an Interlan NI1010A
controller with an Interlan NT100 transceiver and a vampire tap. (Yes,
I know this isn't the latest and greatest...) The controller seems to
check out properly, but it claims it is unable to send because of excess
collisions. It is the only thing on the Ethernet, which is a 27 m (I
think) chunk of the yellow cable, factory-fresh, terminators on both ends,
DC impedance correct as measured on the tap. The Carrier Sense and
Collision Presence LEDs are on solid (although this is not indicative of
duty cycle because there are pulse stretchers on them) when the transceiver
is connected up, and off when I unplug the transceiver cable at the
transceiver. To me this says "bad transceiver", "bad tap", "bad cable",
or "major noise problem". Noise should not be excessive; the environment
isn't exactly electrically quiet -- a lot of pre-FCC equipment -- but no
arc welders either. The DC impedance being correct suggests to me that
the tap and cable are not grossly defective. I'm really hoping this isn't
a bum transceiver, it's a bad time for that. Any suggestions?
Oh, the transceiver and controller were bought in the same order and appear
to be theoretically compatible as nearly as I can tell.
--
"We must choose: the stars or Henry Spencer @ U of Toronto Zoology
the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henryed@mtxinu.UUCP (03/27/87)
>I'm just in the process of activating some long-dormant PDP11 Ethernet >hardware, and have hit a problem. The hardware is an Interlan NI1010A >controller with an Interlan NT100 transceiver and a vampire tap. (Yes, >I know this isn't the latest and greatest...) The controller seems to >check out properly, but it claims it is unable to send because of excess >collisions. It is the only thing on the Ethernet ... > [description of various static tests to determine integrity deleted] Interlan transceivers, unlike some others, are sensitive to the specification that the tap not be placed within 3m of the end of the cable. I suspect that their transceivers are sufficiently sensitive that they detect collisions with themselves from the small but inevitable reflections from the terminated end of the cable. I've never noticed this sort of problem with TCL transceivers; 3Com transceivers routinely work very well even when connected together with nothing longer than a barrel connector and terminated right at the transceiver. Be sure to locate the tap at one of the marks on the cable (to avoid standing-wave problems with other taps added later). I also try to avoid the mark nearest to the end of the cable, but that may just be paranoia - the same reason I type "sync" three times even on recent BSD systems that do it themselves when I shut down the system. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
henry@utzoo.UUCP (Henry Spencer) (03/27/87)
Well, the plot sickens. First, to sum up the two replies I got:
One said that the NT100 is Ethernet 2 while the NI1010A is Ethernet 1.
I had wondered about compatibility problems a bit myself, but the two
were bought as a package, claimed to be compatible, and the transceiver
explicitly claims to be E1 compatible. Read on...
The other reply cited past experience with marginal rejection of power-
supply noise in the NI1010A's receiver. The fix that worked for them was
to add a couple of capacitors to the board. Their account had certain
features that resembled our situation, but read on...
I did some more experimenting. In particular, I took a look at what was
going on on the cable with a scope. Most interesting. About every 36
microseconds, regular as clockwork, the transceiver put out a 400-ns pulse
at about -2V (i.e., Ethernet transmit voltage). Not a carrier sequence,
not a noise burst, but a fairly clean more-or-less rectangular pulse. No
wonder the controller was complaining of collisions when it tried to send...
Anyone ever seen anything like this?
Finally, just for the hell of it, I tried exchanging the NT100 for a Sun
transceiver (3Com 3C101, almost certain to have compatibility problems
since it's definitely E2/802.3). Problem vanished. No more pulses on
the Ethernet, no more trash-on-the-line LEDs on the controller, no more
complaints about collisions from the controller. I won't be absolutely
sure that this is functioning 100% correctly until I put something else
on that Ethernet and get them talking, but it looks okay.
My conclusion is that either (a) I've got a defective NT100, or (b) there
is something else wrong, and the difference between the 3Com and Interlan
transceivers is enough to make the difference between smooth functioning
and trouble (3Com draws less power, or has cleaner signals?). Thoughts?
--
"We must choose: the stars or Henry Spencer @ U of Toronto Zoology
the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henryhenry@utzoo.UUCP (Henry Spencer) (04/02/87)
> ... About every 36 > microseconds, regular as clockwork, the transceiver put out a 400-ns pulse > at about -2V (i.e., Ethernet transmit voltage). Not a carrier sequence, > not a noise burst, but a fairly clean more-or-less rectangular pulse. No > wonder the controller was complaining of collisions when it tried to send... It occurs to me that I didn't make one aspect of this clear enough: these pulses were on the *coax*, not on the transceiver cable. I.e., this transceiver is actually crudding up the Ethernet itself, not just making trouble for its own controller. A few people have assumed that I have gotten confused about transceiver heartbeat. Unless I am *seriously* mistaken about what heartbeat is, this isn't it -- wrong cable, wrong signal characteristics (square pulse instead of 10-MHz wave), wrong timing (continual rather than a short burst at the tail end of each transmission). For compatibility fans, by the way, the NI1010A controller claims to be Ethernet 1, but one of its test commands claims to listen for heartbeat! > Finally, just for the hell of it, I tried exchanging the NT100 for a Sun > transceiver (3Com 3C101 ... Problem vanished... Just to keep people up to date on the fun... This substitution has indeed cured the problem completely. The Ethernet cable is electrically clean according to my scope, and the NI1010A is communicating successfully with a Sun via the Ethernet. There may possibly be a noise problem on the transceiver cable -- I don't have an easy way to get a scope probe into it -- but on the surface everything's quiet. -- "We must choose: the stars or Henry Spencer @ U of Toronto Zoology the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henry