TCP Optimizer version 2.0.2 Beta

[Philip]

We've released an updated beta version of the TCP Optimizer 2, including a couple of non-essential bug fixes as described below. Note this is still a "Beta" version of the program intended for testing purposes. The latest stable release can be downloaded here: TCP Optimizer v 2.0.1

The latest beta version can be downloaded here:

TCP Optimizer v 2.0.2 Beta

The online documentation is available here: TCP Optimizer Documentation




List of updates and fixes in the current beta version:

1. Added all virtual NICs to the Network Adapters pull-down menu to account for nVidia and other on-board network cards with non-standard drivers. Sorted the pull-down menu by IP class for easier identification of the correct NIC (external IPs and the most likely NIC should be towards the top of the pull-down menu).
2. Replaced the "NegativeCacheTtl" advanced setting with "MaxNegativeCacheTtl" for Windows XP and 2003 Server (retained "NegativeCacheTtl" for Windows 2000). Note the "NegativeCacheTtl" setting is not removed by the program currently, that might change still in the final 2.0.2 version.
3. Added back the Tcp1323 options for Windows 95, although it is up to the user to update Windows and determine support for scaled RWIN values.
4. Fixed the version numbers to display correctly in the program properties.

You can view previous updates and past issues in the following threads:
version 2.0.1 final
version 2.0.0 final
version 2 beta

[Philip]

Any coments/problems with the 2.0.2 beta ?

[Cypher]

I like this version allot. Here's my specs:

- XP Pro w/ all updates and SP2 TCP fix.

- Intel Pro/1000 CT integrated NIC (Asus P4C800-E DLX) using Intel 10.0 Version 8.5.14.0 Drivers. Static IP with DHCP disabled.

- Router= Crappy Vonage Linksys RT31P2. (Which is somehow faster than my Nexland ISB)

- ISP=Comcast @ 8000/768

- TCP Opt. settings:MTU=1500 RWIN 921600, MTU=Y, BHD=N, Sel.Ack=Y, Max Dup. Acks=2, TTL=64, TCP 1323= scaled, Host Res=5,6,7,8, LAN= Opt., ToS=92, DNS error all set to 0, LAN Req. Buf=16384.

-OOL and AOL FTP test levels at 1100 using the latest FF build.

Looks great to me Phillip, keep up the great work. :2cool:

[Philip]

Please someone test this for the Windows 95 Tcp1323 addition as per the requests from version 2.0.1 ... Also, if there are no other bugs found this might become the final 2.0.2 release soon.

[rafi_d]

Here are two problems:
1. In Advanced tab - ALL "host-resolution" values are 0. The real values are: XX 00 00 00 which should display XX.
2. In "general" tab - when selecting "custom settings" - the existing RWIN value is being changed to some random (bigger) value. It should stay the same.

Thanks for a great software!

[Philip]

Here are two problems:
1. In Advanced tab - ALL "host-resolution" values are 0. The real values are: XX 00 00 00 which should display XX.

What Operating System ? All the "host resolution" values are set to low numbers, and not at the same priority. They should be set, and are, as far as I know to 5,6,7,8. This is intentional and by design. The Optimizer displays the decimal equivalent of the hex values you quote, as it should.

2. In "general" tab - when selecting "custom settings" - the existing RWIN value is being changed to some random (bigger) value. It should stay the same.

Thanks for a great software!

What Operating System ? It should not change when switching from "Optimal" to "Custom", and it does not on our test machines ?


Thanks for your input, please try to be a bit more descriptive so we can reproduce/identify the problems.

[mccoffee]

What Operating System ? All the "host resolution" values are set to low numbers, and not at the same priority. They should be set, and are, as far as I know to 5,6,7,8. This is intentional and by design. The Optimizer displays the decimal equivalent of the hex values you quote, as it should.



What Operating System ? It should not change when switching from "Optimal" to "Custom", and it does not on our test machines ?


Thanks for your input, please try to be a bit more descriptive so we can reproduce/identify the problems.

Problems running on Win98SE in the title of his thread boss

[Philip]

Problems running on Win98SE in the title of his thread boss

Umm... Uninstall OS, unplug, pack and return to the store.

[mccoffee]

Umm... Uninstall OS, unplug, pack and return to the store.

only if we could treat women the same way

[MousePotato]

When chosing "Optimal Settings" it negates the Faster Web Page loading tweak ??


- shouldn't the faster web page loading tweak be part of "Optimal Settings' ???


DnsPriority = 1
HostsPriority = 1
LocalPriority = 1
NetbtPriority = 1

[Philip]

When chosing "Optimal Settings" it negates the Faster Web Page loading tweak ??


- shouldn't the faster web page loading tweak be part of "Optimal Settings' ???


DnsPriority = 1
HostsPriority = 1
LocalPriority = 1
NetbtPriority = 1

