Thank you Annlee, this is enlightening. My users mainly use word/excel documents along with a small access database.
I know that sounds awful but what performance gain I will loose by using a "cheap" switch that does not do flow control? If I where able to convince my client and we used a Cisco switch, how could I verify that the 3COM cards are compatible with the Cisco gears? Would you use a sniffer and analyze the traffic or is there a simpler way? Thanks, Pierre-Alex ----- Original Message ----- From: "Annlee" To: Cc: Sent: Friday, August 29, 2003 10:09 PM Subject: Re: 802.3x switch traffic disruption [7:74455] > A Google search on "802.3x" yields a lot of discussion of flow control > issues people seem to have -- linux as well as windows clients. One > item I found at the IEEE's web page was this: > http://grouper.ieee.org/groups/802/3/efm/public/email/msg02446.html > > /quote > In working with Ethernet for over 20 years, the one functionality that is > most severely vendor dependant is 802.3x "Flow Control". Perhaps it is > partly the politics of the 802.3WG. Perhaps the politics of IETF pushing > their flow and rate adaptation to the exclusion of other layer or > types is > partly to blame. In some cases it marketing decisions on the part of > vendors that cause them to improperly implement 802.3x in their > interfaces > and systems. For those vendors that are purely Ethernet and expect > themselves to do things right, 802.3x Flow Control works to a level and > quality that is at first surprising to their customers. If you want more > information about my experiences with vendors and their > implementations of > 802.3x, continue to read. > > ...and it goes on, at some length. > > FWIW > > Annlee > > [EMAIL PROTECTED] wrote: > > No, I don't think I have a design issue: the network has 7 clients and 1 > > server so the architecture is very simple. My client was complaining of slow > > speed when opening files. My approach was to optimize at every layer > > possible. Choosing 802.3x feature was just one thing among others I did to > > speed up file access. > > > > 1) I moved them from a bus architecture, to a switched architecture, > > replacing all the coax cabling with twisted pair. > > 2) When I replaced the NICs I went for NIC that could do flow control and > > chose a "brand name" switch that supported the same feature. (Yes I should > > have chosen Cisco for the Switch, but how do you convince you client to pay > > "more" for something that appears to do the same thing?). > > 3) I replaced the OS on the clients (Windows Millennium) with Windows XP > > professional. Optimized the page file (and removed it from the system/boot > > partition). Disabled unnecessary services. > > 4) On the server side, I used SCSI hard disks and the fastest SCSI > > controller I could find on the market. Optimized the server to death. > > 5) I did not mess-up with modifying TCP Window parameters because I thought > > that was not necessary. > > > > The speed increase is visible, but with the network freezing up twice this > > week, all my work has taken a serious credibility hit. I have replaced their > > Switch with one of my personal Cisco switches after the second incident. My > > plan is to leave the switch ( a Cisco 2924XL) there for a week or two so I > > can monitor network activity and gather statistics . Then I don't know... > > The switch belongs to my CCIE rack so I will either have to sell it to them > > or buy them another inexpensive switch. :>) > > > > > > > > > > > > ----- Original Message ----- > > From: "annlee" > > To: > > Sent: Friday, August 29, 2003 7:24 PM > > Subject: Re: 802.3x switch traffic disruption [7:74455] > > > > > > > >>Netgear does have its problems... > >>http://www.dslreports.com/shownews/31774?mode=flat > >> > >>That said, all the inexpensive devices have problems of one sort or > >>another. I think it's a case of getting what you paid for / caveat > >>emptor. For small networks clients, I always try to get them to buy > >>one step higher quality than they wanted to pay for (since if they > >>understood the ramifications, they wouldn't need me). It rarely works > >>though ... which does tend to lead to repeat business... > >> > >>Annlee > >> > >>Priscilla Oppenheimer wrote: > >> > >> > >>>It sounds like the Netgear Layer 2 802.3 flow control is buggy. It > > > > sounds > > > >>>like you can't turn it off, though, because it's not a managed switch. > >>>Should have bought Cisco!? :-) > >>> > >>>You can turn it off on the workstations, though, and I would somewhat > >>>hesitantly recomment that. You might risk other problems by disabling > > > > it. > > > >>>Flow control should be negotiated with autonegotiation, but we know how > >> > >>well > >> > >>>that works for duplex mode. Nontheless, if it were me, I think I would > > > > turn > > > >>>it off on the workstations carefully, as a test to start with. > >>> > >>>I'd be interested in other people's opinions, but I think flow control > > > > at > > > >>>the data-link-layer is risky and unnecessary anyway. > >>> > >>>No offence to Netgear (really!) but I'm not sure I would trust them to > > > > do > > > >>it > >> > >>>right, especially on a low-end switch. So, let's say a switch port has > > > > been > > > >>>flow controlled and told not to send any packets for a while. What does > > > > it > > > >>>do with the packets? How much buffering can it support? Does it have > >>>features to avoid head-of-the-line blocking? Will the flow control on > > > > that > > > >>>interface cause problems for other interfaces? > >>> > >>>TCP already does end-to-end flow control. Of course, not every > > > > application > > > >>>uses TCP, but a lot do. I think that's a better way to handle it. > >>> > >>>And one final comment, if you really need to be flow controlling > > > > traffic, > > > >>>perhaps you should just upgrade the bandwidth? Ethernet flow control > > > > sounds > > > >>>like a bandaid over a design problem to me.... > >>> > >>>What do others think? Do you use 802.3x flow control? Thanks. > >>> > >>>Priscilla > >>> > >>> > >>> > >>>[EMAIL PROTECTED] wrote: > >>> > >>> > >>>>I need some expert option on the following matter: > >>>> > >>>>I have a Netgear Fast Ethernet Switch FS608 (which does 802.3x > >>>>Flow > >>>>control) connected to a DLink 5 port switch (no flow control) > >>>> > >>>>Twice this week, the FS608 locked itself causing ALL traffic in > >>>>the company > >>>>to be disrupted. The problem was solved by power cycling the > >>>>switch. > >>>> > >>>>All the clients on the FS608 have 3Com network cards that > >>>>support flow > >>>>control. > >>>> > >>>>Here are my questions: > >>>> > >>>>1) Are there some caviat in running 802.3x I am not aware of? > >>>>I did > >>>>extensive research before implementing this and did not find > >>>>any issues with > >>>>the implementation of the technology? > >>>> > >>>>2) Is there an issue of running 802.3x on one switch and not on > >>>>the other? > >>>> > >>>>3) I could turn off the 802.3x feature on all the workstations > >>>>but I can't > >>>>turn it off on the FS608. This is NOT a managed switch. Any > >>>>suggestion on > >>>>how to troubleshoot this problem? > >>>> > >>>>Thank you, > >>>> > >>>>Pierre-Alex > >>> > >>>**Please support GroupStudy by purchasing from the GroupStudy Store: > >>>http://shop.groupstudy.com > >>>FAQ, list archives, and subscription info: > >> > >>http://www.groupstudy.com/list/cisco.html > >>**Please support GroupStudy by purchasing from the GroupStudy Store: > >>http://shop.groupstudy.com > >>FAQ, list archives, and subscription info: > > > > http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74528&t=74455 -------------------------------------------------- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
