What about non managable switches that you can't force a setting? Don k
Sent from my BlackBerÿÿ® smartphone with SprintSpeed -----Original Message----- From: "Kim Longenbaugh" <k...@colonialsavings.com> Date: Thu, 5 Mar 2009 16:43:23 To: NT System Admin Issues<ntsysadmin@lyris.sunbelt-software.com> Subject: RE: file copy strangeness Hi, The nic was originally set to auto, with the switch on 100/full. I changed it to 100/full on both ends, with no change. I totally agree with you that autonegotiation can be a real pita. I also agree that something could have changed with out us being aware of it. The people that share this workstation could have made a change without letting us know (or being willing to admit). The good thing is that the account they log in with is a user account and is further restricted by GPOs. Thanks for the suggestions, and if you think of anything else please keep'em coming. -----Original Message----- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Thursday, March 05, 2009 4:34 PM To: NT System Admin Issues Subject: Re: file copy strangeness On Thu, Mar 5, 2009 at 1:49 PM, Kim Longenbaugh <k...@colonialsavings.com> wrote: > The workstation nic was set to auto, switch on 100/full ... That could be the problem right there. The way Ethernet is designed, if duplex is manually set, it *disables* auto-negotiation. So if one end is set manually and the other is on auto, the end on auto will conclude the other end must not be duplex capable, and use half-duplex. Google "duplex mismatch". >> Try the copy with ROBOCOPY to see if the problem is just with Explorer. > > Haven't tried that, but did try FTP'ing the file to the server, same results FTP's an even better test, because it's not using SMB at all. So this trouble exists in the IP layer or lower. Useful info. Hmmm. Or I suppose it could be a problem with the storage subsystem on the workstation. Copying a file to the workstation means writing to the disk. What if you copy a file locally, i.e., to the same disk. Does that go quickly? Maybe run CHKDSK, maybe defrag. Check Event Viewer for any errors. ÿÿ Check TCP window scaling on each end point. > > Didn't check this, and can't see how it would help unless one end or the > other got changed, since the transfer from the workstation was at expected > speed until the problem started, and again, nothing on workstation or server > was changed. You're seeing different behavior than you were at some previous time. *Something* changed. Of that, we can be certain. In such situations, ot's always a good idea to check possible causes, even the stuff you "know" can't have changed. As far as TCP window scaling goes: This lets a sender increase the window size, to allow more data to be "in the air" at a time. If TCP window scaling is enabled on the server but not on the workstation, that might explain things. It's just a guess, but it seems to fit. There are some other IP and TCP parameters that might affect things (maximum segment size, receive window size, maximum transmission unit, etc.), too. I forget where Windows keeps them all. But it's worth checking. I've heard of them getting screwed up and causing weird performance issues. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
