> > The protocol appears to be operating correctly in the > > "gettingafilefromamigaatawin2" capture. The slowdown is the > large time gaps > > between the receiving end (192.168.1.10) sending an > acknowledgement, and the > > sending end (192.168.1.120) sending the next data packet. > The gaps at that > > point appear to frequently be as much as two seconds. It > looks like the > > sender is busy doing something other than sending. > Strangely, this seems to > > occur most often near the end of the transmission of a 64K > chunk. This pause > > is absent during the transmission of the last chunk. I > wonder if the sender > > is busy in the middle of the transfer with queuing up the > next chunk. Slow > > disk access? > > Is it possible that the sender has not set TCP_NODELAY and > the OS has a > very long timeout waiting for more data from the application?
Richard, Thanks for looking into this. No, I have TCP_NODELAY setup in my smb.conf. I have alos tested with misc of the other possible "tune parameters" in this option. Here is the only useful info I found in a high level debug. -- [2002/06/25 03:47:55, 0] lib/util_sock.c:(853) With error = Protocol not available setsockopt: SO_REUSEPORT=0 on port 0 failed with error = Protocol not available -- I will install an hw raid solution this week as well as testing with another tpc/ip stack. Anybody remeber the most fatal errors with samba 2.0.7 core and Win2k ? I could mention that ftp flows very neat in both directions (~850kb/s) -- Ulf
