wanproxy performance

[Uttam Singh]

Hi Juli

Thanks for your help so far.

wanproxy from svn/trunk seems to be broken. Please see other details below.

A real WAN connection is being used in my tests. I have a VDSL2
100Mb/100Mb connection between client and server site. I am modifying
DSL settings to force WAN connection speed at 5Mb/5Mb for these tests.

I have checked out and built wanproxy from svn/trunk and file
transfers (upload or, download) don't work now. I did a gmake clean
and a top level build of everything under wanproxy.

I see file transfer start but it hangs pretty much after first dozen
packets are sent between the 2 proxies. If I revert back to the 0.6.2
wanproxy build, without changing any other variable, things work like
before.

Tack Results:

1. sample test file (~10MB binary file)

%tack -TQc ~/test1.bin
1291591407.945118 [/codec_timer] INFO: 169 timer samples.
1291591407.945336 [/codec_timer] INFO: 4804377 total runtime.
1291591407.945406 [/codec_timer] INFO: 28428 mean microseconds/call.

2. sample text file (~10MB text file)

%tack -TQc ~/test1.txt
1291592129.859450 [/codec_timer] INFO: 159 timer samples.
1291592129.859670 [/codec_timer] INFO: 1353549 total runtime.
1291592129.859812 [/codec_timer] INFO: 8512 mean microseconds/call.

Please let me know if you need any debug output from wanproxy.

thanks,

-Uttam

On Sat, Dec 4, 2010 at 10:00 PM, Mallett, Juli <juli at clockworksquid.com> wrote:
> Hi Uttam,
>
> To do your WAN simulation, are you using dummynet on the systems in
> question, or are you simulating those links separately (or using real
> links)?
>
> I suspect that the problem is either one of the performance
> pessimizations that I recently fixed in Subversion or something in
> network configuration.
>
> Just to be sure, can you do one or both of these:
>
> (1) Build 'tack' in programs/tack and run 'tack -TQc file.bin' where
> file.bin is the file you're transferring.  This will give some idea of
> how fast the XCodec is on that file.
> (2) Rebuild WANProxy on both systems from Subversion.
>
> To build from Subversion do:
> sudo pkg_add -r subversion (if you don't already have it installed)
> svn co http://wanproxy.org/svn/trunk wanproxy-src
> cd wanproxy-src/programs/wanproxy
> gmake NDEBUG=1
>
> I did a few tests on a netbook that I have with a similar CPU and it
> looks like it should be able to handle as much as 100Mbps for some
> kinds of data.  I'm very surprised by the poor performance you note,
> so I am wondering if it's a problem with latency simulation or similar
> (for instance, putting the latency between the client and the client
> wanproxy rather than just between the two wanproxy boxes.)
>
> Hopefully we can work this out quickly!
>
> Thanks,
> Juli.
>
> On Sat, Dec 4, 2010 at 07:11, Uttam Singh <us at iptvlabs.com> wrote:
>> Hi Juli
>>
>> Thanks for your prompt response
>>
>> I see your point, my performance results may be system bound.
>>
>> My Wanproxy systems have the following specs:
>>
>> - 1.6GHz dual-core Atom
>> - 2GB 533MHz DDR2 memory
>> - FreeBSD 8.0 Stable dedicated for wanproxy
>> - each system is running build wanproxy-0.6.2 downloaded from
>> http://wanproxy.org/releases/wanproxy-0.6.2.tar.gz
>>
>> - In my tests I am trying to get best results possible, I am doing
>> multiple transfers in succession (i.e. upload multiple times and then
>> download multiple times)
>>
>> I changed my WAN settings to 5Mbps symmetrical (up/down).
>>
>> Now I get following results while transferring same file multiple times:
>>
>> No Wan Proxy:
>>  - Up: 4Mbps
>>  - Down: 4Mbps
>>
>> Wan Proxy:
>>  - Up: 3.23Mbps
>>  - Down: 2.71Mbps
>>
>> So compression may be adding to the latency here. Maybe given the
>> system spec, this is only meaningful for slow links (1Mbps or, less).
>> Though I don't quite understand why the CPU usage stats are so low.
>> Also, there is still a material performance difference between upload
>> and download - which is an anomaly.
>>
>> Please see other comments inline >>
>>
>> On Fri, Dec 3, 2010 at 9:53 PM, Mallett, Juli <juli at clockworksquid.com> wrote:
>>> Hi Uttam,
>>>
>>> Can you give me some information on the systems that you are running
>>> WANProxy on?  You should see deduplication in each direction, although
>>> they are, right now, independent — that is, if you upload a file and
>>> then download it, you won't get the benefit.  This is a short-term
>>> shortcoming that did not used to exist, but is necessary during a
>>> transitional period in which I am working on improving support for
>>> many-clients, many-servers models of use, as opposed to the old
>>> one-client one-server model.  I think that your test involves multiple
>>> downloads of the same file, so you should see performance improvements
>>> on download.
>>>
>>> I have a few more questions (and will flesh out the one I started this
>>> message with):
>>>
>>> 1) Are you using a Subversion-built version or an old release?
>>
>>
>>>> 0.6.2 tar release
>>
>>
>>> 2) Are the systems WANProxy is running on very fast?  I'm wondering if
>>> 2Mbps is as fast as the build of WANProxy you are using can run — it
>>> seems unlikely since that is quite slow, but I want to be sure.  I've
>>> made a lot of performance improvements lately, so if you're running a
>>> Subversion build this should definitely not be the problem unless you
>>> are running on systems with very slow RAM or CPU.
>>
>>
>>>> 1.6GHz dual-core Atom with 2GB 533Mhz RAM. Wanproxy systems are dedicated and not running much of anything else.
>>>> While doing the file transfers I see Wanproxy top out at 5 - 8% CPU (while CPU is 90+% idle)
>>
>>
>>> 3) Are you in fact doing multiple downloads and multiple uploads for
>>> your tests of the same file, or are you doing an upload and then a
>>> download and then another upload or...what?
>>>
>>
>>>> Multiple uploads of the same file and then multiple downloads of the same file.
>>
>>> I hope that we can resolve your performance issues!
>>>
>>> Thanks,
>>> Juli.
>>>
>>
>