[Verizon Samsung Galaxy Note II] ffolkes:
I have added some new settings, as described below.

I also added some new tuneables to ZZMoove to help with the lag some people are experiencing. Naturally, ZZMoove strives to keep the frequency as low as possible, which does introduce lag for a second or two when you start interacting with the device. The new tuneables should help with that. From what I've heard on the international Note II forums, this has indeed helped with the lag people experienced on ZZMoove.

Changing the Screen-Off DTIM may yield battery savings for people who are around WiFi a lot. By default, it defaults to the WiFi access point's default value - which is very often as fast as possible. Will setting this higher result in any significant battery savings? I don't know yet. :P However I flashed an older kernel version, and testing shows that the power mode was NOT being reduced on screen-off. If I'm not overlooking something, our WiFi radios are on full-power constantly. So now I'm really curious to see if anyone notices any better battery life by setting "Max" for the Screen-Off Power Mode and/or setting the DTIM to like 5 or something.

.

Plasma kernel 2.03b6 for Verizon Note II

- ZZMoove: Added Frequency for Responsiveness

- ZZMoove: Added Responsiveness Up Threshold

- ZZMoove: Added Responsiveness Sampling Rate

- Silenced some unneeded kernel logging

- Switched default TCP congestion algorithm to Westwood (from Veno)

- Compiled with more TCP congestion algorithms (bic, cubic, htcp, reno, veno, westwood)

- STweaks: Added Network tab

- STweaks: Added option to change TCP congestion algorithm

- STweaks: Added options to change WiFi power mode for screen-on and screen-off states. "Max" = power saving mode. With Max, speed tests averaged 8mpbs down/15mpbs up, and normal mode (aka "Fast") averaged 40mbps/40mbps (which is still much less than my computer gets on the same speedtest.net server). How much battery might this save? I don't know.

- STweaks: Added options to change WiFi DTIM interval for screen-on and screen-off states.

.

New options on the ZZMoove Scaling tab of STweaks

[Frequency For Responsiveness] - Same functionality as the similarly named tuneable from other governors. This makes it easier to scale up from very low frequencies. Ultimately, it has the effect of "hovering" the CPU frequency at or near the value set here when idle. This should greatly help with lag issues. Automatically disables itself while suspended. Default: 400 MHz.

.

[Up Threshold Below Frequency For Responsiveness] - When Frequency For Responsiveness is set, and the current frequency is below (but not equal) to that frequency, this up threshold will take effect. The lower this is, the more quickly the governor will scale up. Can be used with or without Responsiveness Sampling Rate (the setting below this one). 0 disables this setting. Default: 40%.

.

[Sampling Rate Below Frequency For Responsiveness] - If the frequency is below the Frequency For Responsiveness, use this as the sampling rate. Goal: This will make the governor check more frequently to see if it needs to scale-up, which should help compensate for lag caused by very low frequencies. For example, when your finger first touches the screen and does something, if the CPU is at a low frequency, like 200 MHz, you'd normally have to wait ~100ms for the governor to even know there's demand before it would scale-up. This can easily create very obvious lag. So, this setting helps to make that transition as quickly as possible by offering you a faster sampling rate for very low frequencies. Can be used with or without Responsiveness Up Threshold (the setting above this one). 0 disables this setting. Default: 70000us.

.

.

New options on the Network tab of STweaks

[TCP Congestion Algorithm] - Sets the TCP congestion algorithm. It is explained here better than I could. Default: Westwood.

.

[WiFi Power Mode Screen-On] - Sets the WiFi chip's power mode when the screen is on. Testing shows that on average: Max = 8mbps down/15mmpbs up. Fast = 40mpbs down/40mbps up. How much less power is consumed in Max mode though? I don't know yet. Note: You MUST suspend and resume for changes to take effect!

.

[WiFi Power Mode Screen-Off] - Sets the WiFi chip's power mode when the screen is off. Remember, you MUST suspend and resume for changes to take effect!

.

[WiFi DTIM Interval Screen-On] - The Delivery Traffic Indication Message (DTIM) corresponds to every beacon sent by the WiFi access point, and lets clients know data is about to be exchanged. This interval allows your WiFi chip to sleep longer before it has to wake up and listen for broadcasts and multicasts. By default the driver uses a value of 0, which means it defaults to what the WiFi access point defaults to. Often times that default is 1 (as frequently as possible). The higher this number, the less power the WiFi radio will use, but the longer it will take before it knows data has arrived (aka push notifications may be slow). Note: You MUST suspend and resume for changes to take effect!

.

[WiFi DTIM Interval Screen-Off] - Sets the DTIM interval while the screen is off. Remember, you MUST suspend and resume for changes to take effect!

.

.

