WANProxy in Subversion is working again.

[Mallett, Juli]

Hi Uttam,

Thanks for your response -- the iperf results had me worried :)

There are currently no limits on the cache size, no discard facilities
and no immediate plans for disk caching.  I was working on disk-based
caching at one point but it's a slightly lower priority for me right
now.  I have been thinking about hiring someone to develop the disk
caching and related things, but am not sure yet whether I can justify
it.

Supporting discard is actually a little tricky because you have to
prevent symbol reuse.  I'm moving in the direction of making changes
that will enable that, namely by putting some more fields in the
symbol name rather than using it all for a hash, but that's happening
only opportunistically.  Supporting discard is a necessary
prerequisite for supporting disk-based caching.

Thanks,
Juli.

On Tue, Dec 21, 2010 at 18:49, Uttam Singh <us at iptvlabs.com> wrote:
> Hi Juli,
>
> Please disregard my 'iperf' results.
>
> I was using a server and client configuration file which had codec set
> to "None". After changing it to "codec0" I am seeing successful
> completion and big improvements!
>
> Without WanProxy iperf reports xfer throughput ~4.5Mbps
>
> With WanProxy iperf reports ~70Mbps. The data used by this iperf by
> default is [0..9] repeated pattern.
>
> great work! very very promising.
>
> Couple of questions on memory management:
>
> - is there any limit on how much memory wanproxy will use? over time
> will it exhaust all free memory?
> - is there any aging mechanism to discard less frequently used data caches?
> - I see that you have disk caching on your todo list, have you found
> any volunteers for that work?
>
> thanks,
>
> -Uttam
>
> On Tue, Dec 21, 2010 at 7:51 PM, Uttam Singh <us at iptvlabs.com> wrote:
>> Hi Juli,
>>
>> Just wanted to share some early results from wanproxy svn r653:
>>
>> - seeing great improvement in performance when moving data from Client
>> Proxy -> Server Proxy
>>
>> Setup: 5Mbps symmetrical WAN, SMB file transfers (binary file ~11MB)
>>
>> Without WanProxy:
>> Up: 4Mbps
>>
>> With WanProxy:
>> Up: 14Mbps
>>
>> - strange but did not observe any improvements over multiple transfers
>> of the same file in the other direction (Server Proxy -> Client Proxy)
>>
>> - iperf tests are still failing. iperf send repeated text patterns
>> which should be great for deflation but I am seeing Client-Proxy
>> sending much more data to Server-Proxy than it receives from Client.
>>
>> Client ------ Client-Proxy ................ Server Proxy ------ Server
>>
>> Run:
>> Server> iperf -s -p 5100
>> Client> iperf -c -t 10 -p 5100 (10 sec test)
>>
>> I see that client completes sending data to Client-Proxy followed by
>> TCP-FIN. Client-Proxy however continues sending data to Server-Proxy
>> for another ~30sec before closing. I haven't done any detailed
>> analysis except verify that iperf works successfully in the same setup
>> if I don't use WanProxy.
>>
>> thanks,
>>
>> -Uttam
>>
>> On Tue, Dec 21, 2010 at 2:48 AM, Mallett, Juli <juli at clockworksquid.com> wrote:
>>> Hey folks,
>>>
>>> I've recently spoken with a few people who needed to try features that
>>> were only available in WANProxy in Subversion, but there were bugs
>>> that prevented testing.  I've been buried with work for the last six
>>> months, but have taken a few weeks off now, in which I'm working on a
>>> couple of exciting enhancements to WANProxy as well as catching up on
>>> bug fixes.
>>>
>>> As of right now (well, as of r650), I believe that I have fixed the
>>> bulk of the problems that people were seeing.  There may be a few edge
>>> cases, particularly related to connection teardown, but things look a
>>> lot better.  If I get positive feedback from other testers, I will
>>> probably put together a release before the end of the year, as well as
>>> one shortly into the new year.
>>>
>>> Please report any problems you see except for a crash when exiting due
>>> to ^C / SIGINT.  I have been working on infrastructure related to
>>> multithreading and have broken signal handling as a result, but that
>>> will be fixed in the near future.
>>>
>>> Thanks,
>>> Juli.
>>> _______________________________________________
>>> wanproxy mailing list
>>> wanproxy at lists.wanproxy.org
>>> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>>>
>>
>