Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by Anand Moda » Wed, 25 Nov 1998 04:00:00



I have a Cisco Cat5000 running 3.2.1b.  Plugged into this switch is a Compaq
server that has a Netflex 10/100 Autosensing NIC and the latest NIC drivers.
The server runs Oracle on NT.  When the server and switch are set to 100Mbit
Full Duplex a client connection to the server is very slow.  Switch port
stats show a large number of runts.  Sniffer analyzer trace shows lots of
retransmissions.

Now I set the connection on both sides to 10Mbits Half Duplex and the client
zooms along - no runts, few retransmissions.  But although the client runs
smoother, strangely enough, an NT backup from this server across the network
increases in time from 1 1/2 hours to 4 1/2 hours.

My initial guess is that the physical connection is not adequate for Fast
Ethernet.  But its 10 feet from the switch to the server.  Is it possible
that a straight through patch cable is not adequate because it doesn't
use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried letting one
or the other side autosense, and I've tried forcing both sides to agree
on speed and duplex.  

tia
anand

Anand Modak        WAN Engineer        Montgomery County Public Schools

 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by mjy » Wed, 25 Nov 1998 04:00:00


Straight thru is an obvious step to fix...not sure if NEXT is distance sensitive
but it is a problem. Get the Rx+/- (Tx+/-) together and try it...
Can you get the exact same trace 10 and 100 ?  When does it differ ?

> I have a Cisco Cat5000 running 3.2.1b.  Plugged into this switch is a Compaq
> server that has a Netflex 10/100 Autosensing NIC and the latest NIC drivers.
> The server runs Oracle on NT.  When the server and switch are set to 100Mbit
> Full Duplex a client connection to the server is very slow.  Switch port
> stats show a large number of runts.  Sniffer analyzer trace shows lots of
> retransmissions.

> Now I set the connection on both sides to 10Mbits Half Duplex and the client
> zooms along - no runts, few retransmissions.  But although the client runs
> smoother, strangely enough, an NT backup from this server across the network
> increases in time from 1 1/2 hours to 4 1/2 hours.

> My initial guess is that the physical connection is not adequate for Fast
> Ethernet.  But its 10 feet from the switch to the server.  Is it possible
> that a straight through patch cable is not adequate because it doesn't
> use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried letting one
> or the other side autosense, and I've tried forcing both sides to agree
> on speed and duplex.

> tia
> anand

> Anand Modak        WAN Engineer        Montgomery County Public Schools



 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by Alfred Rodrigue » Wed, 25 Nov 1998 04:00:00



to 100 Mb Half duplex.
When we had servers and switches set to auto,  they wouldn't negotiate properly
and systems that were set to 100 Mb full duplex,
flooded the clients with act packets,  which slowed down some systems to a
crawl.

Alfred


> I have a Cisco Cat5000 running 3.2.1b.  Plugged into this switch is a Compaq
> server that has a Netflex 10/100 Autosensing NIC and the latest NIC drivers.
> The server runs Oracle on NT.  When the server and switch are set to 100Mbit
> Full Duplex a client connection to the server is very slow.  Switch port
> stats show a large number of runts.  Sniffer analyzer trace shows lots of
> retransmissions.

> Now I set the connection on both sides to 10Mbits Half Duplex and the client
> zooms along - no runts, few retransmissions.  But although the client runs
> smoother, strangely enough, an NT backup from this server across the network
> increases in time from 1 1/2 hours to 4 1/2 hours.

> My initial guess is that the physical connection is not adequate for Fast
> Ethernet.  But its 10 feet from the switch to the server.  Is it possible
> that a straight through patch cable is not adequate because it doesn't
> use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried letting one
> or the other side autosense, and I've tried forcing both sides to agree
> on speed and duplex.

> tia
> anand

> Anand Modak        WAN Engineer        Montgomery County Public Schools


 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by Bristow, Rober » Wed, 25 Nov 1998 04:00:00


Anand,
 Which device, the switch or the server, are sending the runt packets?
Rob
> -----Original Message-----

> Sent: Tuesday, November 24, 1998 1:34 PM

> Subject: Speed/Duplex Paradox - Fast is Slow & Slow is Fast

