Sorry to be a network weenie, but.... What is the TCPWindowsize on the actual machine? Is it 65536? 63K is an odd number to see, you understand. I'm wondering if you have an RFC896 interaction going on, but I'm not sure. Basically, if you have TCP_NODELAY on (as you do in the dsm.opt file) you're agreeing to send small packets, however they are created. This keeps you from fully utilizing the packet, and can cause massive network congestion. Using larger packets matters as a measure of your MTU size, so I'm curious about that, too. Can you send the values for your network connection? I'm afraid I don't know enough W2K to tell you where to look, though.
-drs- David Stabler, CATE/AIX, CNCE Senior Systems Analyst >>> [EMAIL PROTECTED] 08/21/02 01:04PM >>> Zig- this is Win2k on an ethernet network-- the switch isn't an SP switch. But this are the settings in the dsm.opt file right now. I have played with resourceutilization, compression, and largecommbuffer. None make any difference. The one thing that really gets me is that even with verbose on, I see NO files passed to the server since I kicked off this trace at 10:51. This is going to a disk pool that is on a Shark, with nolimit on the file size. TXNBytelimit 25600 TCPBuffsize 32 TCPWindowsize 63 TCPNodelay YES LARGECOMmbuffer no COMPression No *quiet commrestartduration 30 commrestartinterval 20 RESOURceutilization 3 Zig Zag <veritrash@YAHOO. To: [EMAIL PROTECTED] COM> cc: Sent by: "ADSM: Subject: Re: Win2K domino 4.6 server slooooooowwwwww b/u Dist Stor Manager" <ADSM- [EMAIL PROTECTED]> 08/21/2002 11:14 AM Please respond to "ADSM: Dist Stor Manager" Lisa, Check you client dsm.sys file(Notes client) see what the TCPWINDOWSIZE 1024 TCPBUFFSIZE 128 TXNBYTELIMIT 25600 TCPNODELAY YES LARGECOMMBUFFERS YES I get decent thruput with this, I am also on SP using the switch.. --- Lisa Cabanas <[EMAIL PROTECTED]> wrote: > This machine's weekly b/a incr is deathly slow. The > nic is set at 100/full > and the Telcom guru has looked at the swtich, and > there is nothing amiss > there. > > But it takes forever... The incr kicked off Saturday > morning, and was still > going today, with lots of > 08/17/2002 11:56:10AM ANS1809E Session is lost; > initializing session reopen > procedure. > 08/17/2002 11:56:30AM ... successful > 08/17/2002 03:36:37PM ANS1809E Session is lost; > initializing session reopen > procedure. > 08/17/2002 03:36:57PM ... successful > 08/17/2002 05:16:19PM ANS1809E Session is lost; > initializing session reopen > procedure. > 08/17/2002 05:16:39PM ... successful > 08/17/2002 07:10:09PM ANS1809E Session is lost; > initializing session reopen > procedure. > 08/17/2002 07:10:29PM ... successful > 08/17/2002 07:38:21PM ANS1809E Session is lost; > initializing session reopen > procedure. > 08/17/2002 07:38:41PM ... successful > > > > I killed it off, and turned on some traces and see a > bunch (1.022 x 10^26) > of these in the trace out. This seem like a bad > thing to me. Is this a > TSM problem, or do I gather more info and tell the > server/domino gurus to > fix something? (Andy, which trace flags will get me > the most bang for my > buck?) > > > dsmem.cpp (1900): (Bad free list links) > > > tia > > lisa __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com