ethernet hardware question

On Tue, 21 Oct 2003 09:03:55 +0200, Skybuck Flying wrote:


Indeed... I didn't know about gap's and transmission times... His remark
about the gap sent me in the right direction.

I know believe 10 mbit ethernet is 10.000.000 bits/sec. Each bit takes 100
nanoseconds to send.

So if one has to send 64.000 bytes... and one wants to receive 64.000 bytes
as well... and the cards are half duplex

Then the calculation is as follows:

64.000 bytes * 8 bits * 100 nanoseconds / (1000 * 1000) = 51.2
milliseconds...

This is a rough estimate...

The idea is my software should no longer try to keep sending, sending,
sending... but it should wait a little bit so it can receive 64 kb.

So the idea is to wait 51.2 milliseconds or maybe even 102.4 milliseconds...
to allow the card and the stack to receive a packet.

This is difficult to achieve in some hardware, and not required at all.
Ethernet hardware imposes a gap between frames with a slight randomising,
so that after a frame is finished, everyone has a roughly equal chance of
being able to send the next frame. You can attempt to send as fast as you
like - unless you have a faulty Ethernet adapter, you will not fully block
everyone else who is trying to send.

Steve.

On Mon, 20 Oct 2003 18:23:16 -0600, Vernon Schryver wrote:

In article cu_kb.191087$%h1.182820@sccrnsc02, DaveW wrote:

If you try sending from both computers at once you get packet collisions and
nothing gets thru.

That's utter drivel.


Vernon Schryver

Correct, but impolite.

Ethernet controllers are well able to cope with two people wanting to send
at the same time. They will not begin to send if another machine is
already sending - they wait. And if 2 machines start to send at exactly
the same time, they detect this, back off and try again after a random
delay. Same way as people talking in a group of friends.

Steve

In article , "Steve Horsley" writes:
On Mon, 20 Oct 2003 18:23:16 -0600, Vernon Schryver wrote:

In article cu_kb.191087$%h1.182820@sccrnsc02, DaveW wrote:

If you try sending from both computers at once you get packet collisions and
nothing gets thru.

That's utter drivel.


Vernon Schryver

Correct, but impolite.

Ethernet controllers are well able to cope with two people wanting to send
at the same time. They will not begin to send if another machine is
already sending - they wait. And if 2 machines start to send at exactly
the same time, they detect this, back off and try again after a random
delay. Same way as people talking in a group of friends.

I thought the context was a full duplex 100 meg Ethernet between
two workstations with a UTP crossover cable.

In that environment there is no back off and try again logic. There
are no collisions. The sender just sends. If both ends want to
send at the same time they are free to do so. If one end cannot
receive at the same time that it is sending then that end is broken.

Apologies if I have failed to monitor changing context.

John Briggs

In article ,
Steve Horsley wrote:

...
This is difficult to achieve in some hardware, and not required at all.
Ethernet hardware imposes a gap between frames with a slight randomising,
so that after a frame is finished, everyone has a roughly equal chance of
being able to send the next frame.

That is wrong. As a painful proof of how wrong it can be, look for
"Ethernet Capture Effect" as in
http://www.google.com/search?q=%22Et...ture+Effect%22


You can attempt to send as fast as you
like - unless you have a faulty Ethernet adapter, you will not fully block
everyone else who is trying to send.

That's close enough to true. In practice and contrary to 100VG
and token ring salescritters and various trade rag espurts, CSMA/CD
is pretty fair.


Vernon Schryver

"Steve Horsley" wrote in message
news
Ethernet hardware imposes a gap between frames with a slight randomising,
so that after a frame is finished, everyone has a roughly equal chance of
being able to send the next frame.

AFAIK, there is a random delay after a collision, in addition to the
interframe gap (96 bit-times?). Transmission is delayed until the end of a
"passing" frame, if there is one, but then no longer than the interframe gap
requires - no random element. This way gives better performance under light
loads, because there's a good chance of there being only one transmitter.
But under heavy loads, a random delay (as you described) is preferable; a
collision is virtually guaranteed.

Alex