> I have a Cisco Cat5000 running 3.2.1b.  Plugged into this
> switch is a Compaq
> server that has a Netflex 10/100 Autosensing NIC and the
> latest NIC drivers.
> The server runs Oracle on NT.  When the server and switch are
> set to 100Mbit
> Full Duplex a client connection to the server is very slow.  
> Switch port
> stats show a large number of runts.  Sniffer analyzer trace
> shows lots of
> retransmissions.

> Now I set the connection on both sides to 10Mbits Half Duplex
> and the client
> zooms along - no runts, few retransmissions.  But although
> the client runs
> smoother, strangely enough, an NT backup from this server
> across the network
> increases in time from 1 1/2 hours to 4 1/2 hours.

> My initial guess is that the physical connection is not
> adequate for Fast
> Ethernet.  But its 10 feet from the switch to the server.  Is
> it possible
> that a straight through patch cable is not adequate because
> it doesn't
> use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried
> letting one
> or the other side autosense, and I've tried forcing both
> sides to agree
> on speed and duplex.  

> tia
> anand

> Anand Modak        WAN Engineer        Montgomery County
> Public Schools
> 850 Hungerford Dr, Rockville MD 20850  (301)517-8233  


 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by Anand Moda » Wed, 25 Nov 1998 04:00:00


The switch reports the runts so I assume the server is responsible for
generating them and the switch is detecting them.

BTW - I have tried all combinations of 10/100 half/full duplex set the
same on both ends of the server/switch connection.  I have just had my
cabling guys install patch panels on both ends so if it has to do with
1&2 and 3&6 on 2 twisted pairs of a cat 5 then conforming to patch panel
standards should take care of this for me.

I have a response that the NetFlex NICs are no good... Anybody else have
experience with these?

 thx.
anand.


> Anand,
>  Which device, the switch or the server, are sending the runt packets?
> Rob

> > -----Original Message-----

> > Sent: Tuesday, November 24, 1998 1:34 PM

> > Subject: Speed/Duplex Paradox - Fast is Slow & Slow is Fast

> > I have a Cisco Cat5000 running 3.2.1b.  Plugged into this
> > switch is a Compaq
> > server that has a Netflex 10/100 Autosensing NIC and the
> > latest NIC drivers.
> > The server runs Oracle on NT.  When the server and switch are
> > set to 100Mbit
> > Full Duplex a client connection to the server is very slow.  
> > Switch port
> > stats show a large number of runts.  Sniffer analyzer trace
> > shows lots of
> > retransmissions.

> > Now I set the connection on both sides to 10Mbits Half Duplex
> > and the client
> > zooms along - no runts, few retransmissions.  But although
> > the client runs
> > smoother, strangely enough, an NT backup from this server
> > across the network
> > increases in time from 1 1/2 hours to 4 1/2 hours.

> > My initial guess is that the physical connection is not
> > adequate for Fast
> > Ethernet.  But its 10 feet from the switch to the server.  Is
> > it possible
> > that a straight through patch cable is not adequate because
> > it doesn't
> > use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried
> > letting one
> > or the other side autosense, and I've tried forcing both
> > sides to agree
> > on speed and duplex.  

> > tia
> > anand

> > Anand Modak        WAN Engineer        Montgomery County
> > Public Schools
> > 850 Hungerford Dr, Rockville MD 20850  (301)517-8233  


Anand Modak        WAN Engineer        Montgomery County Public Schools

 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by Scott Renne » Thu, 26 Nov 1998 04:00:00


I would verify that you are using a Cat 5 cable, and replace it just the
same.  I have also had problems with the NetFlex 10/100 cards.  Setting
both sides (switch port and card) to 100 Full Duplex, has fixed this
problem for me in the past

Scott


> I have a Cisco Cat5000 running 3.2.1b.  Plugged into this switch is a Compaq
> server that has a Netflex 10/100 Autosensing NIC and the latest NIC drivers.
> The server runs Oracle on NT.  When the server and switch are set to 100Mbit
> Full Duplex a client connection to the server is very slow.  Switch port
> stats show a large number of runts.  Sniffer analyzer trace shows lots of
> retransmissions.

> Now I set the connection on both sides to 10Mbits Half Duplex and the client
> zooms along - no runts, few retransmissions.  But although the client runs
> smoother, strangely enough, an NT backup from this server across the network
> increases in time from 1 1/2 hours to 4 1/2 hours.

