Look Priscilla, I am not trying to get in a pissing contest here, and I am not trying to "waste bandwidth" (though I don't know if I would worry about that, considering all of the things that flow through the Internet). All I was attempting to do was clarify what I was thinking, and I ADMITTED that you were correct on most of the issues. However, I also know what I have read and been told through the years, and while that doesn't include the original IEEE documents, it DOES include quite a few books, including a number of Cisco books. Perhaps they are wrong and you are right....I am fine with that, but I would like to clarify my understanding if that is the case. Therefore, I will (try) to make some succinct comments on your statements below:
Priscilla Oppenheimer wrote: > > At 07:29 PM 5/18/02, Brian Hill wrote: > > >First, the slot time (64 byte time) isn't much of an issue > unless running at > >100Mbps or faster, and isn't an issue at all running full > duplex. > > Slot time is an issue for all CSMA/CD networks, regardless of > transmission > speed. It is certainly discussed as a fundamental issue in all > versions of > IEEE 802.3 from the first in January 1985. This would be the first time I have heard this statement. I was under the impression that the slot time's primary purpose was to facilitate collision detection. In other words, that the slot time represented the length of time an Ethernet host listened to it's own packet to detect a collision. Is this not true? If it is true, how does the slot time have anything to do with full duplex Ethernet? > >, which necessarily reduces the repeated > >network's diameter, as if a packet collides after the slot > time it becomes a > >late collision, and the original host may not properly detect > the collision. > >I seem to remember that there always being a recommendation, > however, not to > >repeat the packet more than 5 times due to S/N Ratio problems > creeping in > >after amplification. > > I can't find any mention of what you're saying, and I also > question the > premise. Ethernet repeaters do digital regeneration of the > signal. I don't > think they amplify noise. They clean up the digital signal. > Ahah, then I stand corrected yet again. I did a search on this, and found out that an analog repeater simply amplifies the signal, thus retaining any noise caused by attenuation, while a digital repeater actually regenerates the signal, essentially recreating the packet in the process. In most of the books I have read regarding basic Ethernet functionality, they simplify it by claiming that all repeaters simply amplify the original signal, which would retain any noise already present in the original. However, this new information regarding repeating is according to BICSI, which I would assume is correct, and matches up with your statements. > > >As for the switch vs. hub thing, I seem to remember based on > the S/N thing > >that anything that amplified the original signal caused this > problem. > > Regardless, it's completely out of the realm of a discussion on > how > switches behave. Agreed, I was simply trying to explain my original thinking. The thought process was that a switch simply operated on the same principle as a hub, with the exception of the fact that it recognizes and forwards based on MAC. In other words, my thinking was that a switch amplified the signal like a hub, when in truth, neither do...They both rebuild the signal. > > >I also > >remember the distinction that under normal circumstances, the > switch does > >not modify the packet in any way (L3/4 switches and trunking > excluded). > > True, but think about the meaning of the sentence. Layer 2 > switches don't > modify the packet (frame). We aren't talking about signals > here. We're > miles above that. Yes, but I was thinking of the easiest way to do this electrically, again, by amplifying. > > >However, thinking about it, based solely on the switching > mode, it seems > >that all switches (and even a lot of hubs now) buffer the > packet in RAM and > >then forward it, which means, as someone stated, that the > packet is "rebuilt". > > A hub that did that wouldn't really be a hub. The extra delay > would cause a > problem, for one thing. Priscilla, I can't find the logic in this. If the hub doesn't buffer the frame, I don't see any way it could possibly rebuild it. I mean, from what I can tell, either the hub amplifies the original signal (which you and documentation state is untrue), or it has to somehow record the incoming signal (into RAM?) and then send the regenerated signal back out, doesn't it? I am not talking about buffering the entire packet, therby increasing the delay, my thought process was simply that either it sent the signal on, amplifying it, or it stored and analyzed the signal, then forwarded it back out. This is based on my understanding that the signal itself is analog, even if it is represented digitally. In other words, either you can increase the analog signal by running it through a circuit, or you have to convert the original analog signal into a digital representation (+3.12 volts might be determined to be a binary 1 or simply 3 volts, for instance), and then create a new analog signal. I am no EE either, however, so perhaps my thinking is flawed. Is this how "digital" repeating is done? > > Of course a switch rebuilds the frame. Even a cut-through > switch obeys > CSMA/CD rules. Even though it starts forwarding as soon as it > recognizes > the destination address, it does sense carrier first and then > monitor for > collisions and retransmit if necessary. (It does store the > frame, just in > case). We discussed this in great detail a few weeks ago. > Yes, I understand the switching methods, I just wasn't bringing them into the equation. You are right, of course, switches buffer the frame and therefore would always rebuild the signal. > >As for me drinking by the pool, no, I am out of town at present > > At the pool, though? A lot of hotels have pools. ;-) > > Seriously, there's no point in a having a philosophical walk > down memory > lane on this topic. It's still in my locally-used cache, plus I > have > mountains of documentation to back up what I say (not being at > a hotel). LOL. Now that's nice. I wasn't arguing with most of what you said Priscilla, I was actually agreeing with you for the most part. I see no reason for you to berate me on this. Unless, of course, you have the singular distinction of being the only person who ever lived who hasn't made an incorrect statement. I did admit my error, and all I am trying to do now is learn from the major flaw in my thinking that caused me to make the mistake in the first place. I would assume you would be able to appreciate that. Brian Hill Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44471&t=44408 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
