At 10:49 PM 5/18/02, Brian Hill wrote: > > 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 its 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?
Full duplex is used on a point-to-point link where each side has a dedicated transmit circuit. It's not multiple access (MA). Since it's not MA, the sender doesn't need to sense the carrier first (CS). Collision detection (CD) isn't necessary because the two stations sending at the same time is legal. So full duplex wasn't what I had in mind when I said that slot time is an issue for all CSMA/CD networks. I don't know why you are mentioning it here. The IEEE annex that covered full-duplex (802.3x) probably didn't mention slot time. That annex was rolled into the 802.3 2000 edition, however, which of course does cover slot time since it still covers CSMA/CD, repeaters, etc. (in addition to full-duplex operation.) > > >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. A hub doesn't understand frames, doesn't buffer them, and doesn't rebuild them. It rebuilds bits. It regenerates the signal one bit at a time. It syncs up on the signal by looking at the preamble. It regenerates the preamble (to avoid the problem of the preamble shrinking from repeaters taking time to sync up on it) and forwards the rest of the bits. It also extends fragments that are less than 96 bits (including the preamble). If it has any "RAM," it's only a few bits big. We used to teach the gory details of repeater behavior but that's about all I remember at this time. >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? Well, now we are getting into EE talk. ;-) Everything is analog at some level, isn't it? But an Ethernet repeater works on a Manchester encoded digital signal. (MLT-3 encoding for 100 Mbps). I think your second statement is closest to the truth (that the repeater converts the analog signal into a digital representation and creates a new analog signal). But I don't know the exact details. I'm sorry I was so punchy in the previous message. Priscilla ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44485&t=44408 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