> My initial guess is that the physical connection is not adequate for Fast
> Ethernet.  But its 10 feet from the switch to the server.  Is it possible
> that a straight through patch cable is not adequate because it doesn't
> use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried letting one
> or the other side autosense, and I've tried forcing both sides to agree
> on speed and duplex.

> tia
> anand

> Anand Modak        WAN Engineer        Montgomery County Public Schools


 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by coredu » Thu, 26 Nov 1998 04:00:00


We had performance problems trying to get 100 Full Duplex, but
updating the NT drivers did the trick (to what, I don't know - I
support the switch, not the server).

I don't like the cards though - I've seen much better performance and
reliability from Intel NICs.

Bob.


>I have a Cisco Cat5000 running 3.2.1b.  Plugged into this switch is a Compaq
>server that has a Netflex 10/100 Autosensing NIC and the latest NIC drivers.
>The server runs Oracle on NT.  When the server and switch are set to 100Mbit
>Full Duplex a client connection to the server is very slow.  Switch port
>stats show a large number of runts.  Sniffer analyzer trace shows lots of
>retransmissions.

>Now I set the connection on both sides to 10Mbits Half Duplex and the client
>zooms along - no runts, few retransmissions.  But although the client runs
>smoother, strangely enough, an NT backup from this server across the network
>increases in time from 1 1/2 hours to 4 1/2 hours.

>My initial guess is that the physical connection is not adequate for Fast
>Ethernet.  But its 10 feet from the switch to the server.  Is it possible
>that a straight through patch cable is not adequate because it doesn't
>use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried letting one
>or the other side autosense, and I've tried forcing both sides to agree
>on speed and duplex.  

>tia
>anand

>Anand Modak        WAN Engineer        Montgomery County Public Schools


 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by a.. » Fri, 27 Nov 1998 04:00:00


How about 100mg half on the server and 10mg on the workstation. I'll bet the
workstation can't do 100mg full (or just can't process the input that fast).

Tony Wieczorek
CCDA, CCNA, MCSE,
CNE-3, CNE-4, IBM PSE

Modern Business Technology
(414) 344-0143 Ext. 256

-----Original Message-----

Sent: Tuesday, November 24, 1998 8:11 PM

Subject: RE: Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Anand,
 Which device, the switch or the server, are sending the runt packets?
Rob

> -----Original Message-----

> Sent: Tuesday, November 24, 1998 1:34 PM

> Subject: Speed/Duplex Paradox - Fast is Slow & Slow is Fast

> I have a Cisco Cat5000 running 3.2.1b.  Plugged into this
> switch is a Compaq
> server that has a Netflex 10/100 Autosensing NIC and the
> latest NIC drivers.
> The server runs Oracle on NT.  When the server and switch are
> set to 100Mbit
> Full Duplex a client connection to the server is very slow.
> Switch port
> stats show a large number of runts.  Sniffer analyzer trace
> shows lots of
> retransmissions.

> Now I set the connection on both sides to 10Mbits Half Duplex
> and the client
> zooms along - no runts, few retransmissions.  But although
> the client runs
> smoother, strangely enough, an NT backup from this server
> across the network
> increases in time from 1 1/2 hours to 4 1/2 hours.

> My initial guess is that the physical connection is not
> adequate for Fast
> Ethernet.  But its 10 feet from the switch to the server.  Is
> it possible
> that a straight through patch cable is not adequate because
> it doesn't
> use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried
> letting one
> or the other side autosense, and I've tried forcing both
> sides to agree
> on speed and duplex.

> tia
> anand

> Anand Modak        WAN Engineer        Montgomery County
> Public Schools
> 850 Hungerford Dr, Rockville MD 20850  (301)517-8233


 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by Charlie Fenwic » Fri, 27 Nov 1998 04:00:00


Anand,

I just got finished troubleshooting a very similar situation.  We had one
single vlan that was supporting a certain application  (Roughly 50 PCs).
 Let's call the machines we were troubleshooting A, B and C.  When I
originally installed the two switches to support this application, I left
the switch in auto speed/duplex negotiation (I wasn't sure how the
application vendor would install the PCs or what kind of NICs they had).

