Very bad performance when copying large files from windows to samba-share

Tue Jul 9 05:07:02 GMT 2002

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" <ulf.bertilsson at adcomdata.no> 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:dan.barrett at storigen.com]
> 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:AEsh at tricord.com]
> Sent: Monday, June 24, 2002 2:59 PM
> To: 'Lars Heineken'; samba-technical at lists.samba.org
> Cc: ulf.bertilsson at adcomdata.no
> 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:Lars.Heineken at gmx.de] 
> Sent: Monday, June 24, 2002 1:19 PM 
> To: samba-technical at lists.samba.org 
> Cc: ulf.bertilsson at adcomdata.no 
> 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" <ulf.bertilsson at adcomdata.no> 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 
> > 
> 
> 