In article ,
Alex Fraser wrote:
"Steve Horsley" wrote in message
news
Ethernet hardware imposes a gap between frames with a slight randomising,
so that after a frame is finished, everyone has a roughly equal chance of
being able to send the next frame.

AFAIK, there is a random delay after a collision, in addition to the
interframe gap (96 bit-times?). Transmission is delayed until the end of a
"passing" frame, if there is one, but then no longer than the interframe gap
requires - no random element. This way gives better performance under light
loads, because there's a good chance of there being only one transmitter.
But under heavy loads, a random delay (as you described) is preferable; a
collision is virtually guaranteed.

No, there is not and should not be a random delay between back-to-back
transmissions except when the MAC is too slow to keep up. Decades
ago salescritters of makers of lame and broken Ethernet hardware would
claim that non-broken hardware from Sun and other vendors was broken
because it had no such mythical delay between back-to-back packets.

Such a random delay would do no good unless it were on the order of
a slot time or 64 bytes. Contrary to decades of nonsense and blarney,
profitably preventing collisions is not as easy as that. A random
delay shorter than a slot time would not be long enough to ensure that
a second station would get a chance to start transmitting before the
transmitter of the previous packet.

Standards conformant CSMA/CD systems start transmitting their next
packet immediately after their previous packet.

The venerable AMD LANCE violated the Ethernet and 802.3 standards by
delaying after defering to another station. That obscured the Ethernet
Capture Effect for many years and gave significantly better performance.
In cocktail party conversation terms, that non-standard or excessive
politeness let a speaker run down completely and avoided frustrating
a second speaker or group of speakers so much that they give up leave.


Vernon Schryver

Skybuck Flying" wrote in message
...

"shope" wrote in message
...
"Skybuck Flying" wrote in message
...

"Sin" wrote in message
...
I have two computers connected to each other via 10 megabit
ethernet
cards
and UTP cross over cable.

My question is the following about ethernet :

Is ethernet able to send and receive packets at the same time ?

Or should each card wait until it's clear to send ?

I'm asking this since I am testing something that has to do with
winsock.

Large udp packets of 64 kb.

If my slow p166 and my fast PIII 450 both start sending large udp
packets
of 64 kilobyte... it seems like the P166 or the P450 can't receive
anything
anymore...

Something like that I am not 100% sure.

Try sending something easy the other way during the transfer - ping
maybe?

I am not sure but it seems that fails as well.


If the sending card cant handle inbound packets during transmit then
there
may be something wrong with the driver or the IP stack. Or maybe your
send
routine doesnt release any CPU?

Could be that winsock tries to send the 64 kb in packets of 1500 bytes and
forgets to receive as well.


The other possiblity is that the software chokes on such a large UDP
packet
(i seem to remember some isues with bigger than 32k -1 byte packets to
do
with 16 bit arithmetic) - try some smaller sizes if you can tune it.


As the other poster said duplex mode dictates that. On the other
hand,
UDP
is by nature an unreliable protocol so you can't expect all of the
packets
to reach their destination in a context where all those packets are
important to the communication at hand.

If the cards are pretty old then they are probably half duplex. If you
want
to force this then put an Ethernet repeater / 10M only hub between the 2
PCs.

A host sending to a much slower host is one of the situations where
there
will be high packet loss if the packets have no gap between each
other.

Hmm.. very interesting... I wonder what the formula would be for
calculating
the right gap time ?!

The sending ethernet card and driver should impose the minimum Ethernet
inter packet gap on the transmission - around 10 uSec.

it isnt the gap so much as "reset time" in the software driver. Some old
cards (3Com 3c501) had to have the driver chip reset each time they
recieved
or sent a packet - if the next one arrived during the "dead time" then
it
was lost.

Indeed... I didn't know about gap's and transmission times... His remark
about the gap sent me in the right direction.

I know believe 10 mbit ethernet is 10.000.000 bits/sec. Each bit takes 100
nanoseconds to send.

So if one has to send 64.000 bytes... and one wants to receive 64.000
bytes
as well... and the cards are half duplex

Then the calculation is as follows:

64.000 bytes * 8 bits * 100 nanoseconds / (1000 * 1000) = 51.2
milliseconds...

