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. It is also discussed in Ethernet Version 2.0 from 1982. In fact, hold it here...... I also have a copy of the Ethernet memo written by Bob Metcalfe in 1973. (This is the memo where the term Ethernet was first used. It's more than a "memo." It's the actual specs.) Yes, it talks about slot time too. Oh, and here's the original patent from 1977. Yup, in there too. The 5-4-3 "rule" came about when people were trying to design 10Base5 networks, i.e. 10 Mbps with 500-meter thick coax segments in the 1970s and 1980s. The "rule" was an oversimplification of the actual requirements to help people design networks with Ethernet repeaters while maintaining the 512 bit slot time. Nobody used the term "full duplex" or "half duplex" in a conversation having to do with Ethernet. Ethernet was multiaccess. Stations sensed the carrier before sending, and there was a goal that only one station should send at a time, so that's sort of like half duplex, which was a phrase mostly used to characterize a two-wire point-to-point connection between a terminal and a host. The term "half duplex" wasn't used to describe Ethernet until the full-duplex interfaces started popping up. Half duplex was applied retroactively to the older types of interfaces that did normal CSMA/CD. (I just checked the Ethernet Version 2 specification and the original IEEE 802.3 specification and couldn't find any mention of the phrase "half duplex." I don't have them in soft copy though, so I'm limited to the scanning my eyes can do.) >As I >remember it, the problem with the slot time is that at 100Mbps, the slot >time drops to something like 5.12 ms The slot time is 5.12 microseconds for 100 Mbps Ethernet. That is indeed an issue. That's why it's rare to implement 100 Mbps Ethernet with repeaters. >, 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. >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. >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. >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. 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. >So, I agree with most of what you have said after all, with the exception of >the S/N ratio having nothing to do with it. I do remember reading that the >S/N ratio degradation was an issue after many amplifications of the original >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). Unless we get into the bowels of the physical sublayers, in which case I will relinquish my nerd hat, not being an electrical engineer, I respectfully suggest that discussing the other issues is a waste of bandwidth. Priscilla >, and just >rattled off the reply. As I hope I have shown, I did have reasons for what I >said, just perhaps the weren't thought out well enough. > >Brian Hill >CCNP, CCDP, MCSE 2000 (Charter Member),MCSE+I (NT4.0), >MCSA (Charter Member), MCP+I, MCP(21), Inet+, Net+, A+ >Lead Technology Architect, TechTrain >Author: Cisco, The Complete Reference >http://www.alfageek.com ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44467&t=44408 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
