darnold@felix.UUCP (Dave Arnold) (05/25/90)
Rumor has it that DELNI's assert collisions, and may impact network performance. In other words, if the DELNI were attached to a coaxial cable segment, and a LAN analyzer was monitoring collisions, and 9 stations were transmitting (8 on the DELNI, 1 on the cable), much more collisions would be seen with the DELNI than if the 9 stations were just attached to the coaxial cable segment alone. I have heard of this before and all the reports I have heard have just been hearsay. I asked our local DEC tech. rep. about this, and he initially never heard of this problem. But said he would look into it. After doing some research, he called me back and said he didn't know about the collisions, but did say that each port on the DELNI are internally distanced so that the propogation delay parameters are met. (??) And he said problems could result if you cascaded the DELNI's. I still have no hard information regarding this. I do know that the tolerances for Ethernet are narrow. Does anybody have any facts? -------- Dave Arnold - FileNet Corporation 3565 Harbor Boulevard, Costa Mesa, Ca. 92626 PSTN: (714) 966-3906 FAX: (714) 966-3440 Telex: 383902 UUCP: hplabs!felix!darnold
ted@blia.BLI.COM (Ted Marshall) (05/30/90)
If a DELNI is in "global" mode and the transceiver connected to the global port is wired for SQE test (heartbeat), the heartbeat signal is passed down to ALL of the local ports. In other words, when any of the stations finishes a packet transmision, all of the stations on the DELNI see the heartbeat "blip" on collision detect pair. This condition will cause few, if any, problems because most Ethernet stations don't care about collision signals when they aren't trying to transmit. Also, because the blip comes early within the required 9.6us inter-packet gap, stations waiting to transmit shouldn't be affected either. That is NOT to say that there isn't Eathernet hardware on the market today that won't be affected. Devices that don't wait the full inter-packet gap before transmitting or otherwise are brain-dead in terms of following the specifications, for example. Also, anything that isn't a simple station, such as a repeater or bridge, may be affected. Those aren't supposed to be connected to a transceiver that generates heartbeat anyway (I believe). Also, any kind of Ethernet analyzer that counts collisions that is connected to a DELNI will most likely count a collision for each heartbeat it sees. That is, for each transmition by another station on the DELNI. This is generally where rumors about extra collisions generated by DELNIs come from. -- Ted Marshall ...!ucbvax!mtxinu!blia!ted <or> ted@blia.bli.com ShareBase Corp., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000 The opinions expressed above are those of the poster and not his employer.
pat@hprnd.HP.COM (Pat Thaler) (05/30/90)
> > (Comment that repeaters and bridges are not suppose to be connected > to MAUs which generate heartbeat.) There seems to be a common misconception that bridges should not be connected to MAUs with heartbeat. This is not correct. From the point of view of the MAU, the bridge is the same as a DTE. It uses the same media access control method as any other DTE (station, node, or other term of your choice) on the network and has the same need for heartbeat. ("same need" = many DTEs will operate while connected to MAUs which do not produce heartbeat since Ethernet Rev 1 did not have heartbeat.) It is correct that heartbeat should not be sent to repeaters. Pat Thaler
cliff@violet.berkeley.edu (Cliff Frost) (05/31/90)
In article <11702@blia.BLI.COM> ted@blia.BLI.COM (Ted Marshall) writes: > >If a DELNI is in "global" mode and the transceiver connected to the global port >is wired for SQE test (heartbeat), the heartbeat signal is passed down to ALL >of the local ports. In other words, when any of the stations finishes a >packet transmision, all of the stations on the DELNI see the heartbeat "blip" >on collision detect pair. > >This condition will cause few, if any, problems because most Ethernet stations >don't care about collision signals when they aren't trying to transmit. Also, >because the blip comes early within the required 9.6us inter-packet gap, >stations waiting to transmit shouldn't be affected either. But the 9.6us gap is per transmitter. You've got one station that has just sent a packet, and it won't try to send another for 9.6us, but you've got 7 (or 15) other stations that don't know anything about the first station's transmission and may decide to transmit themselves. One of them could easily see the heartbeat "blip" as a false collision. From all the responses I got back to my question I believe this is a compelling reason NOT to use SQE with multiports. Maybe this is why multiports aren't defined in the IEEE specs. Cliff Frost UC Berkeley
rpw3@rigden.wpd.sgi.com (Rob Warnock) (05/31/90)
In article <1990May30.181740.14203@agate.berkeley.edu> cliff@violet.berkeley.edu (Cliff Frost) writes: +--------------- | In article <11702@blia.BLI.COM> ted@blia.BLI.COM (Ted Marshall) writes: | >If a DELNI is in "global" mode and the transceiver connected to the global | >port is wired for SQE test (heartbeat), the heartbeat signal is passed down | >to ALL of the local ports... | But the 9.6us gap is per transmitter. You've got one station that has just | sent a packet, and it won't try to send another for 9.6us, but you've got | 7 (or 15) other stations that don't know anything about the first station's | transmission and may decide to transmit themselves. One of them could | easily see the heartbeat "blip" as a false collision. +--------------- Such as a repeater, which is *required* to do "receiver-based" collision detection, so it can "jam" the other side of the net correctly whenever there's a collision on the front side. Spurious SQEs look like collisions to repeaters, which then proceed to jam up the net. (*Ugh!* *Gasp!* *Gag!*) +--------------- | From all the responses I got back to my question I believe this is a | compelling reason NOT to use SQE with multiports. Maybe this is why | multiports aren't defined in the IEEE specs. +--------------- What's really disgusting is that it takes maybe all of $0.37 worth of parts per port to direct the SQE back to the one port that sent the transmission. All you need is a (non-critical) one-shot and an "AND" gate per port. Other vendors (e.g. Cabletron) can do it; no reason why DEC couldn't have. [Except... they didn't.] -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
haas@cs.utah.edu (Walt Haas) (05/31/90)
In article <2230087@hprnd.HP.COM> pat@hprnd.HP.COM (Pat Thaler) writes: >... >It is correct that heartbeat should not be sent to repeaters. Could you clarify this? Clearly the problem with heartbeat to multiports is that the heartbeat signal will be repeated inappropriately to N-1 ports. In the case of a repeater connected directly to a transceiver which generates SQE, the SQE signal should only appear at the appropriate time as a function of the packet being forwarded through the repeater. The DEMPR in fact requires SQE from its transceiver, otherwise it lights an angry little red light in complaint. -- Walt Haas haas@cs.utah.edu
ted@blia.BLI.COM (Ted Marshall) (06/01/90)
In article <1990May30.181740.14203@agate.berkeley.edu>, cliff@violet.berkeley.edu (Cliff Frost) writes: - In article <11702@blia.BLI.COM> ted@blia.BLI.COM (Ted Marshall) writes: - >because the blip comes early within the required 9.6us inter-packet gap, - >stations waiting to transmit shouldn't be affected either. - - But the 9.6us gap is per transmitter. You've got one station that has just - sent a packet, and it won't try to send another for 9.6us, but you've got - 7 (or 15) other stations that don't know anything about the first station's - transmission and may decide to transmit themselves. One of them could - easily see the heartbeat "blip" as a false collision. Indeed. I hadn't thought that out fully. Sorry about that. -- Ted Marshall ...!ucbvax!mtxinu!blia!ted <or> ted@blia.bli.com ShareBase Corp., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000 The opinions expressed above are those of the poster and not his employer.
rpw3@rigden.wpd.sgi.com (Rob Warnock) (06/01/90)
In article <1990May31.123149.2718@hellgate.utah.edu> haas@cs.utah.edu (Walt Haas) writes: +--------------- | In article <2230087@hprnd.HP.COM> pat@hprnd.HP.COM (Pat Thaler) writes: | >It is correct that heartbeat should not be sent to repeaters. | Could you clarify this? Clearly the problem with heartbeat to multiports | is that the heartbeat signal will be repeated inappropriately to N-1 ports. | In the case of a repeater connected directly to a transceiver which generates | SQE, the SQE signal should only appear at the appropriate time as a function | of the packet being forwarded through the repeater. +--------------- Think a little more about the configuration. Suppose some other station on the DELNI sends a packet, which the DEMPR dutifully repeats (and by the way later gets a SQE at the end of the *transmitted* packet on the other side, which is just fine) and then sees a SQE coming in the *receive* side [due to the brpken DELNI] immediately behind this packet it just received and repeated! "Oops! Collision. Gotta jam!", sez he, and the jam he sends out may or may not cause (some) receivers on one or the other sides to barf on the perfectly good preceding packet, because the jam came in the inter-packet interval. (I have observed this "partial" failure mode.) Repeaters must do receiver-based collision detection, to avoid repeating garbage fragments. Since the data is AC-coupled, a collision may cause parts of bits to "cancel", breaking up the collision interval into micro- intervals of carrier/no_carrier. That's why "carrier-detect" in the station is defined to be the "OR" of carrier-detect and collision. Getting a SQE while *receiving* (on the "front" or DELNI side) is not a good thing. No, the DELNI does it wrong, and DEC is perfectly correct in telling you not to put a DEMPR behind a DELNI. You *could* successfully put a DEMPR behind a "multiport" that did it right... [other vendors' names ommitted] -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311