[Asus Transformer TF700] lucius.zen:
Didn't know ping tests use a different protocol than TCP/IP. Indeed, TCP/IP congestion algorithms should not impact scores on ping tests, as most use the ICMP protocol. Had no idea, never really cared about ping tests to begin with. Download/upload speeds can definitely be influenced by TCP/IP congestion algorithms though.

Regardless, how does the validity of the ping data influence reproducibility? The validity of the ping measure is inconsequential with respoect to the reproducibility and reliability of the other measures. Hell, althought it should be removed including the ping data does not impact reproducibility whatsoever. Validity and reliability (reproducibility) are not one in the same. The experiment is still highly reliable despite an invalid measure. Cutting out the ping data simply saves one from having to do a few calculations. Results will likely be of a different magnitude due to individual differences in network speed, tablet hardware/software, location, weather, time of day, etc. However, so long as they follow the same methodology and use the same app for testing (Speed Test by Optimal Software) similar patterns should arise following a significant number of trials.

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

In case anyone is wondering here is a quick and dirty breakdown of the TCP/IP protocol and how TCP/IP congestion algorithms impact network performance.

TCP/IP Congestion Algorithms

TCP/IP is a core set of communication protocols used over the Internet and similar networks. IP packets are the vehicle devices use to transfer data over a network. They are comprised of a header containing the source/destinatin address (among other things) and a payload, which contains the actual data to be sent from an application program to a host. TCP, part of the transport internet layer, provides intermediate communication between an application program and an internet host.

When sending large chunks of data an application program can issue a single request to TCP instead of breaking down data into a series of IP packets and requests. Due to network congestion and other factors packets sent using IP are often lost. TCP is responsible for detecting packet loss, requesting retransmission, reordering data, and minimizing network congestion to maintain the ordered delivery of packets between the sender/receiver. When the host receives a stream of packets it must reassemble the data into the form that it was originally sent. Once the receiver confrims the soundness of the data it sends a packet back to the sender acknowledging its retrieval. To avoid overloading the connection this aknowledgement must occur before more packets can continue to be sent/recieved.

For each connection TCP maintains a congestion window. The TCP congestion window is maintained by the sender and provides a means for preventing network congestion due to overload. When packets are aknowledged by the receiver the TCP congestion window size increases exponentially until a timeout occurs or the receiver reaches its limit. Thus, as more packets are acknowledged the maximum segment size (specifies the largest amount of data in a single TCP segment) of the congestion window becomes larger - every round-trip time the maximum segment size effectively doubles. A mechanism called "slowstart" controls the maximum segment size of the TCP congestion window. TCP congestion avoidance algorithms are responsible for controlling TCP communication in resonse to packet loss, or TCP congestion, via TCP window size, "slow-start", and the slow-start threshold. Thus, TCP congestion avoidance algorithms have a significant impact on the communication of packets between a sender/receiver.

---------- Post added at 09:34 AM ---------- Previous post was at 09:08 AM ----------

CROMI 5.2a, Hunds v3.4.2, Rom2SD, fsync disabled, GPU rendering enabled, plus a bunch of my own tweaks/mods. Fastest combo possible in my opinion. Tried out _that on 5.1.2 and 5.2a but it was laggier, doesnt feel like the same device. Been running Hunds for a long time, havent run into any issues on 3.4.1 and 3.4.2 with 5.2a. If your primary goal is smoothness thats the way to go. I can't stand lag, I wouldnt be able to continue using this tablet if it lagged. My new favourite pasttime is challenging and owning my friends with macbooks in webpage loading competitions lol. I used to dislike using this tablet for streaming flash videos bc it was buggy compared to full fledged laptops. At this point I can happily say if my roommate and I are going to stream some SP we us my the tablet rather than his macbook pro.

Here are some other tweaks I am using to boost performance. I have been reluctant to put them out until I am completely finished optimizing but I have seen great results in benchmark scores and everyday use thus fard so I will let you guys try them out for yourselves.

Governor Tweaks

go_maxspeed_load = 85 - improves responsiveness without noticeably hitting battery life

max_boost = highest freq available unless using stock freq (1900000 for me)

midrange_freq = set closest to middle of freq table unless using stock freq - needs to be recalibrated if not using stock freq or governor wont behave properly (760000 for me)

midrange_go_maxspeed_load = 65

Note - In order to apply these properly you must remove the three lines beneath "#CPU and VM Tweaks" in sdbags 50CleanTWEAKS init.d scriptmake this apply

Hunds Hotplug Config:

rt_config = 2 4 8

Note - In order to apply these properly you must remove the rt_config line (very bottom) from Hunds 99loadmodules init.d script

TCP/IP Congestion Algorithm:

Westwood

CPU/GPU Profiles:

Balanced - Now lowest power setting - used for light load computing:

- GPU Voltage/Freq = 1425/700

- Core 1 = 1600000

- Core 2 = 1600000

- Core 3 = 1540000

- Core 4 - 1540000

Power Save - Used for tasks with moderate load:

- GPU Voltage/Freq = 1425/700

- Core 1 = 1750000

- Core 2 = 1750000

- Core 3 = 1700000

- Core 4 = 1700000

Performance - Used for short, intense workloads:

- GPU Voltage/Freq = 1425/700

- Core 1 = 1900000

- Core 2 = 1900000

- Core 3 = 1850000

- Core 4 = 1850000

Things Unfinished:

- Retest all PMR tweaks

- Voltage table

- GPU voltage table

- Finish TCP tests

- Governor Tweaks - timer_rate, min_sample_time, max_normal_freq, go_maxspeed_load, midrange_go_maxspeed_load - for some reason I am unable to edit timer_rate and min_sample_time using init.d scripts - everything else in the script works, and if I run it manually the values change correctly; however, for some reason I am completely unable to set them at boot with an init.d script no matter what I try - I also want to test if setting max_normal_freq is better at 1500000.