It does not "negate" anything, it applies our version of the tweak as per this article: http://www.speedguide.net/read_articles.php?id=1130

By default, those services have priorities as low as 2000 (with higher numbers being lower priority). Also, every service has its own priority, they're not all set to the same level. What the Optimizer does is set them to different priorities, all being very high (low numbers = high priority).

It's been that way before, you can see different versions of the tweak on different sites. I believe ours to be correct and at least as good as, if not better than the others.

[rafi_d]

What Operating System ? All the "host resolution" values are set to low numbers, and not at the same priority. They should be set, and are, as far as I know to 5,6,7,8. This is intentional and by design. The Optimizer displays the decimal equivalent of the hex values you quote, as it should.



What Operating System ? It should not change when switching from "Optimal" to "Custom", and it does not on our test machines ?


Thanks for your input, please try to be a bit more descriptive so we can reproduce/identify the problems.

Problems running on Win98SE in the title of his thread boss

Umm... Uninstall OS, unplug, pack and return to the store.

Well, thanks for the output... at least I don't see my OS in the headlines on Windows' security problems ...
I will be more then happy to provide more info if you, guys, do not have a 98SE 'test platform'. There are a few of us - 98 users - left, you know ... can you make them happy too ?!

[5MpstweakR]

Please someone test this for the Windows 95 Tcp1323 addition as per the requests from version 2.0.1 ... Also, if there are no other bugs found this might become the final 2.0.2 release soon.

for win95...

My ability to test is limited in that I do not wish to change my current settings by making actual changes.

With that in mind here is what I noticed when I ran the beta:

my current settings:

scaling off, and rwin set to 64240 (I'm getting speeds in the 4.65 to 4.75 range without packet loss which is well over the 90% threshold for optimization)
time stamps off
mtu discovery on
black hole no
selective ack yes (but does not work for win 95)

********

testing follows:

I moved the slider to 5 megs or 5000

1) I selected optimal setting

The Rwin the program chose was 513920 <--- (way too high as with 2.0.1)
scaling was checked (so Tcp1323Opts appears to work)

other settings the program chose:

mtu yes
black hole no
ack default


2) I selected custom settings:

rwin was limited to a 5 figure number, in other words I could not enter 128480 even when scaling was checked

_________________

http://forums.speedguide.net/showpos...7&postcount=12

http://forums.speedguide.net/showpos...8&postcount=30

bottom line is although the Tcp1323Opts is now available there appears to be a couple of minor adjustments needed as follows:

1) the optimal settings for rwin was way to high just as before (you may want to change this number to default to either 44 or 88 times MSS, not 352 times MSS.

the only difference is Tcp1323Opts (scaling & time stamp) is now available

2) under custom settings the rwin slot was limited to 5 numeric characters

this prevents someone from experimenting with multiples of in my case 64240... 128480, 256960 or even 513920 if one wanted to make the custom setting follow the optimal setting the program chose in 1 above.

Again I am limited in testing this as explained.

If anything above is not clear let me know.

[Philip]

Well, thanks for the output... at least I don't see my OS in the headlines on Windows' security problems ...
I will be more then happy to provide more info if you, guys, do not have a 98SE 'test platform'. There are a few of us - 98 users - left, you know ... can you make them happy too ?!

We have been trying to make a well rounded program that works with all current Windows versions, including Windows 98. It has been tested extensively before.

What mcoffee said, and what I responded was a joke.

[Philip]

for win95...

My ability to test is limited in that I do not wish to change my current settings by making actual changes.

You can test pretty effectively without actually applying the settings, since the "Apply Changes" button brings up a review of all changes to the Registry that would actually be made.

The Rwin the program chose was 513920 <--- (way too high as with 2.0.1)
scaling was checked (so Tcp1323Opts appears to work)

For a 5 Mbit connection with 500 ms max latency it is the lowest valid RWIN value that would allow for full throughput. The value is based on the bandwidth*delay product, directly by the book... If you want to base everything on a lower latency, there is an option in the preferences.

2) I selected custom settings:

rwin was limited to a 5 figure number, in other words I could not enter 128480 even when scaling was checked

That might have to be fixed, thanks for the input.

1) the optimal settings for rwin was way to high just as before (you may want to change this number to default to either 44 or 88 times MSS, not 352 times MSS.

the only difference is Tcp1323Opts (scaling & time stamp) is now available

2) under custom settings the rwin slot was limited to 5 numeric characters

this prevents someone from experimenting with multiples of in my case 64240... 128480, 256960 or even 513920 if one wanted to make the custom setting follow the optimal setting the program chose in 1 above.

Again I am limited in testing this as explained.

If anything above is not clear let me know.

I don't see 1) as a problem, as I've stated before RWIN in the Optimizer is based on the bandwidth*delay product, which is the undisputable test for the size of RWIN. The only arguable fact is what maximum possible latency should be used, and that is selectable in the preferences of the program.

