I've put up the files on Anonymous-FTP on ftp://heineken.dyndns.ws
The files are Snipplets from the beginning of the transaction, covering the timeout, and ending during normal copying. verybadperformance1.txt is a brief text-output from etherreal (1.4MB) Frame 0-10018 verybadperformance2.txt is a detailed text-output from etherreal (5.9MB) Frame 0-3012 verybadperformance3.txt is a detailed text-output from etherreal (22.9MB) Frame 0-1248 The last transaction before the timeout is a write Request to the last byte of the target-file, at about 700MB. This is a typical move of windows-applications to check if enough space is available for the target. During the timeout my linux-box writes a tempfile to disk at size of the source-file. This is due to the write request from the client. If this lasts too long, the whole connection times out. Samba has a swith to prevent these temp-file-creation it's called "strict allocate" and I set it to "OFF" just to be shure. I'm really out of ideas, I don't know how to check sambas behaviour when it gets the write-request ! On Tue, 9 Jul 2002 13:29:19 +0200 "Ulf Bertilsson" <[EMAIL PROTECTED]> wrote: > Please do lookup and hint me to url, registry or related info. > I still have a dream that I mange to fix this :) > > Funny tho, one way it's all fine, just seems like "explorer" sends > anoying dos packets. > > -- > Ulf > > -----Original Message----- > From: Dan Barrett [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 24, 2002 9:31 PM > To: Esh, Andrew; Lars Heineken > Cc: Ulf Bertilsson > Subject: RE: Very bad performance when copying large files from windows > to samba-share > > > I've seen a problem similar to Ulf's. Reading data from a samba share > to a Win2k machine over a GigE network was slow. Turned out that the > app was issuing 64k reads, which with the SMB proto overhead would end > up as two SMB requests, 1 large and 1 very small ~65 byte transfer. So > every other SMB request was for only 65 bytes. > > This caused two problems. > 1. Too much SMB proto overhead since 50% of the SMB requests were only > transferring 65 bytes. We took a hint from Microsoft and changed the > app's readsize to 64420? bytes. Same as you seen when copying files > with Windows Explorer. > > 2. Delayed TCP Acking of the 65 byte packets since the TCP window > wasn't full. This delayed sambaserver from sending the 64k. If > anything similar is happening to Ulf I can lookup what we did to get > around this. > > Daniel Barrett > Storigen Systems > > -----Original Message----- > From: Esh, Andrew [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 24, 2002 2:59 PM > To: 'Lars Heineken'; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: Very bad performance when copying large files from windows > to samba-share > > > > This doesn't appear to me to be the same problem Ulf posted. When > looking at those captures, I saw no leading pauses in the data flow. > There was the usual directory information gathering, and then the first > write request at offset zero, right after that. The performance appeared > to be affected by the one or two second pauses near the end of nearly > every 64KB transfer chunk. > > -----Original Message----- > From: Lars Heineken [ mailto:[EMAIL PROTECTED]] > Sent: Monday, June 24, 2002 1:19 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Very bad performance when copying large files from windows > to samba-share > > > This the summary: > > Most interresting is the gap between the beginning of the transaction > and the actual writing (writing begins at about 45sec) > > Any traffic above this point is just minor. After the 45sec the "real" > transfer begins. > > As I found no way to search for checksum errors, I didn't found any.. > > The graph looks like this: > > -- > -- > -- > -------| > | > .......45s > > Or that in Bandwith: > > ###### > ------ > ###### > ------ > -------| > | > .......45s > > I can attach screenshots if interested. > > No. Time Source Destination Protocol > Info > 1 0.000000 lars-heineken.lan 192.168.10.255 CUPS > ipp://192.168.10.1:631/printers/HPLaserjet6L (idle) > > 2 10.996660 www.heineken.lan 192.168.10.255 CUPS > ipp://heineken.lan:631/printers/HPLaserJet6L (idle) > > 3 11.999360 lars-heineken.lan arne-heineken.lan TCP > hostname > boomerang [PSH, ACK] Seq=1926846500 Ack=1568123 Win=6432 > Len=28 > > 4 12.009310 lars-heineken.lan arne-heineken.lan TCP > hostname > boomerang [PSH, ACK] Seq=1926846528 Ack=1568123 Win=6432 > Len=36 > > 5 12.009479 arne-heineken.lan lars-heineken.lan TCP > boomerang > hostname [ACK] Seq=1568123 Ack=1926846564 Win=7704 Len=0 > > 6 13.987759 arne-heineken.lan lars-heineken.lan SMB > Tree Connect AndX Request, Path: \\LARS-HEINEKEN\IPC$ > > 7 13.989816 lars-heineken.lan arne-heineken.lan SMB > Tree Connect AndX Response > 8 13.990034 arne-heineken.lan lars-heineken.lan LANMAN > NetWkstaGetInfo Request > 9 13.990220 lars-heineken.lan arne-heineken.lan LANMAN > NetWkstaGetInfo Response > 10 13.990568 arne-heineken.lan lars-heineken.lan LANMAN > NetServerGetInfo Request > 11 13.990865 lars-heineken.lan arne-heineken.lan LANMAN > NetServerGetInfo Response > 12 13.991240 arne-heineken.lan lars-heineken.lan LANMAN > NetWkstaGetInfo Request > 13 13.991362 lars-heineken.lan arne-heineken.lan LANMAN > NetWkstaGetInfo Response > 14 13.992297 arne-heineken.lan lars-heineken.lan LANMAN > NetShareEnum Request > 15 13.992524 lars-heineken.lan arne-heineken.lan LANMAN > NetShareEnum Response > 16 13.993013 arne-heineken.lan lars-heineken.lan LANMAN > NetWkstaGetInfo Request > 17 13.993125 lars-heineken.lan arne-heineken.lan LANMAN > NetWkstaGetInfo Response > 18 14.045036 arne-heineken.lan lars-heineken.lan SMB > Open AndX Request, Path: \The Man Who Sued God > (2001).XPD.ShareReactor.avi > > 19 14.046435 lars-heineken.lan arne-heineken.lan SMB > Open AndX Response, FID: 0x1ba0 > 20 14.046757 arne-heineken.lan lars-heineken.lan SMB > Write Request, FID: 0x1ba0, 0 bytes at offset 719970304, 0 bytes at > offset 719970304 > > 21 14.079254 lars-heineken.lan arne-heineken.lan TCP > netbios-ssn > pe-mike [ACK] Seq=1974177356 Ack=1615097 Win=5840 Len=0 > > 22 15.895193 www.heineken.lan 192.168.10.255 RIPv1 > Response > 23 16.048326 arne-heineken.lan lars-heineken.lan SMB > Transaction2 Request FIND_FIRST2, Pattern: \* > 24 16.048429 lars-heineken.lan arne-heineken.lan TCP > netbios-ssn > pe-mike [ACK] Seq=1974177356 Ack=1615182 Win=5840 Len=0 > > 25 16.173695 arne-heineken.lan lars-heineken.lan SMB > Tree Disconnect Request > 26 16.173765 lars-heineken.lan arne-heineken.lan TCP > netbios-ssn > pe-mike [ACK] Seq=1974177356 Ack=1615221 Win=5840 Len=0 > > 27 26.109439 lars-heineken.lan 192.168.10.255 BROWSER > Host Announcement LARS-HEINEKEN, Workstation, Server, Print Queue > Server, Xenix Server, NT Workstation, NT Server > > 28 27.989388 lars-heineken.lan 192.168.10.255 CUPS > ipp://192.168.10.1:631/printers/HPDJ520 (idle) > 29 27.989448 lars-heineken.lan 192.168.10.255 CUPS > ipp://192.168.10.1:631/printers/lp (idle) > 30 30.989599 lars-heineken.lan 192.168.10.255 CUPS > ipp://192.168.10.1:631/printers/HPLaserjet6L (idle) > > 31 41.977621 www.heineken.lan 192.168.10.255 CUPS > ipp://heineken.lan:631/printers/HPLaserJet6L (idle) > > 32 45.886424 www.heineken.lan 192.168.10.255 RIPv1 > Response > 33 57.336317 lars-heineken.lan arne-heineken.lan SMB > Write Response, 0 bytes > 34 57.345345 arne-heineken.lan lars-heineken.lan SMB > Write Request, FID: 0x1ba0, 65487 bytes at offset 0, 65487 bytes at > offset 0 > > 35 57.345429 lars-heineken.lan arne-heineken.lan TCP > netbios-ssn > pe-mike [ACK] Seq=1974177397 Ack=1616681 Win=8760 Len=0 > > 36 57.345464 arne-heineken.lan lars-heineken.lan NBSS > NBSS Continuation Message > 37 57.345485 lars-heineken.lan arne-heineken.lan TCP > netbios-ssn > pe-mike [ACK] Seq=1974177397 Ack=1618141 Win=7300 Len=0 > > 38 57.345588 arne-heineken.lan lars-heineken.lan NBSS > NBSS Continuation Message > 39 57.345611 > > > On Mon, 24 Jun 2002 10:03:59 +0200 > "Ulf Bertilsson" <[EMAIL PROTECTED]> wrote: > > > > I did the ethereal-capturing. What looks very strange on > > > first sight: About 6 of 10 packest are described as: NBSS > > > Continuation Message. > > > Sometimes there are 6 of them one after another. > > > Is this normal ? > > > > Lars, > > > > Do you see any checksum errors in NBSS packet ? > > > > If you use the TCP Stream Analysis in Ethereal, > > how to the graphs look ? > > > > -- > > Ulf > > > >
