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=74526&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
