Okay Ive had a day of it today , and I thought I would share this little support event experienced today. A Client site of mine runs Samba 2.2.8a connecting to a series of Windows XP boxes via a Netgear Switch/Hub. Earlier in the week they reported that certain applications, most notorously Symantec ACT were performing at super slow speeds. A non site investigation showed that any file opened from the Server , copied to the desktop client was being copied at super slow speeds, as if all the bandwidth on the network had gone. Checking configuration of the smb.conf and local machines proved no use at all and for a part of the hour I scratched my head as I tried to understand what was slowing down all file open, copy and move performance over the network. Since local file activity ( on the server or client ) was more than adequate I was non plussed, until I reasoned that the only other device between Client and Server was the Network Switch. A Quick power cycle of the Netgear switch later , and the performance was back where it should have been ! Just a salutory tail to tell really since the problem was neither Server or Client based, but the architecture was clearly malfunctioning. Does anyone know of a test I could have carried out in order to trouble shoot that particular issue ?
On Fri, Jul 30, 2004 at 06:12:13PM +0100, Nicholas Butler wrote:> Okay Ive had a day of it today , and I thought I would share this little > support event experienced today. > > A Client site of mine runs Samba 2.2.8a connecting to a series of > Windows XP boxes via a Netgear Switch/Hub. > > Earlier in the week they reported that certain applications, most > notorously Symantec ACT were performing at super slow speeds. > > A non site investigation showed that any file opened from the Server , > copied to the desktop client was being copied at super slow speeds, as > if all the bandwidth on the network had gone. > > Checking configuration of the smb.conf and local machines proved no use > at all and for a part of the hour I scratched my head as I tried to > understand what was slowing down all file open, copy and move > performance over the network. > > Since local file activity ( on the server or client ) was more than > adequate I was non plussed, until I reasoned that the only other device > between Client and Server was the Network Switch. > > A Quick power cycle of the Netgear switch later , and the performance > was back where it should have been ! > > Just a salutory tail to tell really since the problem was neither > Server or Client based, but the architecture was clearly malfunctioning. > > Does anyone know of a test I could have carried out in order to trouble > shoot that particular issue ?When I used to work on problems like that for Vantive all I did was put a sniffer on client and server and look for dropped packets. Once I found one or more on a lan segment I knew there was an equipment problem. Few people bother to do this these days - even though the lan equipment has got cheaper (and worse) than it used to be. Jeremy.
> -----Original Message----- > From: Jeremy Allison [mailto:jra@samba.org]> When I used to work on problems like that for Vantive all I did was > put a sniffer on client and server and look for dropped packets. Once > I found one or more on a lan segment I knew there was an equipment > problem. Few people bother to do this these days - even though the > lan equipment has got cheaper (and worse) than it used to be.People tend to overlook the basics. I've seen several performance problems fixed just by correcting mismatched duplex settings.
Nicholas Butler <> wrote:> A Client site of mine runs Samba 2.2.8a connecting to a series of > Windows XP boxes via a Netgear Switch/Hub.Budget constraints lead to me having to purchase Netgear managed switches (as opposed to something a little more traditionaly robust) a couple of years ago. They *were* horrible. Dropped packets, network slowdowns, entire print jobs vanishing. . . that sort of thing. I was forced to go back to some daisy chained hubs while I had it out with Netgear. A couple of firmware flashes later and everything's just fine. I still wonder how a company could have let a (highly priced) piece of equipment out the door in that state though, they should be ashamed. --J(K)
> Does anyone know of a test I could have carried out in order to trouble > shoot that particular issue ?Taking Ethereal and looking for large gaps between pakets. Seeing a lot of connection reset by peer messages in the log. Always check for full/halfduplex settings of the network cards.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 30 July 2004 01:12 pm, Nicholas Butler wrote: | | A non site investigation showed that any file opened from the Server | , copied to the desktop client was being copied at super slow speeds, | as if all the bandwidth on the network had gone. | | A Quick power cycle of the Netgear switch later , and the performance | was back where it should have been ! Our experience is that many/most NICs do not autonegotiate with many/most switches properly all of the time. What you saw is indicative of that. Rebooting the NIC just forces another autoneg... So, we no longer rely on autoneg. For all of the servers we manage we set the NICs forced to whatever the network switches are capable of. Most workstations don't use enough bandwidth to make this an issue, but for the ones that do, we force the NIC settings as well. Depending upon the NIC, we use either ethtool of mii-tool to get the job done. - -- _____________________________________________ A Message From... L. Mark Stone Reliable Networks of Maine, LLC 477 Congress Street, 5th Floor Portland, ME 04101 Tel: (207) 772-5678 Web: http://www.RNoME.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQFBDkIZ2cQw/ayGE2gRAlVHAJ0fVK/1FOecQWRJxvwpGo9RkujbBACfYEKG 973/uF9BSf/WqBT5OYy1vQE=RG9w -----END PGP SIGNATURE-----