Another needy student

TiredMan wrote in part:

At least you're honest.

You cannot, because as the cable guy said, they are different things. Do not confuse speed of transmission (aka latency) with amount transferred (aka bandwidth). One is raw speed, the other is payload.

For an interesting contrast, calculate the bandwidth of the Long Beach Freeway, with three lanes of tractor-trailers rolling at 50 mph, spaced 1 sec apart, each carrying a 40 ft container of ~200,000 DVDs from China. Ans: About 3,000,000 GB/s. But the latency is hours or days.

-- Robert

10Base-T implies cables at most 100m long, with multiple segments linked by repeater.

While electricity in the cable travels a

try the calculation.

the other hints you need are that bits are sent serially across the cable, and speed = dist/time.

this

Nope - that limit is specific to 10Base-T (which is what you were asked about - but still, precision is a good thing).

there are other cable types supported for Ethernet, and thick Ethernet co-ax for example supports 500m segments. Fibre links go much further as there are fairly low signal loss rates.

I asked

thruput is not directly related to delay (which another post was hinting at) - treat them as separate properties.

If I know that 10Base-T runs at 10Mbps, and I know

personally - i think whoever asked the Q is completely wrong - they say "how far in the cable" then they talk aobut effective speed including delays thru electronics.

There are two effects occurring at the same time. One is bits being spit out of a source computer, and the other is how long it takes the bits to travel the length of the pipe.

If 64 * 8 = 512 bits are transmitted at 10 Mb/s, the time required to get those bits out the source NIC is 512 / 10E6 = 51.2 usec.

Now these 512 bits are in sequence dumped into a pipe that sucks each bit through at about 2E8 m/sec (or about 2/3 of the speed of light through a vacuum). So how much cable distance do the 512 bits spread over, from first to last, as they are being trickled into the pipe? If it takes 51.2 usec to get all the bits out of the source NIC, that first bit has traveled a total distance of 51.2E-6 * 2E8 = 10,240 meters by the time the last bit has been transmitted out the source NIC. I'm just using the basic equation distance = rate * time.

In other words, the source NIC is slow enough that the first bit is being delivered at the end of the 100 meter cable well before the last bit of that frame has been been sent out at the source side.

At 100 Mb/s, the length of the frame is 1024 meters. At 1000 Mb/s, the length of the frame is 102.4 meters. At 10Gb/s, the length of the frame is 10.24 meters.

Unless I'm misreading something, this c part doesn't make sense. Perhaps what they really mean is the maximum cable length usable with the normal CSMA/CD protocol of a *shared* Ethernet. Not a switched Ethernet, which is presumably full duplex. In a full duplex LAN, no problem. In a shared LAN, instead, a source NIC needs to know when another source somewhere else has started to transmit well before that other source has quit transmitting. If a collision occurs, each offending source needs to be aware that this has happened before it finishes sending its frame. That's the only way these sources know they need to back off and try again. Which means, the round trip distance cannot be shorter than the length of each 64-byte frame.

So, you can't have one source NIC fire off an entire frame, only to discover after the fact that oh by the way, someone else was also transmitting at the same time.

With 10GBASE, you would be limiting the cable length to 10.24 / 2, or

5.12 meters for CSMA/CD, unless you artifically make that 64-byte frame a lot longer. Or just forget about shared Ethernet. Ditto with 1000BASE, by the way. That too requires the shortest frame to be greater than 64 bytes, for half duplex protocol.

Bert

A switched ethernet is only full duplex if both ends of the link operate in full duplex.

I don't know if gigabit switches will support half duplex if the other end asks for it, or if gigabit NICs can be set to ask for it.

-- glen

Thanks for the response Robert. It's one of those things where you just expect your ethernet patch cord and cable to work when you plug it in. There's always more going on than you know.

Robert Redelmeier wrote:

Thanks Glen,

At least you make me feel like I'm not the only one who read this question and said huh.

glen herrmannsfeldt wrote:

glen herrmannsfeldt schrieb:

Gigabit uses carrier extension on half duplex links.

Mirko

So the standard says. Can you find any equipment that actually supports half duplex GigE?

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

That is what I was trying to ask.

It would seem that if one supported it, though, others would also have to support it.

-- glen

I don't think this matters so much in the context of a homework question, though, which is what this was. I think what the instructor was trying to get the students to do is to understand the underlying mechanisms.

Bert

The only half duplex GBE that I have ever heard of is the Cisco GigaStack GBIC.

are IIRC severe cable length limitations (1 metre?). IIRC connection was/is only supported to other identical GBICs.

I can't now figure out why they made it.

Ordering Information - Model Number: WS-X3500-XL (Cisco GigaStack GBIC and 50 centimeter cable for GigaStack GBIC) - Cable: CAB-GS-1M (1 meter cable for GigaStack GBIC)

Came with a 50cm cable.

snipped-for-privacy@hotmail.co.uk wrote: (snip)

There are IIRC severe cable length limitations (1 metre?).

So, no carrier extension?

I used to think it would be useful for clusters where all the machines are close together, and under the control of one central machine. Though gigabit switch prices are low enough that I might not believe that anymore, but maybe now for 10G. Though without carrier extension the cabling might be too short even for a cluster.

-- glen

> There are IIRC severe cable length limitations (1 metre?).

it can run in full duplex mode as well. in 1/2 duplex, you dont get any QoS support acrss the G/stack link.