I got a call that certain parts of the application were very slow and that
key hosts running in this application were reporting errors, lets call them
hosts A, B and C.

A would transmit a large amount of data to B and C.  When I first
investigated they had A set to half and B and C set to full.  Many a bad
CRC, single and multiple collisions were seen for A.  The application would
eventually balk and say that A couldn't write to network drive space on B
and C.  That A had suffered disk buffer over runs and that data may have
been lost (this was a image archiving application where pictures are
snapped at A temp stored in a buffer and then shipped to B and C for
different types of processing).

The vendor's engineer flip-flopped the duplex configuration...  B and C now
half, and A was full.  The application would eventually balk again saying
that B and C were not responding.  When I plugged in a sniffer in I saw a
large number of retransmissions to, and late ACKs coming from, B and C.
 ACKs would be like .1, .3 or .5 ms on the average and then would skyrocket
to 197ms or higher.

The problem would not be so bad when all three devices were in the same
switch.

My theory was this (and we have taken as the explanation)...

Full duplex takes CS and CD out of Ethernet, because there are logically
only 2 devices on a bridged segment.  Meaning in the first situation, B and
C were sending ACKs and data back to A (and the switch was switching) so
fast, that A could not really deliver the data the application needed to
send effectively.  (B and C could transmit when they were receiving as
where A could not).  When reversed (B and C half and A full), the late ACKs
and retransmissions were due to A sending data as fast as it could (not
CS-ing and not looking for collisions) and B and C behaving like
traditional Ethernet.  Not transmitting when receiving and observing
collisions.  Therefore, the ACKs never made it back to A (or late) and A
intern figured there was a problem.

My suggestion to the vendor and customer, who was having the problem: Set
all PCs to half or set all PCs to full.  Because the PCs had different NIC
manufacturers and the link between the switches was 100Mbs (the same speed
as all the PCs plugged into them) I leaned towards all being half.

I would suggest only using full duplex between ports when you have...

A) A dedicated one to one relationship that you can identify, for example:
A to B transmitting a lot of data back and forth or in the above example A,
B and C.  (All devices plugged into a switch).
B) All workstations running full duplex plugged into switches.

C) Router to switch.

D) Switch to switch.

I would try not to have a situation where I had a mix and match of full and
half on workstations/servers in a single vlan.  Only exception is maybe if
you have a many to one relationship (like 100 workstations /half/ to 1
server /full/ all the same speed).  Or other high utilization hosts such as
a router interface mentioned above.

If you have 100Mbs/full to 10Mbs/half in the same vlan really opens up a
situation where the 10Mbs workstations can get blasted and not operate
optimally.

We set all the PCs to half and the application performed very well.  I
expect if everything in the Vlan was set to full, it would have also...
however I had concerns about oversubscribing the cross connect, between the
switches and whether or not the PCs would really benefit anyway, due to the
nature of the application.

The bottom line is (IMHO) full duplex is not necessarily better that half,
you really have to analyze what it is you are trying to accomplish and
where your traffic flows are.

I would welcome any other experiences and/or comments with mix and match
full/half duplex.  For my customer will want a detailed explanation of what
happened to their application, so they can take it back to the vendor.

Anand, in your particular situation I would try running the server at
100Mbs/half.  I would imagine you will see the 10Mbs clients problems
lessen/disappear and the backup across the network remain pretty quick.

Cheers,
Charlie Fenwick
RPM Consulting

On Tuesday,

> I have a Cisco Cat5000 running 3.2.1b.  Plugged into this switch is a
Compaq
> server that has a Netflex 10/100 Autosensing NIC and the latest NIC
drivers.
> The server runs Oracle on NT.  When the server and switch are set to
100Mbit
> Full Duplex a client connection to the server is very slow.  Switch port
> stats show a large number of runts.  Sniffer analyzer trace shows lots of
> retransmissions.

> Now I set the connection on both sides to 10Mbits Half Duplex and the
client
> zooms along - no runts, few retransmissions.  But although the client
runs
> smoother, strangely enough, an NT backup from this server across the
network
> increases in time from 1 1/2 hours to 4 1/2 hours.