As far as not being able to select high custom settings in Windows 95, it will be fixed in the final version, thanks for the constructive feedback.

[rafi_d]

We have been trying to make a well rounded program that works with all current Windows versions, including Windows 98. It has been tested extensively before.

What mcoffee said, and what I responded was a joke.

Ok then. I'll try to explain the two problems better (Win98...):
1. When you look at the registry values you can see 5,6,7,8 but the optimizer shows 0's (in both optimized, and current)
2. The RWIN field IS changing value when selecting custom then current

I'll post screenshots later...

[Philip]

Ok then. I'll try to explain the two problems better (Win98...):
1. When you look at the registry values you can see 5,6,7,8 but the optimizer shows 0's (in both optimized, and current)
2. The RWIN field IS changing value when selecting custom then current

I'll post screenshots later...

I'll test that for 1., thanks for the information.

For 2. above, what is your "current" RWIN value (in the Registry and as shown by the Optimizer) ? What is the "custom" ? What is the "optimal" and your selected speed ?

[rafi_d]

I'll test that for 1., thanks for the information.

For 2. above, what is your "current" RWIN value (in the Registry and as shown by the Optimizer) ? What is the "custom" ? What is the "optimal" and your selected speed ?

Here you are:



And here (@500ms default, my current setting was for 200) :

I think that-
* "custom" values should stay the same as all "current" values
* and checking "PPPOE/DSL" should change only the MTU value. If you choose to modify RWIN - maybe change it to the nearest multiple of MSS lower then your BDP calculator shows.

[5MpstweakR]

For a 5 Mbit connection with 500 ms max latency it is the lowest valid RWIN value that would allow for full throughput. The value is based on the bandwidth*delay product, directly by the book... If you want to base everything on a lower latency, there is an option in the preferences.

I don't see 1) as a problem, as I've stated before RWIN in the Optimizer is based on the bandwidth*delay product, which is the undisputable test for the size of RWIN. The only arguable fact is what maximum possible latency should be used, and that is selectable in the preferences of the program.

As far as not being able to select high custom settings in Windows 95, it will be fixed in the final version, thanks for the constructive feedback.

Philip, I appreciate your product and all the work you and others have put into it.

I went back to the TCPO 2.0.2 beta and did the following to test the latency concept:

1) Top menu I selected preferences popup box showed max latency @ 500 just like you said. I selected 100 ms and pressed ok

2) on the general settings tab I selected optimal settings and the program pulled back the same figure 513920 for Rwin.

3) I did two calculations for a 5 Mps connection as follows and if I am using the right formula I got a different answer than the TCPO program

(Maximum Bandwidth x Maximum Anticipated Latency) / 8

a) 500 ms latency

(5000 x 500) / 8 = 312500 To make it a multiple of MSS divide by 1460:

312500 / 1460 = 214.0411 Then round up to the nearest even whole number:

214 x 1460 = 312440 - Optimum RWIN
216 x 1460 = 315360 - Optimum RWIN


b) 100 ms latency

(5000 x 100) / 8 = 62500 To make it a multiple of MSS divide by 1460:

62500 / 1460 = 42.80822 Then round up to the nearest even whole number:

44 x 1460 = 64240 - Optimum RWIN

Note: 64240 is what I am using for my RWIN

If I am using different data and or formula this still would not explain why when I changed the latency to 100 ms the TCPO program came back with the same RWIN of 513920, unless I did something wrong within the program. Also if the formula and data I used is correct, the calculations above show a different RWIN for 500 ms latency.

********************

Bottom line you are spot on in the use of latency as a preference item. You did not need me to confirm that, however...

I presented the above to provide additional info for you in case the formula and data I used is correct to compare against what TCPO program provides when optimal setting is selected.

[Philip]

You are generally right in your calculations, however seems you have discovered another Windows 95 bug in the program. The Optimal RWIN should be calculated as 256960 (1460 x 44 x 4), and 62780 for 100ms (1460x43).

It is being calculated as that in Windows xp/wk/2k3, seems what you're reporting is another Windows 95 bug.





Note: Above 65535, the Optimizer picks the largest non-fragmented unscaled RWIN times a scale factor, just like it is in the TCP/IP headers. The reason for that is we are also optimizing for possible older nodes that don't support large TCP Windows, as well as the many computers that have Window scaling turned off. In these cases the Optimizer window will be negotiated at the largest possible 64240.

If you pick a RWIN of 315360, you will end up having 39420 unscaled RWIN x 8 = 315360 in the TCP headers (note there is only room for a 16 bit number, and a scale factor in the TCP 1323 Options). If the other end is limited to a 65535 TCP Window (as many computers are), or/and has TCP1323 Options off, you may end up negotiating a much smaller RWIN, your unscaled 39420, vs our version of 64240.