ethernet hardware question

  • Thread starter Thread starter Someone Somewhere
  • Start date Start date
S

Someone Somewhere

Skybuck said:
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 ?
Click to expand...

Depends whether they are running full duplex mode. Have you made sure
both NIC's are set to the same setting and they are not relying on auto
negotiation?
 
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.
 
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.
Click to expand...


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.

Alex.
 
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 :
Click to expand...

You really should be asking in comp.dcom.ethernet, as your questions don't have
anything to do with TCP/IP, and have everything to do with ethernet data
communications.


[snip]
--
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group

(Opinions expressed are my own, not my employers')
 
Sin said:
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.
Click to expand...

Hmm.. very interesting... I wonder what the formula would be for calculating
the right gap time ?! :D
 
Someone Somewhere said:
Depends whether they are running full duplex mode. Have you made sure
both NIC's are set to the same setting and they are not relying on auto
negotiation?
Click to expand...

Well... I am not sure... they are pretty old cards... I got a few cards for
free too without software.

For one of the card I might have some old dos software to configure them...

Could it be possible to configure them from windows ???
 
Lew Pitcher said:
You really should be asking in comp.dcom.ethernet, as your questions don't have
anything to do with TCP/IP, and have everything to do with ethernet data
communications.
Click to expand...

I disagree with that.

People that write tcp/ip stacks have to write stuff for ethernet as well.

So it can be very interesting for those people. How to get maximum
performance.
Click to expand...
 
Hmm.. very interesting... I wonder what the formula would be for calculating
the right gap time ?! :D
Click to expand...

The round trip time of the slower host, but this of course can be
increased a lot depending on the processing needed on that packet.
What I'm trying to say is it makes a huge difference if you simply
send the packet and the remote host can either trash it or is fast
enough to completly process it before the next one arrives. With an
ongoing sustained stream of packets it's obvious that there will be
lost packets if the receiving host can't keep up with processing, but
otherwise would be fast enough on the ethernet level alone.

TCP does a lot of optimisations (congestion control) to actually
minimize packet loss (and hence retransmits) as much as possible.
Another thing to mention is that UDP packets of > 512 Bytes are non
standard. So, if what you intend to do should be useable in a just a
little wider area I think you should considder switching to TCP.

Just my 2¢ though.

Markus
 
Hmm.. very interesting... I wonder what the formula would be for
calculating
the right gap time ?! :D
Click to expand...

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
 
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.
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.
Hmm.. very interesting... I wonder what the formula would be for calculating
the right gap time ?! :D
Click to expand...

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.
 
Markus Zingg said:
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.
Click to expand...

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
 
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 :-)
 
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 :-)
Click to expand...

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+fragmentation+considered+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 (e-mail address removed)
 
If you try sending from both computers at once you get packet collisions and
nothing gets thru.
DaveW
 
Back
Top