> My initial guess is that the physical connection is not adequate for Fast
> Ethernet.  But its 10 feet from the switch to the server.  Is it possible
> that a straight through patch cable is not adequate because it doesn't
> use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried letting one
> or the other side autosense, and I've tried forcing both sides to agree
> on speed and duplex.

> tia
> anand

> Anand Modak        WAN Engineer        Montgomery County Public Schools


md.us
 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by Anand Moda » Sat, 28 Nov 1998 04:00:00


Charlie,

Wonderful!  You addressed my problem very nicely!  I appreciate the in-depth
answer.  It sounds reasonable.  I remember reading an article about how a
switch changes traditional ethernet because of its ability to buffer, and to
work with 10/100 half and full duplex.  This seems like a likely place for
the TCP/IP ack process between server and clients to go astray.  I will try
100MB half duplex at the server and other combinations keeping your answer in
mind.


anand.


> Anand,

> I just got finished troubleshooting a very similar situation.  We had one
> single vlan that was supporting a certain application  (Roughly 50 PCs).
>  Let's call the machines we were troubleshooting A, B and C.  When I
> originally installed the two switches to support this application, I left
> the switch in auto speed/duplex negotiation (I wasn't sure how the
> application vendor would install the PCs or what kind of NICs they had).

> I got a call that certain parts of the application were very slow and that
> key hosts running in this application were reporting errors, lets call them
> hosts A, B and C.

> A would transmit a large amount of data to B and C.  When I first
> investigated they had A set to half and B and C set to full.  Many a bad
> CRC, single and multiple collisions were seen for A.  The application would
> eventually balk and say that A couldn't write to network drive space on B
> and C.  That A had suffered disk buffer over runs and that data may have
> been lost (this was a image archiving application where pictures are
> snapped at A temp stored in a buffer and then shipped to B and C for
> different types of processing).

> The vendor's engineer flip-flopped the duplex configuration...  B and C now
> half, and A was full.  The application would eventually balk again saying
> that B and C were not responding.  When I plugged in a sniffer in I saw a
> large number of retransmissions to, and late ACKs coming from, B and C.
>  ACKs would be like .1, .3 or .5 ms on the average and then would skyrocket
> to 197ms or higher.

> The problem would not be so bad when all three devices were in the same
> switch.

> My theory was this (and we have taken as the explanation)...

> Full duplex takes CS and CD out of Ethernet, because there are logically
> only 2 devices on a bridged segment.  Meaning in the first situation, B and
> C were sending ACKs and data back to A (and the switch was switching) so
> fast, that A could not really deliver the data the application needed to
> send effectively.  (B and C could transmit when they were receiving as
> where A could not).  When reversed (B and C half and A full), the late ACKs
> and retransmissions were due to A sending data as fast as it could (not
> CS-ing and not looking for collisions) and B and C behaving like
> traditional Ethernet.  Not transmitting when receiving and observing
> collisions.  Therefore, the ACKs never made it back to A (or late) and A
> intern figured there was a problem.

> My suggestion to the vendor and customer, who was having the problem: Set
> all PCs to half or set all PCs to full.  Because the PCs had different NIC
> manufacturers and the link between the switches was 100Mbs (the same speed
> as all the PCs plugged into them) I leaned towards all being half.

> I would suggest only using full duplex between ports when you have...

> A) A dedicated one to one relationship that you can identify, for example:
> A to B transmitting a lot of data back and forth or in the above example A,
> B and C.  (All devices plugged into a switch).
> B) All workstations running full duplex plugged into switches.

> C) Router to switch.

> D) Switch to switch.

> I would try not to have a situation where I had a mix and match of full and
> half on workstations/servers in a single vlan.  Only exception is maybe if
> you have a many to one relationship (like 100 workstations /half/ to 1
> server /full/ all the same speed).  Or other high utilization hosts such as
> a router interface mentioned above.

> If you have 100Mbs/full to 10Mbs/half in the same vlan really opens up a
> situation where the 10Mbs workstations can get blasted and not operate
> optimally.

> We set all the PCs to half and the application performed very well.  I
> expect if everything in the Vlan was set to full, it would have also...
> however I had concerns about oversubscribing the cross connect, between the
> switches and whether or not the PCs would really benefit anyway, due to the
> nature of the application.

> The bottom line is (IMHO) full duplex is not necessarily better that half,
> you really have to analyze what it is you are trying to accomplish and
> where your traffic flows are.