This is a rough estimate...

The idea is my software should no longer try to keep sending, sending,
sending... but it should wait a little bit so it can receive 64 kb.

So the idea is to wait 51.2 milliseconds or maybe even 102.4
milliseconds...
to allow the card and the stack to receive a packet.

Well I wrote a simple program to test this idea.

It sends and receives a 64000 byte packet with winsock...

On the pentiumIII 450 mhz it takes around 3200 microseconds to send it.
On the pentiumIII 450 mhz it takes around 1500 microseconds to receive it
( from the PentiumI 166 )

On the pentiumI 166 mhz it takes around 16000 microseconds to send it.
On the pentiumI 166 mhz it takes around 10343 microseconds to receive it.
( from the PentiumIII 450 )

When I press the send button on both computers repeatedly at the same
time...

The send interval increase to almost double the time.

Still these times do not make much sense when one calculates it.

64000 bytes / 1500 bytes = 42.666 packets.

42.666 * 1526 bytes * 8 bits = 520874.6667

( 520874.6667 * 100 nanosecs ) / 1000 = 52087.4 microseconds.

So in theory it would take 52 milliseconds to send a 64000 byte packet over
a 10 million bit ethernet card.

Yet winsock will show 3 milliseconds.

( 10 mbit Ethernet is 10.000.000 bits per sec right ? not 10*1024*1024 bits
per sec ? anyway that wont matter much. )

So from this I can concluded two things:

1. Winsock returns from the sendto function faster than the packet is
send....

2. When both sides start sending at the same time it will take more time to
send. Why that is I am not sure... maybe because the CPU has to process
incoming packets etc.

Also these tests were done while running zone alarm pro 4.x firewall on both
computers.

"Skybuck Flying" wrote in message
...
Skybuck Flying" wrote in message
...

"shope" wrote in message
...
"Skybuck Flying" wrote in message
...

"Sin" wrote in message
...
I have two computers connected to each other via 10 megabit
ethernet
cards
and UTP cross over cable.

My question is the following about ethernet :

Is ethernet able to send and receive packets at the same time ?

Or should each card wait until it's clear to send ?

I'm asking this since I am testing something that has to do with
winsock.

Large udp packets of 64 kb.

If my slow p166 and my fast PIII 450 both start sending large
udp
packets
of 64 kilobyte... it seems like the P166 or the P450 can't
receive
anything
anymore...

Something like that I am not 100% sure.

Try sending something easy the other way during the transfer - ping
maybe?

I am not sure but it seems that fails as well.


If the sending card cant handle inbound packets during transmit then
there
may be something wrong with the driver or the IP stack. Or maybe your
send
routine doesnt release any CPU?

Could be that winsock tries to send the 64 kb in packets of 1500 bytes
and
forgets to receive as well.


The other possiblity is that the software chokes on such a large UDP
packet
(i seem to remember some isues with bigger than 32k -1 byte packets to
do
with 16 bit arithmetic) - try some smaller sizes if you can tune it.


As the other poster said duplex mode dictates that. On the other
hand,
UDP
is by nature an unreliable protocol so you can't expect all of the
packets
to reach their destination in a context where all those packets
are
important to the communication at hand.

If the cards are pretty old then they are probably half duplex. If you
want
to force this then put an Ethernet repeater / 10M only hub between the
2
PCs.

A host sending to a much slower host is one of the situations
where
there
will be high packet loss if the packets have no gap between each
other.

Hmm.. very interesting... I wonder what the formula would be for
calculating
the right gap time ?!

The sending ethernet card and driver should impose the minimum
Ethernet
inter packet gap on the transmission - around 10 uSec.

it isnt the gap so much as "reset time" in the software driver. Some
old
cards (3Com 3c501) had to have the driver chip reset each time they
recieved
or sent a packet - if the next one arrived during the "dead time" then
it
was lost.

Indeed... I didn't know about gap's and transmission times... His
remark
about the gap sent me in the right direction.

I know believe 10 mbit ethernet is 10.000.000 bits/sec. Each bit takes
100
nanoseconds to send.

