ethernet hardware question

"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.


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.

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 ?!

This one is most interesting too:

http://www.chipcenter.com/circuitcel...2/c0302ts3.htm

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

TCP does it... They call it throttling... Making UDP reliable is not a
trivial operation. Been there done that. You're better writting a "datagram"
based protocol over TCP if you need "reliable UDP"...

Alex.

I haven't read all those links. Think about what I said. There is no
rocket sience involved. What I mean is simple. As an extrem example
(cause they make things so obviousely clear) say your P133 (or
whatever it was) needs 2 seconds to process the 64K sized non standard
UDP segment. It's obvious that then the "gap time" would be
2seconds. Otherwise it's the roundtrip time. To make things worse,
this round trip time NEVER EVER will be precisely constant. So relying
to it is asking for trouble. I simply don't think that there is too
much sense in createing such pakets unless you say develop some custom
hardware and write low level stuff on both ends (sender and reciveer)
but then you would not even have to stick to UDP. If you choose UDP
for interoperability purposes, stick with the standard packet size
which is 512 bytes or else choose TCP. If your application is
restricted to local lan segments you can get away with such packets
but be prepared that even then you may encounter problems in the
field.

Markus

"Skybuck Flying" wrote in message
...

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

Take a look at how TCP does it.

DS

"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?

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?

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.

Otherwise a card should be able to handle a good fraction of 10 Mbps - thats
only 1.25 Mbyte /sec between the card and memory. If the card is REALLY old
(ie 8 bit AT bus), then 10 Mbps may not be possible between the card and PC
memory.


Alex.

--
Regards

Stephen Hope - remove xx from email to reply

"Markus Zingg" wrote in message
...
I haven't read all those links. Think about what I said. There is no
rocket sience involved. What I mean is simple. As an extrem example
(cause they make things so obviousely clear) say your P133 (or
whatever it was) needs 2 seconds to process the 64K sized non standard
UDP segment. It's obvious that then the "gap time" would be
2seconds. Otherwise it's the roundtrip time. To make things worse,
this round trip time NEVER EVER will be precisely constant. So relying
to it is asking for trouble. I simply don't think that there is too
much sense in createing such pakets unless you say develop some custom
hardware and write low level stuff on both ends (sender and reciveer)
but then you would not even have to stick to UDP. If you choose UDP
for interoperability purposes, stick with the standard packet size
which is 512 bytes or else choose TCP.

i believe you are thinking of the required min packet supported - 512 bytes
of UDP, which with overhead is 550+ bytes

if you stick a sniffer on any ethernet running m$soft networking or NFS you
will see plenty of frames of 1500 bytes carrying UDP, and many of those will
be fragments of bigger UDP packets. 64k is a bit unusual tho.

If your application is
restricted to local lan segments you can get away with such packets
but be prepared that even then you may encounter problems in the
field.

Markus
--
Regards

Stephen Hope - remove xx from email to reply

In article t,
Ben_ wrote:
Hello,

"UDP packets of 512 Bytes are non standard", you say.

Is this limit defined by an RFC or by practices ? Put in another way: what
would happen if an application exceeds this size ? (Sorry if this is silly,
I'm new to UDP :-)

UDP packets larger than 512 bytes are certainly not in any way
"non-standard." It's been almost 20 years since I last heard that
silly canard. Then it was applied to NFS by the salesslugs of
Sun's competitors.

Any IP packet (including TCP/IP and UDP/IP) larger than the MTU of
the path between sender and receiver might be fragmented.
IP fragmentation is undesirable and considered somewhat harmful.
See http://www.google.com/search?q=ip+fr...idered+harmful

It is rare to find a path in the Internet today that has an MTU less
than perhap 1300. I'd say 1500 except for the evils of IPoE.
That means that in practice you can avoid IP fragmentation provided
you keep your UDP/IP packets smaller than 1K.

As others have said, if you don't already know all of this, you'd
probably be better served by using TCP.


Vernon Schryver

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



"Skybuck Flying" 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.

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

"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.


Otherwise a card should be able to handle a good fraction of 10 Mbps -
thats
only 1.25 Mbyte /sec between the card and memory. If the card is REALLY
old
(ie 8 bit AT bus), then 10 Mbps may not be possible between the card and
PC
memory.


Alex.

--
Regards

Stephen Hope - remove xx from email to reply