> I would welcome any other experiences and/or comments with mix and match
> full/half duplex.  For my customer will want a detailed explanation of what
> happened to their application, so they can take it back to the vendor.

> Anand, in your particular situation I would try running the server at
> 100Mbs/half.  I would imagine you will see the 10Mbs clients problems
> lessen/disappear and the backup across the network remain pretty quick.

> Cheers,
> Charlie Fenwick
> RPM Consulting

> On Tuesday,

> > I have a Cisco Cat5000 running 3.2.1b.  Plugged into this switch is a
> Compaq
> > server that has a Netflex 10/100 Autosensing NIC and the latest NIC
> drivers.
> > The server runs Oracle on NT.  When the server and switch are set to
> 100Mbit
> > Full Duplex a client connection to the server is very slow.  Switch port
> > stats show a large number of runts.  Sniffer analyzer trace shows lots of
> > retransmissions.

> > Now I set the connection on both sides to 10Mbits Half Duplex and the
> client
> > zooms along - no runts, few retransmissions.  But although the client
> runs
> > smoother, strangely enough, an NT backup from this server across the
> network
> > increases in time from 1 1/2 hours to 4 1/2 hours.

> > My initial guess is that the physical connection is not adequate for Fast
> > Ethernet.  But its 10 feet from the switch to the server.  Is it possible
> > that a straight through patch cable is not adequate because it doesn't
> > use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried letting one
> > or the other side autosense, and I've tried forcing both sides to agree
> > on speed and duplex.

> > tia
> > anand

> > Anand Modak        WAN Engineer        Montgomery County Public Schools

> md.us

Anand Modak        WAN Engineer        Montgomery County Public Schools

 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by Mattias Douh » Sun, 29 Nov 1998 04:00:00


Hello

I have seend this too, and we upgraded the fw in our switches and the
problem was gone with the wind.

rgds

Matt



>I have a Cisco Cat5000 running 3.2.1b.  Plugged into this switch is a Compaq
>server that has a Netflex 10/100 Autosensing NIC and the latest NIC drivers.
>The server runs Oracle on NT.  When the server and switch are set to 100Mbit
>Full Duplex a client connection to the server is very slow.  Switch port
>stats show a large number of runts.  Sniffer analyzer trace shows lots of
>retransmissions.

>Now I set the connection on both sides to 10Mbits Half Duplex and the client
>zooms along - no runts, few retransmissions.  But although the client runs
>smoother, strangely enough, an NT backup from this server across the network
>increases in time from 1 1/2 hours to 4 1/2 hours.

>My initial guess is that the physical connection is not adequate for Fast
>Ethernet.  But its 10 feet from the switch to the server.  Is it possible
>that a straight through patch cable is not adequate because it doesn't
>use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried letting one
>or the other side autosense, and I've tried forcing both sides to agree
>on speed and duplex.  

>tia
>anand

>Anand Modak        WAN Engineer        Montgomery County Public Schools


Mattias Douhan, Senior Consultant

www.intsys.se
CCIE #4004
We all love SNA, don't we :)
 
 
 

Speed/Duplex Paradox - Fast is Slow & Slow is Fast

Post by Peter Morrisse » Tue, 01 Dec 1998 04:00:00


OK, since you asked for similar experiences, I will share some as
well as some comments below. In summary, I will say that we
mix and match full duplex FE with half duplex 10mbps all over
the place and have had no problems. We also mix half and
full duplex FE, again with no problems. The biggest problems
we have had though are duplexity mismatches between the switch
and the end node, usually a server. In the scenario below, you
seem to assume that your switch is correctly auto negotiating
the correct duplexity. In fact the symptoms you give of high
collision and CRC's indicate a duplexity mismatch. You really
should have little to no CRC errors on any connection.

Charlie Fenwick wrote:

> Anand,

> I just got finished troubleshooting a very similar situation.  We had one
> single vlan that was supporting a certain application  (Roughly 50 PCs).
>  Let's call the machines we were troubleshooting A, B and C.  When I
> originally installed the two switches to support this application, I left
> the switch in auto speed/duplex negotiation (I wasn't sure how the
> application vendor would install the PCs or what kind of NICs they had).