So if one has to send 64.000 bytes... and one wants to receive 64.000
bytes
as well... and the cards are half duplex

Then the calculation is as follows:

64.000 bytes * 8 bits * 100 nanoseconds / (1000 * 1000) = 51.2
milliseconds...

This is a rough estimate...

The idea is my software should no longer try to keep sending, sending,
sending... but it should wait a little bit so it can receive 64 kb.

So the idea is to wait 51.2 milliseconds or maybe even 102.4
milliseconds...
to allow the card and the stack to receive a packet.

Well I wrote a simple program to test this idea.

It sends and receives a 64000 byte packet with winsock...

On the pentiumIII 450 mhz it takes around 3200 microseconds to send it.
On the pentiumIII 450 mhz it takes around 1500 microseconds to receive it
( from the PentiumI 166 )

On the pentiumI 166 mhz it takes around 16000 microseconds to send it.
On the pentiumI 166 mhz it takes around 10343 microseconds to receive it.
( from the PentiumIII 450 )

When both firewall are down the times are at best:

On the pentiumIII 450 mhz it takes around 2171 microseconds to send it.
On the pentiumIII 450 mhz it takes around 578 microseconds to receive it
( from the PentiumI 166 )

On the pentiumI 166 mhz it takes around 8975 microseconds to send it.
On the pentiumI 166 mhz it takes around 2769 microseconds to receive it.
( from the PentiumIII 450 )


When I press the send button on both computers repeatedly at the same
time...

The send interval increase to almost double the time.

Still these times do not make much sense when one calculates it.

64000 bytes / 1500 bytes = 42.666 packets.

42.666 * 1526 bytes * 8 bits = 520874.6667

( 520874.6667 * 100 nanosecs ) / 1000 = 52087.4 microseconds.

So in theory it would take 52 milliseconds to send a 64000 byte packet
over
a 10 million bit ethernet card.

Yet winsock will show 3 milliseconds.

( 10 mbit Ethernet is 10.000.000 bits per sec right ? not 10*1024*1024
bits
per sec ? anyway that wont matter much. )

So from this I can concluded two things:

1. Winsock returns from the sendto function faster than the packet is
send....

2. When both sides start sending at the same time it will take more time
to
send. Why that is I am not sure... maybe because the CPU has to process
incoming packets etc.

Also these tests were done while running zone alarm pro 4.x firewall on
both
computers.

Also my UDP Full Duplex Speed Test shows the same results as my in
development application.

If both sides try to send at 500.000 bytes per sec and data size is 64000.

Then the pentiumIII 450 will send at 500.000 bytes per sec and the pentiumI
166 will receive at 500.000 bytes per sec

But

The pentiumIII 450 will receive at 122 bytes per sec and the pentiumI 166
will send at 122 bytes per sec
( little stats packets )

It seems like the pentium 166 is not able to send large packets anymore...

( this test was also with both firewalls on )

"Vernon Schryver" wrote in message
...
In article ,
Alex Fraser wrote:
AFAIK, there is a random delay after a collision, in addition to the
interframe gap (96 bit-times?). Transmission is delayed until the end of
a "passing" frame, if there is one, but then no longer than the
interframe gap requires - no random element. This way gives better
performance under light loads, because there's a good chance of there
being only one transmitter. But under heavy loads, a random delay (as
you described) is preferable; a collision is virtually guaranteed.

No, there is not and should not be a random delay between back-to-back
transmissions except when the MAC is too slow to keep up. [...]

True, but who mentioned back-to-back transmissions?

Such a random delay would do no good unless it were on the order of
a slot time or 64 bytes. [...] A random delay shorter than a slot time
would not be long enough to ensure that second station would get a chance
to start transmitting before the transmitter of the previous packet.

Indeed, less than one slot time is surely pointless.

Standards conformant CSMA/CD systems start transmitting their next
packet immediately after their previous packet.

Yes, if you include the interframe gap as part of the frame it follows. AIUI
the interframe gap has nothing to do with arbitration (it can't for the
reason you give above), but is there for the benefit of the receiver; a
slight "breather" to allow it deal with the previous packet and prepare for
another.

Alex