- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I work in a similar industry, and I must say that stories such as this one are unfortunately common. There are often wars between engineers and architects over the use of COTS software for systems, often because what looks promising by the spec usually ends up costing out the nose... and then you have to deal with vendor lock-in.
Admin
Interpretation - It's not the software it has to be the hardware
Interpretation - It's not the software it has to be the hardware
Thus spake the master programmer:<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>
"When the program is being tested, <o:p></o:p>
it is too late to make design changes."<o:p></o:p>
Admin
It looks like the highly-specialized control software is doing exactly as planned: bleeding the customer dry.
Admin
Oh, your electricty comes from a Gas fired plant... Our software only works on electricty from a Coal fired plant.
You'll have to change that.
Admin
nice ... it's sad when you can sum up the greed that occurs in software sales or injury lawyers hearts in one comic! dugg! oh wrong site!
Admin
I think this WTF should be attributed to the company that made the purchase in the first place.
They put in a million dollar purchase order without making sure it was going to work with the computers they had in the office? And then, when the install gets botched, they just shell out more money to replace all the servers and clients, instead of making the local contractors fix it? Give me a break.
The punchline about the token ring network is cute, but as long as they didn't fasely claim it work over ethernet, how is that the consultant's problem? I don't know anything about token ring networks but I bet there is a performance reason, given that the software captures sensor data.
Look, consultants will bleed you dry, I just don't think this is what happened in this case.
Admin
Let me get this straight. They had something working, presumably relatively trouble free, for a quarter of a century, and did a complete system replacement without a (thorough) parallel testing phase?
While the software company was sleazy at best (for not divulging/providing proper h/w, s/w specs up front), the water company managers have to take some of the blame for this fiasco.
Admin
I used to work for a specialized control software company. Our product was a little better than that, but not by much.
When I first started working there, they we're using DEC Alpha's with the VMS operating system. They were just porting (most of) the codebase to Linux/Java when I left the company.
Admin
I understood that the terminals had to be token ring. Not the sensors.
Token Ring Lite:
The network topology is a logical "circle". On that circle exists a "token". Think of it like a microphone. Only the terminal with the "token" can talk. That's right, one at a time. When a terminal is done with the token, it gets passed around the ring, until it gets to another terminal that needs to talk. It then takes the token, says it's thing to the server, and passes it on.
It's been since 1995 and my work on AS/400 that I was exposed to token ring. If I'm not mistaken, terminals can't talk to each other except thru the server. But I was a programmer, not a tech. So my interpretation might not be 100% accurate (and I slept thru Networking 101 in school, not my fault, it was the Benadryl). I'm pretty sure on the token passing /talking part tho.
I didn't even know you could DO token ring on a PC. Surprised it didn't need punch card readers and reel to reel too.
Admin
"...<font face="Tahoma" size="-1">One [Token] Ring to bring them all and in the darkness bind them..." </font><font face="Tahoma" size="-1">
Indeed!
I am sure that when you hear or read something like this, you think "Geez, I could get that job done for a lot less money!" But think about it - could you really get all that hardware, software, and networking to not work together in that short of a time? It takes a big company to get such a complex system not functioning!
</font>
Admin
It works as coded
Admin
Technically, EVERYTHING works AS CODED, no?
Admin
Ah. I replied THEN read.
I get it. Duh.
Admin
I didn't even know you could DO token ring on a PC. Surprised it didn't need punch card readers and reel to reel too.
In a previous job, I had token ring running on a bunch of PCs in the mid 1980's, using IBM cables and hubs. With sensors sending data in a network, TR would provide more stable throughput although Ethernet doesn't seem like such a big jump.
Admin
Works as coded!
Again, Works as coded!
Admin
At first I thought they were going to say that the system couldn't run under HPUX--and believe me, very little does. Our software, which compiles under Windows, Solaris, Unix, Linux, and AIX, still has to under go special re-compilation at the customer site for HPUX.
And I'm a little confused here--doesn't the networking API abstract out things like Ethernet vs. Token Ring?
Admin
Yes, but I bet a good chunk of the $$ went into redefining a network model to subvert that.
captcha = hacker "I'm a hacker, he's a hacker, wouldn't you like to be a hacker too?"
Admin
The story only makes sense if the sensors are nodes on the token ring. The app server will abstract the network topology out (of course, you have to configure it properly), so only the collection processes can be dependent on the topology.
Making the sensors rely on a token ring is goofy, because one of the issues I remember from my early 90's use of them is, if a node unexpectedly drops off, the whole ring will come down. So, you never put a token ring anywhere near where actual work got done, for fear of jostling a cable or something.
Admin
WWPD (What would Paula do?)
Admin
It certainly should but I presume if you're real enterprisey, you can still build on its side effects. Say, the server expects packets from the clients in the ezact order the ring is built. Or something like that, I don't really know Token Ring.
Admin
All this does is wish I spent all of those hard years learning to become a good designer, and wish I spent those years polishing my ability to convince someone to give me 2.5 million+ and convince them theyre getting a good deal.
Admin
Apparently about as well as Windows 2000 abstracted out things like HP and Dell.
Admin
I asked Brandon this as well; he wasn't directly involved with the consultant, but he suspects that both the "must use Dell XYZs" and "not token rings" are exuses as to why the SW doesn't work. These excuses satisfied management enough to buy more upgrades or time while the SW company could build a new version.
However, in theory, one could develop his own low-level network routines that would be buggy on Ethernet and not Token Ring. That might also explain the "specific server" thing, but who knows.
Either way, I'm not sure which case is worse.
Admin
Depends on if you're the customer, the equipment provider, or the software contractor. :P
captcha = truthiness .. "This software doesn't have enough 'truthiness' to it!"
Admin
TCP/IP is more effcient than Token Ring, even though its completely haphazard. Token ring systems have zero collisions, because only one system can talk at a time. Well, TCP/IP systems have decent numbers of collisions, which requires that the system resend the packets that collided...Well, it turns out that this is hugely more efficient than trying to actually traffic control the packets.
There is a similar problem dealing with page faulting in memory registers...When you page fault, how do you pick the best register to clear, so that you won't have to page fault again, and bring the same data back in. The best way to do it is purely hypothetical...Clear the register whose data is going to be needed again after the data in all the other registers. Can't be done, due to the fact that software can't predict the future (without a hell of a lot of process overhead).
Well the next best ways are: "Least Recently Used" and "Random". That's right. Random. Throwing out a random register is more efficient than almost any other method.
Token ring was designed by engineers who couldn't come to terms with that fact.
Admin
Agree 100%. Either they wrote their own low level APIs for network connectivity (and wrote it for Token Ring only) or they are just making excuses for why their software blows. Either way, it's a huge WTF. And I also agree that the company deserves some of the WTF for just blindly buying new software.
Also, Token Ring can run on PCs easily.
Admin
As the almighty Dilbert once said:
"There's the problem... the Token Ring has fallen out of the network... maybe it's in the Ethernet?"
This has one of two scenarios: They were buying time, in which case the consulting company is sleaze since they're sucking capital out of "victim" companies with the vague possibility that one day they'll deliver what was promised. OR: Their version of the networking API honestly, truely, praise-be-to-God, swear-on-a-stack-of-GOF-books did not support multiple platforms/network-types, in which case the consulting company is sleaze (for sucking captial out to upgrade their own defective products) and idiotic for not designing their API properly the first time.
Either way you look at it, the consultants were sleaze.
But then, not everyone falls victim to Pyramid scams, do they? *casts a shame-indicuing eye on the manufacturing company* Some people just shouldn't have that much money to throw away.
Admin
Although as far as I can remember there's mathematical proof that systems working with Ethernet's random conflict resolution are significantly less prone to starvation than those using round-robin.
Admin
Well, we had something like that (I'm guessing this is the same company). We just didn't pay anything...
Suckers!
Admin
Not if your systems are playing timing tricks relying on 4 Mbps thoroughput. The pain. At least they didn't also specify that it had to run on 1990-era systems as well, since too-fast systems are well known to cause crashes in horribly miscegenated software.
Admin
All I want to know: Is how to get into this kind of racket? So that I can retire early...
Admin
Illegal kickbacks.
Admin
You mean timing loops are not the correct way to synchronize distributed communication????? *shudders*
O.o?!
Admin
Sounds like they should be entertaining litigation against the contractors. Chances are the contracters are covered by the small print in the agreement, in which case its managements fault for not reading the terms, and re-negotiating them.
When you are dealing with contracts of this size, you negotiate the terms so that payment is upon delivery of a working system as they promised. I was first vexed why it took almost 2 months for my manager to hammer out favourable contract terms with a vendor, and it's cases like this that remind me how easily we could have been taken if that hadn't been done.
Admin
Testing is for sissies. Why would you want to be safe and test something first or look at the specs to make sure it works when you could just drop it striaght into an active environment? Now that's excitement for you!
Admin
This is a much bigger DailyWTF to me than the main article. Sorry to the author, but it is true. TCP/IP is at a different layer than Token Ring. Token Ring is a different type of getting the data around, similar to the random access of what is commonly called Ethernet. However Token Ring is one of the three forms of basic Ethernet, with what is commonly known as Ethernet being CSMA/CD.
CSMA/CD will generally detect collisions and resend at that level, not requiring the TCP/IP timers to trigger for a retry.
CSMA/CD is *NOT* hugely more efficient than Token Ring. They are different. Standard CSMA/CD Ethernet will not work once the utilization of a link gets above 70% from memory. The system just falls over. Token ring however continues to work right up to 100%.
Sometimes random is NOT better. In CSMA/CD Ethernet random means that it is theoretically possible that a packet will be delayed by a few seconds following multiple collisions. If you are trying to control equipment in a plant using a distributed control system that is a BAD thing!
Admin
#define ONE_MISSISSIPI (ONE_SECOND)
#define TWO_MISSISSIPI (ONE_MISSISSIPI + ONE_SECOND)
#define THREE_MISSISSIPI (TWO_MISSIPPI + ONE_SECOND)
.
.
.
count(ONE_HUNDRED_MISSISSIPPI);
const bool ReadyOrNot = true | false;
hereIcome(ReadyOrNot);
Admin
Several folks have already touched on this, but the major difference between token-passing networks and CDMA networks (like Ethernet) is that the token-passing network has easily characterized worst-case behavior in terms of latency and throughput. Token Ring wasn't at all efficient in using the available bandwidth, but it was very predictable.
On an Ethernet network, it's not possible to predict exactly how long it'll take for one node to send a message to another. On Token Ring, you just wait for your turn and send your packet, and it'll get to the destination before the next time you get the token back.
On a network with real-time constraints on data transfer (like those sensor readings), it makes a lot of sense to use a deterministic network. Of course, now that you can make an Ethernet network that's at least 50 times faster than high-speed Token Ring ever was, the worst-case behavior on Ethernet is probably almost always better than the best case with Token Ring.
Admin
I hope that's a typo..... TCP/IP is a higher level protocol that Token Ring. TCP/IP works just fine over both Ethernet and Token Ring.
Now assuming you meant "Ethernet" instead of "TCP/IP", I understand your argument. However, as the number of nodes increases, the probability of Ethernet collisions goes up at a rate of the number of workstations squared. As the number of workstations on a Token Ring network increases, the delay due to token passing goes up proportionally to the number of workstations. The end result is that larger networks run more efficiently on Token Ring. Also, for sensor networks, the maximum latency is mathematically guaranteed on Token Ring. If a few Ethernet clients get real busy, it may make the network approach 100% collisions. Any sensor data that can't get through will be lost forever.
Good Ethernet switches will lessen the problem, but they still have a maximum backplane throughput.
Also someone said "On Token Ring, all the packets go through the server". True, with Token Ring, all the packets go through all of the computers, including the server. However, it's not a single point of failure system. Token Ring works just fine on a peer to peer network without a server. I used to teach a network troubleshooting class and it was very difficult to make a Token Ring stop working at the hardware level. If any station wasn't functioning properly, it was automatically removed from the network and all the other systems worked just fine. Token Ring seems fragile at a glance but turns out to be very robust in practice. What really killed Token Ring was the price. Back when Ethernet was coming down to about $30 a card, Token Ring was still well over $100. Ethernet hubs were dirt cheap and Token Ring MAUs were several hundred dollars for just eight ports. Token Ring over UTP with RJ45 connectors helped a bit, but it was too little too late.
Admin
Turning a multimillion dollar water processing system into a string of Christmas lights? Brilliant!
Admin
I think that part of the problem with hp-ux is that is doesn't ship with a full compiler, the one it ship with is only sufficient to do the kernel.
Admin
She would get the brillant idea of subverting the abstraction layers of not only the protocol stack, but the entier HAL.
captcha: clueless. "What? you say we must buy new servers, workstations and networking infrastructure for the entier department so we can run this million dollar software?"
Admin
*forgive me*
shouldn't that be: const bool ReadyOrNot = FILE_NOT_FOUND ???
Admin
I remember these things from when I was working for a company that would install and service networks (cables, switches, routers, firewalls...).
Most often, we were called because "the network is slow" (100 MBit connection to switches/routers meshed with gigabit).
Another favourite of mine was ip-based control of some widespread industry applications, spanning several sites, but not able to work with sensors and actors sitting on different ip-networks. So we had to resort to strange tunneling and bridging tricks so that machinery spread over the whole country appeared in one single network.
Fragmentation of IP-packets when connecting networks with difrerent MTU (maximum packet sizes) like token ring, ethernet, fddi, arcnet (only once) was also a source of infinite joy.
I had nothing but contempt for many of those companies and their ill-designed products. (Or very well designed - from the viewpoint of maximized effort and cost). Their experts often had to be hit with a cluestick by explaining packet traces very, very, very slowly to them, being unaware of basic network terminology and very well versed in producing pretty interfaces to their product that worked oh so well in the "lab"....
Admin
This is classic!
Admin
I agree with almost everything here but I didn't know about the part in bold. Because, you know, I picture a circle topology, so if a part of the circle is missing or broken...
Also, there are other TR network topology with redundancy, imagine 2 circles with one token going clockwise and another token (in another, parallel cable) going counter-clock wise. Maybe it would make sense in this kind of system.
Mike Rod.
Admin
How about this possibility; a network transmission from a sensor may not be interupted because the server software could not handle multiple interleaved requests, such as 'A1', 'A2', 'A3', 'B1', 'A4', 'B2', 'B3', 'B4'; becuase whenever it got a '*1' packet, it threw out whever incomplete request it had before, or upon reciept of a '*4' packet it closed the current entry.
With a token ring network, each sensor would be able to transmit it's payload without having to add job/sequence information to each packet, and the server would recieve those packets, and only those packets, in uninterupted order.
Perhaps the software required particular hardware (Dell) becuase it was programmed to manipulate the BIOS settings to disable HyperThreading, and/or multi-core.
Admin
3COM's 3C359 was a pretty common PCI token-ring card. I think I may have actually run across one or two, as an intern pulling apart old PCs in the late nineties.
Admin
IIRC (never worked heavily with Token Ring), the MAU took care of creating the physical ring, much like the hub/switch take the place of the length of coax cable (properly terminated at each end) that every node of an Ethernet network used to be connected to.
Admin
"Physically, a token ring network is wired as a star, with 'hubs' and arms out to each station and the loop going out-and-back through each."
http://en.wikipedia.org/wiki/Token_ring
The physical ring topology has been obsolete for a long time.