[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.
Maybe the architecture is simple. That wasn't my point. My point was that a network design that includes a switch that can't keep up with a client NIC, or vice versa, is a bad design. And that's the only problem that 802.3x Ethernet flow control can fix. > My client was > complaining of slow > speed when opening files. How would 802.3x flow control help with slow speed when accessing files? It tells the other side to Pause. It could slow things down. I guess maybe in a good implementation, where the paused device has enough buffers, doesn't have head-of-the-line blocking problems, doesn't have bugs, etc, it could help, but many experts would agree with me that flow control is usually better handled by upper layers. TCP does a great job with it, for example. Also, you're the one that suspected flow control was the problem. You brought it up. What made you suspect it in the first place? Have you tried turning it off? I would trust your instincts on this and try disabling it and see if it helps the Netgear not to freeze. You asked if a sniffer would help in another message. I don't think a lot of sniffers can decode the Pause message. Also, they may not be able to explain why a device crashes. Looking at statistics would help with that, but you can't because it's an unmanaged device. A sniffer might help you figure out why file access is slow, though. Watch the access and the delay between packets. Do you see TCP ACKs quickly but don't see the application-layer reply quickly? That's pretty common and points to a server problem, not a problem with the network or internetworking devices in the network. If the ACK can get through, the network is fine. Or, possibly you see TCP ACKs, but the next packet from the client is delayed. That points to a client problem. Or maybe the client uses a small window size, etc. That kind of stuff you can see with an analyzer. Actually is it still slow since you did all those upgrades you mention below? It shouldn't be... I see below that you replaced the Netgear temporarily with Cisco. That's a good idea. :-) But seriously, the Netgear should work. The basic jobs of a Layer 2 switch, especially in an architecture as simple as what you have, shouldn't be hard to implement. It should just work. Disabling risky features like 802.3x sounds like a good test, though. Also, search the net for other causes of Netgear switches freezing? Does anyone on this list successfully use 802.3x? It would be nice to hear from someone how acutally uses it. Good luck with it. Please keep up posted on what you find out. Thanks. Priscilla Oppenheimer > 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=74533&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
