Jason Robitaille - Unthrottle Download Manager

[palmpre06062009]

Originally Posted by palmpre06062009

Any info? Just trying to better understand the info related to patch. Thanks.

webOS-Patches Web Portal

[capt4chris]

Originally Posted by palmpre06062009

webOS-Patches Web Portal

That page is out of date. It shows 8/26/2011 as the last update but the patch has been updated a couple times lately, last time being 9/11/2011.

[hotshot]

Jason,

Have you played with upping the max concurrent connections? In the PC world, at least, nobody settles for less than 10 these days, because the browsers are just too damn slow with fewer simultaneous connections.

[Xanadu73]

Originally Posted by hotshot

Jason,

Have you played with upping the max concurrent connections? In the PC world, at least, nobody settles for less than 10 these days, because the browsers are just too damn slow with fewer simultaneous connections.

You could always just modify the file yourself for testing...

/etc/palm/luna.conf


M.

[Xanadu73]

Hey!

I've decided to run some speed tests.

A while back while testing some kernel things for 'Psycho, I found a website ( Pingdom Tools ) that measures webpage load times. As far as I can tell from the site, it uses YOUR Internet connection, not theirs. The evidence from the above link to the kernel post and the following data supports that. The site supports saving tests for future reading/analyzing. The links are included in an attachment.

Hardware:

• Phone: Pre-
• OS: webOS 2.1
• Kernel: F105-71
• Carrier: Sprint

The attached files are:

• "Tests_And_Links.txt": The tests and links to the test I ran.
• "Speed_Test_Results_CSV.txt": A spreadsheet (in csv form), sorted by Time ascending, showing various times for various tests. Any Spreadsheet app should be able to import a csv just fine.

I tested changing only MaxConcurrent and MaxRecvSpeed. I did not play with MaxQueueLength as I don't really know what that means in this context.

I used "msnbc.com" as the test website. I figured it was a bloated enough page for "real world" testing.

Test Scenario:

1. Change value
2. Reboot
3. Clear Browser Cache
4. Run test

Results (Sorted by Time Ascending):




I think the data speaks for itself. The "Cap" of course is "65536" (Palm's setting), and un-capped is "-1" (Jason's setting). I also tested with "disabling" a hard-coded MaxConcurrent number, those tests are the "-1" in the "Threads" column.

I ran each MaxConcurrent change with and without a hard-coded MaxReceive number. The difference there is obvious. It seems that MaxConcurrent > 10, it starts to fall down. I didn't test higher than 15 MaxConcurrent. It's entirely possible that devices that have more RAM than my whimpy Pre- would perform better above 10 MaxConcurrent (or a Pre- running webOS 1.4.5 - there's MUCH more available RAM there).


I hope people find this interesting and maybe pass this info on to others to dissect as well.

Attachments:
Tests_And_Links.txt
Speed_Test_Results_CSV.txt

For those on Windows, you'll have to open the "Tests_And_Links.txt" file with WordPad (or Notepad++) because I use Linux and Windows uses a different EOL than the rest of the world does.


M.

[BenL]

Originally Posted by palmpre06062009

I ran speed tests with and without the patch. Cleared the cache between tests (with and without patch). Didn't see any noticeable diff. This was over wifi at home. The download speed was more or less around 12Mbits/sec. So not clear what the patch states that there is limitation of 64kb/s. May be patch description meant to say TCP window size of 64kbytes (65536 bytes)?

I wonder if 65536 is a typo/bug? 65535 is 0xFFFF, which is -1 for a signed short decimal number.
---Ben