This time with files *actually* attached!

----------------------------------------
> From: ap_griffiths AT hotmail DOT com
> To: martineau AT zmanda DOT com
> CC: dustin AT zmanda DOT com; amanda-users AT amanda DOT org
> Subject: RE: TCP Tuning
> Date: Thu, 22 Oct 2009 17:14:33 +0100
>
>
> Just one dle.
> No compression - data is already compressed (gzip).
> No encryption.
> I am using holding disk.
>
> Attached files: -
>
> amdump.1 direct from client
> amdump.3 through NFS.
>
> ----------------------------------------
>> Date: Thu, 22 Oct 2009 11:58:57 -0400
>> From: martineau AT zmanda DOT com
>> To: ap_griffiths AT hotmail DOT com
>> CC: dustin AT zmanda DOT com; amanda-users AT amanda DOT org
>> Subject: Re: TCP Tuning
>>
>> You talk about one dle or multiple dle?
>> Are you using compression or encryption? on client or server?
>> Are you using holding disk? or dumping directly to tape?
>> Post the amdump. file for when it use NFS and when it doesn't use it.
>>
>> Jean-Louis
>>
>> Alan Griffiths wrote:
>>> amgtar with blocksize set to 512 performs at the same speed.
>>>
>>> If I mount the partition on the backup server via NFS then the backup runs 
>>> about 6x quicker. So I'm assuming it must be something related to way 
>>> AMANDA sets up up the TCP connection. Although obviously open to other 
>>> suggestions.
>>>
>>> Alan
>>>
>>>
>>> ----------------------------------------
>>>
>>>> Date: Wed, 21 Oct 2009 06:59:01 -0400
>>>> From: martineau AT zmanda DOT com
>>>> To: ap_griffiths AT hotmail DOT com
>>>> CC: dustin AT zmanda DOT com; amanda-users AT amanda DOT org
>>>> Subject: Re: TCP Tuning
>>>>
>>>> Use the amgtar application and set the TAR-BLOCKSIZE to a bigger value
>>>> (half the STREAM_BUFSIZE.
>>>>
>>>> Why do you believe it is bottleneck?
>>>>
>>>> Jean-Louis
>>>>
>>>> Alan Griffiths wrote:
>>>>
>>>>> Thanks for the pointer.
>>>>>
>>>>> I've re-compiled with
>>>>>
>>>>> define STREAM_BUFSIZE (NETWORK_BLOCK_BYTES * 16)
>>>>>
>>>>> And I can see that has taken effect on the server
>>>>>
>>>>> dumper: try_socksize: send buffer size is 524288
>>>>>
>>>>> But backups are running no faster and I cannot see any indication on
>>>>> the client of the buffer size being used. Note: client also has the
>>>>> new binaries. In older versions of AMANDA amandad used to report
>>>>> buffer size, but this appears to not be the case in 2.6.1p1.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Alan
>>>>>
>>>>>
>>>>>> Date: Mon, 19 Oct 2009 10:03:21 -0400
>>>>>> Subject: Re: TCP Tuning
>>>>>> From: dustin AT zmanda DOT com
>>>>>> To: ap_griffiths AT hotmail DOT com
>>>>>> CC: amanda-users AT amanda DOT org
>>>>>>
>>>>>> On Mon, Oct 19, 2009 at 5:33 AM, Alan Griffiths
>>>>>> wrote:
>>>>>>
>>>>>>> Is there a way to modify the size of the TCP buffers used by
>>>>>>>
>>>>> AMANDA? I am
>>>>>
>>>>>>> trying to improve performance over a relatively high latency link
>>>>>>>
>>>>> and this
>>>>>
>>>>>>> seems to be the only way.
>>>>>>>
>>>>>> It's a source constant, unfortunately, set in stream.h (STREAM_BUFSIZE).
>>>>>>
>>>>>> A patch to make that configurable at compile time or, better, at
>>>>>> runtime would be much appreciated!
>>>>>>
>>>>>> Dustin
>>>>>>
>>>>>> --
>>>>>> Open Source Storage Engineer
>>>>>> http://www.zmanda.com
>>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> Download Messenger onto your mobile for free. Learn more.
>>>>>
>>>>>
>>>
>>> _________________________________________________________________
>>> New Windows 7: Find the right PC for you. Learn more.
>>> http://www.microsoft.com/windows/buy/
>>
>
> _________________________________________________________________
> Chat to your friends for free on selected mobiles
> http://clk.atdmt.com/UKM/go/174426567/direct/01/
                                          
_________________________________________________________________
New Windows 7: Simplify what you do everyday. Find the right PC for you.
http://www.microsoft.com/windows/buy/ 

amdump.1
Description: Binary data

amdump.3
Description: Binary data