> I got a call that certain parts of the application were very slow and that
> key hosts running in this application were reporting errors, lets call them
> hosts A, B and C.

> A would transmit a large amount of data to B and C.  When I first
> investigated they had A set to half and B and C set to full.  Many a bad
> CRC, single and multiple collisions were seen for A.  The application would
> eventually balk and say that A couldn't write to network drive space on B
> and C.  That A had suffered disk buffer over runs and that data may have
> been lost (this was a image archiving application where pictures are
> snapped at A temp stored in a buffer and then shipped to B and C for
> different types of processing).

This tells me that the switch is not matched correctly with A or with
B and C. You should not be seeing any CRC's.

- Show quoted text -

> The vendor's engineer flip-flopped the duplex configuration...  B and C now
> half, and A was full.  The application would eventually balk again saying
> that B and C were not responding.  When I plugged in a sniffer in I saw a
> large number of retransmissions to, and late ACKs coming from, B and C.
>  ACKs would be like .1, .3 or .5 ms on the average and then would skyrocket
> to 197ms or higher.

> The problem would not be so bad when all three devices were in the same
> switch.

> My theory was this (and we have taken as the explanation)...

> Full duplex takes CS and CD out of Ethernet, because there are logically
> only 2 devices on a bridged segment.  Meaning in the first situation, B and
> C were sending ACKs and data back to A (and the switch was switching) so
> fast, that A could not really deliver the data the application needed to
> send effectively.  (B and C could transmit when they were receiving as

I suppose you could make a case that the data was streaming to B and C so
fast that the acks could not make it back to A because A was sending data
to B or C and hogging the wire in that direction. Not likely, but maybe
theoretically possible.

> where A could not).  When reversed (B and C half and A full), the late ACKs
> and retransmissions were due to A sending data as fast as it could (not
> CS-ing and not looking for collisions) and B and C behaving like
> traditional Ethernet.  Not transmitting when receiving and observing
> collisions.  Therefore, the ACKs never made it back to A (or late) and A
> intern figured there was a problem.

The problem with this theory is that it appears that B and C were each inolved
with a single session with A. This means that they would have no reason to
send an ack until they received all the data anyway, thus it would essentiall
be a half duplex conversation at the tcp level. Again, it is much more likely
that the packets were dropped due to the mismatch.

- Show quoted text -

> My suggestion to the vendor and customer, who was having the problem: Set
> all PCs to half or set all PCs to full.  Because the PCs had different NIC
> manufacturers and the link between the switches was 100Mbs (the same speed
> as all the PCs plugged into them) I leaned towards all being half.

> I would suggest only using full duplex between ports when you have...

> A) A dedicated one to one relationship that you can identify, for example:
> A to B transmitting a lot of data back and forth or in the above example A,
> B and C.  (All devices plugged into a switch).
> B) All workstations running full duplex plugged into switches.

> C) Router to switch.

> D) Switch to switch.

> I would try not to have a situation where I had a mix and match of full and
> half on workstations/servers in a single vlan.  Only exception is maybe if
> you have a many to one relationship (like 100 workstations /half/ to 1
> server /full/ all the same speed).  Or other high utilization hosts such as
> a router interface mentioned above.

> If you have 100Mbs/full to 10Mbs/half in the same vlan really opens up a
> situation where the 10Mbs workstations can get blasted and not operate
> optimally.

This is a very common configuration, and it should work just fine.

> We set all the PCs to half and the application performed very well.  I
> expect if everything in the Vlan was set to full, it would have also...
> however I had concerns about oversubscribing the cross connect, between the
> switches and whether or not the PCs would really benefit anyway, due to the
> nature of the application.

This tells me that the switch was auto negotiating to half. The real
test would be to set  A, B and C to full and see what happens. If my
theory is correct, the performance should tank.

Also, if you carry your other theories over to this situation, you should
still have problems. You stil have still eliminated CSMA/CD from the
equation here in that you have multiple switched connections, talking
to the one.  There is still have B and C sending acks at the same time
data is being sent from A.

> The bottom line is (IMHO) full duplex is not necessarily better that half,
> you really have to analyze what it is you are trying to accomplish and
> where your traffic flows are.

I am in agreement here. Full only helps when you have symmetric traffic
patterns. This would not appear to be the case in your application.
But, it should not hurt either, unless something is malfunctioning or
misconfigured.

