Hello all.
I'm from Europe and happen to have a few machines from the last millenium still around me. One of them is very black, and it's Gestalt is not very round, so you might like it.
Not only because of this machine I'm happy to see a web site related to it has appeared, and grown, since a few years ago. :-)
OK, but now I've got a hardware related question:
A few months ago, my box started having problems getting Ethernet packages through its TP Ethernet port. So much that this port became unusable.
I was wondering whether this would be a hardware issue - whether anyone might have seen it before and know the reason - or whether anyone might know that some funny software or configuration problem might cause such behaviour. Or newer ethernet, too many hosts, new protocol features known to others but not next... anything???
Details:
My box is a Next Dimension 68040/25MHz Cube.
Has lived in the same place for a couple of years. Has been used occasionally. Has been connected to a LAN via its Twisted Pair (TP, 10Base-T) Ethernet port all the time - at least, if I remember that correctly.
4 Months ago, booted it, and found the network wouldn't work. Tried with alternate switches, direct connections to various other machines - all with old 10/100 Fast Ethernet, and new Gigabit Ethernet on the other end. Also tried a number of different cables (although I do NOT know now, whether at least one unshielded cable would have been in the set, or would be available here at all. (One very flat TP cable was tried however, I guess this would rather be unshielded.).
ping from this box, or to this box, via the TP connector will lose almost all packages.
Exceptions: The first package after a physical disconnect, pause, reconnect may quite often get through, and get through reliably if the BNC connector was used before.
Also, maybe 3..5 reply packages from next may get through when I ping to it from Linux with the -l "preload" option, that will send a number of pings packages and not wait for replies. The first two will usually fail, but number 3..6 or 7 may actually evoke replies that also make it back to the linux machine, and then, within some rather normal 2 ms or so. All following packages will *not* find visible replies any more, no matter whether I "preload" 8 or 100 packages.
Pinging with different package payloads, between 1 and 500 bytes, does not change the behaviour.
If connected via the TP connector to any switch, or to an autosense ethernet port of a laptop etc., that switch/port shows a good link with the correct speed. All transmitted ping packages from the Next make the switch LED flicker, but they most probably not reach the intended target node (most packages won't become visible in Wireshark running on a target node).
And connecting a TP cable between this port is enough to change the ping message on next from something like "can't reach/not available" to some long waiting for incoming replies.
I.e. the cable is recognized, but transmitted messages are in some way not "strong" enough, or not correct, so they will mostly not get through.
Moreover, if I use the BNC connector of the machine via some BNC-TP-capable switch, its networking works like a charm. Here I can ping, flood ping, use bing to measure throughput (results are 7.. 8.5 MBps) etc. - perfect.
I already know that the cabling from the far end of the TP ethernet cable to the machine side of the initial chip *behind* the connector, which includes 4 parallel impedances, is completely ok. Two blue capacitors behind that show the same plausible little capacity on the multimeter. And the remainder of the board does not look suspicious in any way. Motherboard Battery is good, nothing spilled etc. No visibly lose parts. No other relevant problems with the machine (so far).
It's really funny to see the occasional package getting through. Maybe at one point I've even seen the port work well again - surprisingly, unexpected, after some debugging session - and then go bad again a little bit later.
It almost looks as if the output or input should be overloaded or saturated in some electrical or logical way (like: MAC comparison logic???) by sending one or a few packages, and then would clamp to some "useless" state.
I have *not* yet connected a scope or similar tool, just wanted to ask whether something similar might be known to other users. I've already seen the chips used might support diagnostic LEDs (which Next apparently saved the money for), if nothing else helps I might add them in.
Electrolytic caps close by do not look bulged or otherwise suspicious.
The Mac-Adress reported by the cubes configuration looks ok, (like 00 00 0F xx xx or so) and it's the same that's seen outside (in wireshark).
Oh, and: yes, there's an SGI Indy somewhere above that cube, connected to the same switch. I *might* theoretically have plugged a cable into the Indy's ISDN port, while the other end was in the Cube's TP Ethernet port. That's not very probably - and it's even less probable that any of the machines would have been powered on while I did that - but theoretically, it might have happened and it might possibly (??) explain why a 10Base-T Port should go bad. If there isn't any other more probable reason...
Any input is highly welcome - thanks for your reading and for your inspiration in advance. Kind regards, and season's greetings!
Joerg
Hey Jörg & welcome to the forums.
Your problem looks rather interesting. I have a suspicion that it may be noise related and noise would indicate capacitors going bad. Have a very good look around the surface mount electrolytics to see if there are any indications of electrolyte venting. This would look like an oily stain, perhaps with dust stuck to it:
http://www.flickr.com/photos/t-rexky/6795732116/These electrolytics may also visually appear to be fine but be dried out and not functional. I would not expect to see them bulge, however.
The BNC may work because it has a separate and dedicated power supply with its own output smoothing capacitor. If this capacitor is in a better shape then the network would be more stable on the BNC port.
Peter.
We're just recently starting to see failures and weird behavior caused by the SMD capacitors leaking so it doesn't hurt to replace them anyways.
+1 for capacitors.
--
Brian
And as a by-the-way, I just rebuilt a Quadra 660av with 13 new SMD capacitors and I tried the side cutter method of removal rather then the alternating pad with a soldering iron method. It worked like a charm and not a single lifted pad. I will rebuild my sound boxes next using this approach.
Hello all -
Thanks a lot for your fast replies - and t-rexky, for the beautifully made photo series. Had to smile at the sticker you added to your board.
Your feedback will make me give the caps a very careful look now. Especially if you started seeing trouble since 2011. I only shudder in an---ticipation, considering the few machines that should consequently have reviews. Or end up with corroded multilayer boards. :-(
Some time ago I actually replaced all SMD caps on a DAT deck control board. That cured not only the drive control problems that lead to the diagnosis and action - but also the digital input malfunction that had started some years before, quite far away from the spillage. And I was lucky because one cap had spilled fluid; pads and connections nearby showed corrosion and needed bridging in the worst spot.
Wouldn't want anything similar on this board.
OK. I'll post some follow up if I get it done (hopefully by next year :-) ).
Kind regards! Jörg
Quote
Your feedback will make me give the caps a very careful look now. Especially if you started seeing trouble since 2011. I only shudder in an---ticipation, considering the few machines that should consequently have reviews. Or end up with corroded multilayer boards.
I've started stumbling onto the problem in devices as new as studio DVcam tape decks. Remember the badcaps incident in the early 00's? Get ready as we begin to see SMD caps begin to expire as we're about to hit the point where everyone and everything switched from through-hole to SMD.
Hi all.
Here is some follow up.
Interim conclusion:
------------------------
Apparently, the Twisted Pair Ethernet port of my NeXT Cube can only communicate via one gigabit ethernet switch out my available set.
That might indicate some relatively early problem in the Cube's TP port.
So I might be back at "capacitors!" again. :-(
However, on both NeXT boards I did not spot any slightest sign of anything having evaded any capacitor. And an operation would not fit in easily right now (me having the flu) - but still carry a risk of damaging something - I decided not to operate on it right away.
But I see there definitely is a problem, I'm not completely done with it yet (and will keep the caps in mind).
Other (now relatively improbable) reasons might relate to what we call "Brummschleife" over here (electromagnetic hum between devices due to the specific arrangement of power cables) etc.
Please - do not read on if you're not intensely interested in the details!
-
Here is what I did and what I found
Looking at the caps:
-----------------------
Examined both boards of the machine carefully (but only in office light).
Did not find *any slightest* sign of anything leaked from any capacitor.
Only a little dust in several places; far less than I've seen in other machines. Cleaned some away with alcohol tabs (mostly on IC sides and caps, especially the ZIP RAMs) - but that was mostly for cosmetic reasons (if not remotely to improve cooling...).
Also cleaned the component side close to the ethernet ports. That would hardly colour the swabs. And it wouldn't help either.
Then, I re-measured the coils and caps behind the TP port. Highly probably ok. Checked the values (mostly resistance) of small SMD parts - found a few, that would repeat across multiple parts = plausible values.
Couldn't measure the electrolytic caps individually w/o removing at least one pin (because the total would exceed the range of my multimeter [but I wouldn't want to make more complicated measurements then]).
Moreover, only one SMD 47uF cap and two perfect looking classic 220uF are close to the ethernet portion. Measuring the 47uF of these gave a result beyond the range of my multimeter [->and I wouldn't want to know more right now]. So it was at least connected to some large total capacity as you would expect from local power supply buffers/HF noise reducers. Only 6 x 47uF SMD are spread across the board, and a few 220uF in addition to them. Given this low numbers of caps in total, and the fact that much of the board should be relatively low power consumption logic, and that two 220uF are very close to the one 47uF in the ethernet area, and *no* slightest signs at all of any leakage, and SCSI and mono video out (with heatsink and 100MHz quartz) also close by working perfectly - I thought that all this should make it less probable that any SMD caps should have dried out, and even if this one should, its functionality might be sufficiently covered by the others. Or at least, it should not be very plausible that one single small ethernet chip would lose its functionality from noise, whereas a number of probably more power hungry, and more momentary load causing ones nearby should still work perfectly.
Well, this is still all speculation and it may be wrong. BUT: I am reluctant to swing a soldering iron over a rare, narrowly packed SMD board before trouble would be more severe, and the diagnosis more reliable.
To find (remote) arguments pro/con the "caps" hypothesis, I also booted the machine w/o the dimension card to reduce PSU load. That would not change a thing.
I considered removing main memory SIMMs as well to make local power supply/noise issues less probable. But I found they're not easy to get out - might break the plastic clips holding them in place - and as they are far away from the ethernet section of the board, have their own 220uF cap etc. pp. (see above) - I stopped after the first one and put everything back together for now.
Tests re. cabling and switches:
-----------------------------------
The cast:
Cube connected via TP or Coax
Switch1 Gigabit Ethernet all TP
Switch2 10/100 Fast Ethernet all TP
(Various other machines on both of these switches)
Switch3 1x Coax; ca. 12x TP 10Mbit Ethernet
Switch4 10/100 Fast Ethernet all TP
Switch5 Gigabit Ethernet all TP, different make than Switch1
(Various cables, old and new)
I normally deploy one gigabit ethernet switch1 which is completely full, plus one secondary 10/100 switch2 for a few slower machines by another desk, including the NeXT cube.
Normal expected operation:
AnyOther tp - 10/100(tp)switch2 - giga(tp)switch1 - anywhere
would work
But:
Cube tp - 10/100(tp)switch2 - giga(tp)switch1 - anywhere
does NOT work (THE original annoying finding).
(I'm unsure whether this evolved over time in this configuration,
or whether I introduced it when I last rearranged the LAN setup,
but did not notice for months because the Cube was rarely used.)
But:
Cube coax - 10M(coax+tp)switch3 - 10/100(tp)switch2 - giga(tp) switch1 - anywhere
DOES work (solving the acute problem, but leaving me uncomfortable)
So I tried more variations:
Cube tp - 10M(coax+tp)switch3 - 10/100(tp)switch2 - giga(tp)switch1 - anywhere
would NOT work
Cube tp - 10/100(tp)switch4 - 10/100(tp)switch2 - giga(tp)switch1 - anywhere
would NOT work
Cube tp - giga(tp)switch5 - giga(tp)switch1 - anywhere
would NOT work (but indicate (supposedly) some negotiation attempts)
Cube tp - giga(tp)switch1 - anywhere
would SURPRISINGLY (for today) work.
With 5m cable CAT.5E SFTP
Cube tp - giga(tp)switch1 - router
WORKS
Cube tp - giga(tp)switch1 - router - wlan - latop
WORKS
Cube tp - giga(tp)switch1 - 10/100switch2 - printer
WORKS (!)
And yes: No cabling errors here, if I remove the line between switch1 and switch2, that ping will stop.
Now, I'm really curious. Let me try this one:
Cube tp - 10/100(tp)switch2 - printer
does NOT work. (oh, oh...)
I used the same cable that went from cube to switch1 (->switch2->printer) before (working), and plugged that over to switch2. And waited for the pinging Cube to show "network unavailable" after removal of the cable from switch1, before I plugged it into switch2.
Now:
Cube tp - 10/100(tp)switch2 - printer
with the link to ge(tp)switch1 removed.
does NOT work either.
Power cycling switch2 does not help.
Unpluging the cable to Cube and waiting etc. does not help.
The switch recognizes that cable, but the Cube sticks with "Network is down"
Additionally power cycling the Cube...
Well, it dosn't say "Network is down" any more,
but neither does it see any ping echoes.
(Over the years, I've seen rare failures - on about two switches - apparently from MAC address table overloads, wrong assumptions regarding connections etc. - These might theoretically justify complete powering down and up again of all components for perfect testing - but that would take ages to complete.)
Now I try it with *all* other switches:
Cube tp - 10(coax,tp)switch3 - printer (only using tp!)
does NOT work
Cube tp - 10/100(tp)switch4 - printer
does NOT work
Cube tp - giga(tp)switch5 - printer
does NOT work
In all cases, the cube tries to ping.
Its light on the switch will indicate the pings -
but the light for the printer will permanently stay on.
So the ping from the Cube does apparently NOT cross any of these switches.
Cube tp - laptop (with a Gigabit Ethernet port):
Does NOT work.
So: The newest giga(tp)switch1 is the only one that can be crossed by the Cube tp. :-(
For the record: That's a d-link DGS-1008D
Whereas switch5 is a TP-Link TL-1008D
I would have guessed that both boxen would contain very similar, if not the same hardware - but effectively, they are different. Or... (back to noise, hum, etc.) - the difference might be that switch1 has all its ports connected? (Well, switch2 is also quite full...) - NO.
Just swapped in switch5 (TP-LINK) for switch1 (d-link) completely.
NeXTCube sadly doesn't communicate through it. :-(
Hmm. This makes the hypothesis that Cube tp is out of its specs more plausible again.
(For the record: Every switch kept the power plug that came with it. I won't look into exchanging these.)
So, final bottom lines for now:
-----------------------------------
(1) *My* NeXTCube 68040/25 TP ethernet port may be so far out of its specs that it can communicate only with my newest switch. :-(
(2) d-link DGS-1008D works; whereas TP-LINK TL-1008D does NOT work. This may be specific for my machine - and off topic from here on - but it underscores that two very similar boxes with very similar price tags from very similar origin do still not contain hardware that would perform in the same way. Very interesting. I haven't opened them and looked inside, yet...
I think this is the first time that I have seen a computer being able to work with one TP Ethernet switch, and not with (esp. so many) others.
I've seen similar things before for RS232 ports on laptops (years ago, probably >10 years ago!, lost hours or days back then) - but Twisted Pair Ethernet has always looked very tolerant to me.
Would any of you ever have had similar experiences?
-
OK. Please excuse me for this long post. As this is certainly a special interest group - and due to the fact that this odd behaviour could hit more NeXT owners with the boards coming of age - I thought you might rather enjoy the details being recorded and visible for search engines.
If you have any comments - I'm still curious :-)
(I may still look into capacitor replacement when I feel a bit more relaxed & w/o the flu...)
Oh, mental note: "Capacitors in the power supply... - at least give them a quick look." :-)
Kindest regards + *** A HAPPY NEW YEAR 2014 !!! ***
Joerg
Hmpf!
Also just for the record:
I just happen to notice that both GE switches emit so much noise in the CB range that they can clearly be heard. The base noise of the TP-Link is somewhat more noticeable than the d-link.
No fun.
Kind regards. Joerg
Quote from: "flupsdups"Thanks a lot for your fast replies - and t-rexky, for the beautifully made photo series. Had to smile at the sticker you added to your board.
You are welcome! Just please note that after some more board reworks I now definitely prefer to snip the SMD capacitors off the board with side cutters rather than using the alternate pad pulling method illustrated in the photos. The disadvantage, of course, is that you cannot measure them to understand if they were bad or not. And the sticker, well it's just what I do :-).
Quote from: "flupsdups"Moreover, only one SMD 47uF cap and two perfect looking classic 220uF are close to the ethernet portion.
Have a look in the file archive area where there is a schematic of the Turbo Cube main board. Sheet 8 of the schematic shows the Ethernet circuits including the power supplies. Of particular interest would be C92 but also C79 and C96. The schematic is at:
http://www.nextcomputers.org/NeXTfiles/Docs/Hardware/Schematics/Turbo_cube/. I expect that the non-turbo Cube ethernet configuration is very similar if not identical. The 220uF are all bypass capacitors and are in parallel with VCC as well as most of the other 47uF capacitors. In-circuit measurement would therefore not be very effective.
Quote from: "flupsdups"(I may still look into capacitor replacement when I feel a bit more relaxed & w/o the flu...)
Oh, mental note: "Capacitors in the power supply... - at least give them a quick look." :-)
Kindest regards + *** A HAPPY NEW YEAR 2014 !!! ***
Joerg
I am still voting for the capacitors since the behaviour is intermittent. I am actually now at the point where I do not even bother testing the electrolytics on the the vintage equipment I acquire. I just clean everything, open it up, make a list of all the electrolytics on the boards and in the power supplies and order replacement parts from DigiKey. I even replace the input line filter capacitors even though they seem to always measure good. My overall opinion is that it is not worth the risk of potential damage by continuing to use such old and sometimes rare equipment without refurbishment.
Note that when ordering replacements I identify the manufacturer and the series designation and locate the old data sheets to identify the ripple current and impedance / ESR ratings. I also measure the old parts dimensionally to make sure the replacements fit. I had a lot of success using Nichicon PW pretty much everywhere in the old switch mode power supplies except I use the Panasonic FM where ultra low impedance and high ripple current are required that exceed the PW specifications. For the SMD parts I use Panasonic FP series.
I recently rebuilt an HP 715, HP 735, Quadra 660av and a Sparcstation 20 (the HPs and the SS20 use tantalums on the main boards so I only needed to worry about their power supplies). The 735 power supply was locally damaged by leaked electrolyte and still appears dead after the initial repair so I must spend some more time troubleshooting it, without any schematics of course. The 715, Quadra and SS20 power supplies were in a good shape with no leaks, damage or even excessive ripple on the output rails. However, upon disassembly, it was clear that some of the output filter capacitors in the SS20 power supply were beginning to leak electrolyte. Even though they were leaking, they still measured fine with respect to capacitance, leakage current and ESR!
If I have a bit of time I will post some more photographs to my flickr account.
HAPPY NEW YEAR!
Welcome to the forums. One thing you might try if you haven't already is using an old 10/100 hub instead of a switch. I was able to get networking going on my cube that way with an old Netgear 10/100 hub. It failed to work with the switches that I had at the time but worked great when I used the hub. Hope that helps.
Hi 68040.
Thanks for your suggestion. I would have tried a hub - but my only one is quite far away (sadly missed more than once...).
But I guess that I got the Cube after my first switch. So it should once have worked with that, although my memory is completely diffuse here. After all, I might have got the Coax-TP-Switch just for that cube just as well back then. Seriously, I don't remember.
At the moment, I've placed the newest Gigabit Ethernet switch onto the desk with the Cube (overkill, no machine over there goes beyond Fast Ethernet), and the older GE onto my desk with the modern machines.
So everything works as well as it can (for now). I'll see when I have the time to do the caps refresher. (Most certainly not before the middle of the year.) And if I remember the hub when going home, I'll try that too - just for completeness...
Thanks again and kind regards! Joerg
Hi all,
I'm new here, just started hunting around for answers to some questions I have with my NextCube, and this one looks familiar. Apologies for reviving an old thread...
I've tried to use the TP network port, and it seems completely dead. I see people having better luck with the thinnet port, and since I meanwhile found that I still have a PCI thinnet card for a PC, I'm going to try that route next.
I see lots of mention of capacitors going bad as a possible cause. How relevant/urgent is it to check/fix those when the board appears to be otherwise working fine? And given that these are apparently SMD, what's the skill level required to do this without ruining things?
WFK