Some ping comparisons

I did some testing to see the differences between the different modes. From what I can tell, I guess the DTIM doesn't have any effect while in Fast mode? The data appears to support that theory.

Fast mode, 0 DTIM:

~ # ping 192.168.1.102

PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data.

64 bytes from 192.168.1.102: icmp_seq=1 ttl=128 time=10.8 ms

64 bytes from 192.168.1.102: icmp_seq=2 ttl=128 time=11.7 ms

64 bytes from 192.168.1.102: icmp_seq=3 ttl=128 time=11.7 ms

64 bytes from 192.168.1.102: icmp_seq=4 ttl=128 time=11.8 ms

64 bytes from 192.168.1.102: icmp_seq=5 ttl=128 time=11.7 ms

Max mode, 0 DTIM:

~ # ping 192.168.1.102

PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data.

64 bytes from 192.168.1.102: icmp_seq=1 ttl=128 time=61.9 ms

64 bytes from 192.168.1.102: icmp_seq=2 ttl=128 time=89.4 ms

64 bytes from 192.168.1.102: icmp_seq=3 ttl=128 time=111 ms

64 bytes from 192.168.1.102: icmp_seq=4 ttl=128 time=133 ms

64 bytes from 192.168.1.102: icmp_seq=5 ttl=128 time=42.6 ms

Fast mode, 1 DTIM:

~ # ping 192.168.1.102

PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data.

64 bytes from 192.168.1.102: icmp_seq=1 ttl=128 time=13.1 ms

64 bytes from 192.168.1.102: icmp_seq=2 ttl=128 time=11.7 ms

64 bytes from 192.168.1.102: icmp_seq=3 ttl=128 time=13.0 ms

64 bytes from 192.168.1.102: icmp_seq=4 ttl=128 time=11.8 ms

64 bytes from 192.168.1.102: icmp_seq=5 ttl=128 time=12.2 ms

Max mode, 1 DTIM:

~ # ping 192.168.1.102

PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data.

64 bytes from 192.168.1.102: icmp_seq=1 ttl=128 time=134 ms

64 bytes from 192.168.1.102: icmp_seq=2 ttl=128 time=48.7 ms

64 bytes from 192.168.1.102: icmp_seq=3 ttl=128 time=77.1 ms

64 bytes from 192.168.1.102: icmp_seq=4 ttl=128 time=101 ms

64 bytes from 192.168.1.102: icmp_seq=5 ttl=128 time=125 ms

Fast mode, 5 DTIM:

~ # ping 192.168.1.102

PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data.

64 bytes from 192.168.1.102: icmp_seq=1 ttl=128 time=12.6 ms

64 bytes from 192.168.1.102: icmp_seq=2 ttl=128 time=11.7 ms

64 bytes from 192.168.1.102: icmp_seq=3 ttl=128 time=11.8 ms

64 bytes from 192.168.1.102: icmp_seq=4 ttl=128 time=12.8 ms

64 bytes from 192.168.1.102: icmp_seq=5 ttl=128 time=11.7 ms

Max mode, 5 DTIM:

~ # ping 192.168.1.102

PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data.

64 bytes from 192.168.1.102: icmp_seq=1 ttl=128 time=503 ms

64 bytes from 192.168.1.102: icmp_seq=2 ttl=128 time=524 ms

64 bytes from 192.168.1.102: icmp_seq=3 ttl=128 time=449 ms

64 bytes from 192.168.1.102: icmp_seq=4 ttl=128 time=474 ms

64 bytes from 192.168.1.102: icmp_seq=5 ttl=128 time=493 ms

Fast mode, 10 DTIM:

~ # ping 192.168.1.102

PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data.

64 bytes from 192.168.1.102: icmp_seq=1 ttl=128 time=12.9 ms

64 bytes from 192.168.1.102: icmp_seq=2 ttl=128 time=12.3 ms

64 bytes from 192.168.1.102: icmp_seq=3 ttl=128 time=11.6 ms

64 bytes from 192.168.1.102: icmp_seq=4 ttl=128 time=14.3 ms

64 bytes from 192.168.1.102: icmp_seq=5 ttl=128 time=11.9 ms

Max mode, 10 DTIM:

~ # ping 192.168.1.102

PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data.

64 bytes from 192.168.1.102: icmp_seq=1 ttl=128 time=1976 ms

64 bytes from 192.168.1.102: icmp_seq=2 ttl=128 time=974 ms

64 bytes from 192.168.1.102: icmp_seq=3 ttl=128 time=999 ms

64 bytes from 192.168.1.102: icmp_seq=4 ttl=128 time=1014 ms

64 bytes from 192.168.1.102: icmp_seq=5 ttl=128 time=1281 ms

.