- Show quoted text -

> I would welcome any other experiences and/or comments with mix and match
> full/half duplex.  For my customer will want a detailed explanation of what
> happened to their application, so they can take it back to the vendor.

> Anand, in your particular situation I would try running the server at
> 100Mbs/half.  I would imagine you will see the 10Mbs clients problems
> lessen/disappear and the backup across the network remain pretty quick.

> Cheers,
> Charlie Fenwick
> RPM Consulting

> On Tuesday,
> November 24, 1998 1:34 PM, Anand Modak [SMTP:amo...@mcps.k12.md.us] wrote:
> > I have a Cisco Cat5000 running 3.2.1b.  Plugged into this switch is a
> Compaq
> > server that has a Netflex 10/100 Autosensing NIC and the latest NIC
> drivers.
> > The server runs Oracle on NT.  When the server and switch are set to
> 100Mbit
> > Full Duplex a client connection to the server is very slow.  Switch port
> > stats show a large number of runts.  Sniffer analyzer trace shows lots of
> > retransmissions.

> > Now I set the connection on both sides to 10Mbits Half Duplex and the
> client
> > zooms along - no runts, few retransmissions.  But although the client
> runs
> > smoother, strangely enough, an NT backup from this server across the
> network
> > increases in time from 1 1/2 hours to 4 1/2 hours.

> > My initial guess is that the physical connection is not adequate for Fast
> > Ethernet.  But its 10 feet from the switch to the server.  Is it possible
> > that a straight through patch cable is not adequate because it doesn't
> > use 2 pair for 1 2 3 and 6?  Any other ideas?  I have tried letting one
> > or the other side autosense, and I've tried forcing both sides to agree
> > on speed and duplex.

> > tia
> > anand

> > Anand Modak        WAN Engineer        Montgomery County Public Schools
> > 850 Hungerford Dr, Rockville MD 20850  (301)517-8233  amo...@mcps.k12.
> md.us

 
 
 

1. A fast modem isn't fast if the network is slow

This is a multi-part message in MIME format.

------=_NextPart_000_01BC625F.FF058BE0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ok, it does'nt take a rocket scientist to figure out that you can have the
fastest modem on the market but if your ISP is slow you are slow. I have an
off brand modem from Falcon Technologies that rocks when I get a good
connection. But, most the time it is way too slow because my ISP is very
slow becuase of heavy traffic and bandwidth squeezing. SO throw that into
your $200 modem equations.
--
Steven S. Palmer
http://www.geocities.com/yosemite/8817/
- - - - - - - - - - - - - - - - - - - - - - - -
"People Get The Government They Deserve......"
- - - - - - - - - - - - - - - - - - - - - - - -
------=_NextPart_000_01BC625F.FF058BE0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head></head><BODY bgcolor=3D"#FFFFFF"><p><font size=3D2 =
color=3D"#000000" face=3D"Arial">Ok, it does'nt take a rocket scientist =
to figure out that you can have the fastest modem on the market but if =
your ISP is slow you are slow. I have an off brand modem from Falcon =
Technologies that rocks when I get a good connection. But, most the time =
it is way too slow because my ISP is very slow becuase of heavy traffic =
and bandwidth squeezing. SO throw that into your $200 modem =
equations.<br>-- <br>Steven S. Palmer<br><font =
color=3D"#0000FF"><u>http://www.geocities.com/yosemite/8817/</u><font =
color=3D"#000000"><br>- - - - - - - - - - - - - - - - - - - - - - - - =
<br>&quot;People Get The Government They Deserve......&quot;<br>- - - - =
- - - - - - - - - - - - - - - - - - - -</p>
</font></font></font></body></html>
------=_NextPart_000_01BC625F.FF058BE0--

2. Digital Camera Vs Video Capture

3. PPP slow. Browsing slow but download fast.

4. Underwriters Laboratory symbol

5. Help - fast connection speed, slow download times!!

6. Objective-C FAQ

7. Slow upload speeds? How fast is yours?

8. Download speed fast - web browsing SLOW?

9. Speed begins fast, then slows down??

10. Speeds on 98 (slow) and NT (fast)

11. How fast am I?

12. help! I am having slow connections