• Whiskey Tango Foxtrot? Over. (At Work) (unregistered)

    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.

  • (cs)
    Alex Papadimoulis:

    "Oh, no, no, no, no," the tech rep said, "our software will not work on a Hewlett Packard server! It *must* be installed on a Dell PowerEdge 4208 Server and the clients *must* be all Dell Optiplex GX150's."

    That didn't make too much sense from a technical perspective (their software ran on Windows), but the higher-ups eventually agreed and all of the computers throughout the department were to be changed out. It wouldn't be that expensive, after all: only like half a million or so.

    Interpretation - It's not the software it has to be the hardware

    Alex Papadimoulis:

    "Well, the problem appears to be that your system is using Ethernet. Our product was designed to be used with Token Rings.

    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>

     

  • (cs)

    It looks like the highly-specialized control software is doing exactly as planned: bleeding the customer dry.

  • (cs)

    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.

  • (cs)
    Anonymous:


    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!
  • YourMother (unregistered)

    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.


  • (cs) in reply to mrsticks1982

    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.

  • (cs)

    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.


  • Unklegwar (unregistered) in reply to YourMother
    Anonymous:
    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.



    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.

  • (cs)

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

  • (cs)
    Alex Papadimoulis:

    "Oh, no, no, no, no," the tech rep said, "our software will not work on a Hewlett Packard server! It *must* be installed on a Dell PowerEdge 4208 Server and the clients *must* be all Dell Optiplex GX150's."

    "Well, the problem appears to be that your system is using Ethernet. Our product was designed to be used with Token Rings.


    It works as coded
  • Unklegwar (unregistered) in reply to pjsson
    pjsson:
    Alex Papadimoulis:

    "Oh, no, no, no, no," the tech rep said, "our software will not work on a Hewlett Packard server! It *must* be installed on a Dell PowerEdge 4208 Server and the clients *must* be all Dell Optiplex GX150's."

    "Well, the problem appears to be that your system is using Ethernet. Our product was designed to be used with Token Rings.


    It works as coded


    Technically, EVERYTHING works AS CODED, no?


  • Unklegwar (unregistered) in reply to Unklegwar
    Anonymous:
    pjsson:
    Alex Papadimoulis:

    "Oh, no, no, no, no," the tech rep said, "our software will not work on a Hewlett Packard server! It *must* be installed on a Dell PowerEdge 4208 Server and the clients *must* be all Dell Optiplex GX150's."

    "Well, the problem appears to be that your system is using Ethernet. Our product was designed to be used with Token Rings.


    It works as coded


    Technically, EVERYTHING works AS CODED, no?



    Ah. I replied THEN read.
    I get it. Duh.
  • Robert (unregistered)

    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.

  • Anonymous (unregistered)
    Alex Papadimoulis:

    Shortly after, however, complaints began to roll in about system instability, missing features, and annoying bugs. As an example: the system didn't have the ability to generate a basic report about cooling system statistics over a given amount of time. This was absolutely mission critical to the water processing.

    Works as coded!

    Alex Papadimoulis:

    After arriving and examining the systems for a while, he returned with a relatively simple answer to all of the problems that were being experienced...

    "Well, the problem appears to be that your system is using Ethernet. Our product was designed to be used with Token Rings.



    Again, Works as coded!
  • (cs)

    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?

  • Anonymous (unregistered) in reply to mrprogguy
    mrprogguy:

    And I'm a little confused here--doesn't the networking API abstract out things like Ethernet vs. Token Ring?



    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?"
  • anonymous (unregistered) in reply to Unklegwar

    Anonymous:
    Anonymous:
    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.



    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.

     

    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.

  • my name is missing (unregistered) in reply to mrprogguy

    WWPD (What would Paula do?)

  • (cs) in reply to mrprogguy
    mrprogguy:

    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?



    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.
  • rocksanddirt (unregistered)

    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.

  • (cs) in reply to mrprogguy
    mrprogguy:

    And I'm a little confused here--doesn't the networking API abstract out things like Ethernet vs. Token Ring?



    Apparently about as well as Windows 2000 abstracted out things like HP and Dell.
  • (cs) in reply to mrprogguy

    mrprogguy:
    And I'm a little confused here--doesn't the networking API abstract out things like Ethernet vs. Token Ring?

    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.

  • Anonymous (unregistered) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    Either way, I'm not sure which case is worse.



    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!"
  • (cs) in reply to Unklegwar

    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.

  • SomeCoder (unregistered) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    Either way, I'm not sure which case is worse.

    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.

  • (cs)

    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.

  • (cs) in reply to Satanicpuppy
    Satanicpuppy:

    Token ring was designed by engineers who couldn't come to terms with that fact.


    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.
  • XMLord (unregistered)

    Well, we had something like that (I'm guessing this is the same company). We just didn't pay anything...
    Suckers!

  • foxyshadis (unregistered) in reply to mrprogguy
    mrprogguy:

    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?


    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.
  • (cs)

    All I want to know: Is how to get into this kind of racket? So that I can retire early...

  • (cs) in reply to jo42
    jo42:
    All I want to know: Is how to get into this kind of racket? So that I can retire early...


    Illegal kickbacks.
  • (cs) in reply to foxyshadis
    Anonymous:
    mrprogguy:

    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?


    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.

    You mean timing loops are not the correct way to synchronize distributed communication?????  *shudders*

    O.o?!

  • l1fel1ne (unregistered)

    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.

  • Anti-Tester (unregistered) in reply to snoofle
    snoofle:

    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?

    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!

  • Darryl Smith, VK2TDS (unregistered) in reply to Satanicpuppy

    Satanicpuppy:
    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.

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

    Satanicpuppy:
    Token ring was designed by engineers who couldn't come to terms with that fact (about random being better)

    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!

  • design (unregistered) in reply to snoofle
    snoofle:

    You mean timing loops are not the correct way to synchronize distributed communication?????  *shudders*

    O.o?!



    #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);
  • (cs)

    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.

     

  • (cs) in reply to Satanicpuppy

    Satanicpuppy:
    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.

    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.

  • (cs)
    Alex Papadimoulis:
    "Well, the problem appears to be that your system is using Ethernet. Our product was designed to be used with Token Rings."

    Turning a multimillion dollar water processing system into a string of Christmas lights?  Brilliant!
  • (cs) in reply to mrprogguy

    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.

  • nobody (unregistered) in reply to my name is missing
    Anonymous:
    WWPD (What would Paula do?)

    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?"

  • (cs) in reply to design
    Anonymous:
    snoofle:

    You mean timing loops are not the correct way to synchronize distributed communication?????  *shudders*

    O.o?!



    #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);

    *forgive me*

    shouldn't that be: const bool ReadyOrNot = FILE_NOT_FOUND     ???

  • Christian Vogel (unregistered)

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

  • bob (unregistered)

    This is classic!

  • (cs) in reply to jsmith
    jsmith:

    Satanicpuppy:
    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.

    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.



    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.

  • John (unregistered)

    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.

  • (cs) in reply to Unklegwar
    Anonymous:

    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.


    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.
  • (cs) in reply to Mike Rod
    Mike Rod:
    jsmith:

    Satanicpuppy:
    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.

    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.



    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.


    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.
  • (cs) in reply to anonymous
    Anonymous:

    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.



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

Leave a comment on “Lord of the Token Rings”

Log In or post as a guest

Replying to comment #87667:

« Return to Article