|
Readers have been asking me for a bit more background information about the issues in part one, this results in a far more technical article (follow up) than ever intended. And I hope the technical gurus among us can correct any errors here. As requested, here is more background to the settings...
To clarify the Window/Packet size tweak:
In a Windows environment we improve speed by editing what's called "rwin" (Receive Window) - In other words what is the largest receiving window size that works best for your Windows based PC. There are several other settings for Windows, however our blog is specifically for the benefit of the Ubuntu and Linux community.
Linux, Ubuntu, Fedora, etc. uses several configuration values. Below is what each "value" (in part one) refers to.
net.core.rmem_default
This refers to the DEFAULT size we want to set our RECEIVE window to.
net.core.rmem_max
This refers to the MAXIMUM size we want to set our RECEIVE window to.
net.core.wmem_default
This refers to the DEFAULT size we want to set our SEND window to.
net.core.wmem_max
This refers to the MAXIMUM size we want to set our SEND window to.
net.ipv4.tcp_wmem
Refers to the SEND window size range to use. The first number is the minimum size, the second is the default and the third is the maximum.
net.ipv4.tcp_rmem
Refers to the RECEIVE window size range to use. The first number is the minimum size, the second is the default and the third is the maximum.
net.ipv4.tcp_mem
In general, it refers to the memory buffer used for packet transactions. It keeps the communications buffers from being drained. Communication bottlenecks can occur if this value is too low.
net.ipv4.tcp_rfc1337
Enables or disables time-wait hazards. It's rather complicated as it is a feature that enables (or disables) the ability to handle some of the proposed TCP extension's new class of TCP failures. Check this url for the technical details: www.ietf.org/rfc/rfc1337.txt
(1 turns this on and 0 turns it off).
net.ipv4.ip_no_pmtu_disc
Maximum Transfer Unit (MTU) discovery. If you disable this setting, then the MTU settings will be calculated from the MTU's of all the hops along the path to the host (web site server) you are connecting. Again, 1 enables and 0 disables. MTU is the largest packet size that can be transferred in one physical frame at a time. Remember, the packet also contains the header and trailer information (addresses are part of each packet and are required by routers so that data can be sent to the correct addresses).
net.ipv4.tcp_sack
This refers to SACK (Selective Acknowledgment). The handling of out-of-sequence or duplicate data. When a packet is receive by a computer (the receiver), it send out an acknowledgment to the sending computer (the sender). In other words...
Receiver says to sender: "I got your packet. Please send the next packet".
But what happens when there are duplicate packets? According to www.ietf.org/rfc/rfc2883.txt (lots of details in this link), when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgment.
net.ipv4.tcp_fack
This refers to the control of data flow. Particularly to work with Sack (net.ipv4.tcp_sack above) in avoiding bottlenecks/data congestion. In other words, avoiding data traffic jams. It's a good idea to enable it "1".
net.ipv4.tcp_window_scaling
This refers to the increasing or decreasing of the window sizes. If memory serves me correctly, in Windows the size is static, but in Linux it is dynamic. Therefore, turning this on (by setting it to 1) enables the ability to change window sizes as needed.
net.ipv4.tcp_timestamps
Timestamps are used for RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences). RTTM I think is self-explanatory. PAWS protects against the old/duplicate packet overlaps. You can find more detailed information here: http://www.ietf.org/rfc/rfc1323.txt and here: http://www.scit.wlv.ac.uk/rfc/rfc13xx/RFC1337.html
net.ipv4.tcp_ecn
This ads ECN (Explicit Congestion Notification), details of which can be found here http://www.ietf.org/rfc/rfc3168.txt and here: http://www.ietf.org/rfc/rfc2884.txt
net.ipv4.route.flush
This simply flushes the routing cache. Systems store the routing information in a cache. How to get from point A to point B - In other words where to route (or send) the data, so that it gets to the next (correct) router.
As I mentioned, this follow-up is far too technical (in my opinion) that I ever intended, however it is here by request and I really do hope it helps.
And I hope some of you technical gurus can correct any mistakes or inaccuracies.
To clarify the Window/Packet size tweak:
In a Windows environment we improve speed by editing what's called "rwin" (Receive Window) - In other words what is the largest receiving window size that works best for your Windows based PC. There are several other settings for Windows, however our blog is specifically for the benefit of the Ubuntu and Linux community.
Linux, Ubuntu, Fedora, etc. uses several configuration values. Below is what each "value" (in part one) refers to.
net.core.rmem_default
This refers to the DEFAULT size we want to set our RECEIVE window to.
net.core.rmem_max
This refers to the MAXIMUM size we want to set our RECEIVE window to.
net.core.wmem_default
This refers to the DEFAULT size we want to set our SEND window to.
net.core.wmem_max
This refers to the MAXIMUM size we want to set our SEND window to.
net.ipv4.tcp_wmem
Refers to the SEND window size range to use. The first number is the minimum size, the second is the default and the third is the maximum.
net.ipv4.tcp_rmem
Refers to the RECEIVE window size range to use. The first number is the minimum size, the second is the default and the third is the maximum.
net.ipv4.tcp_mem
In general, it refers to the memory buffer used for packet transactions. It keeps the communications buffers from being drained. Communication bottlenecks can occur if this value is too low.
net.ipv4.tcp_rfc1337
Enables or disables time-wait hazards. It's rather complicated as it is a feature that enables (or disables) the ability to handle some of the proposed TCP extension's new class of TCP failures. Check this url for the technical details: www.ietf.org/rfc/rfc1337.txt
(1 turns this on and 0 turns it off).
net.ipv4.ip_no_pmtu_disc
Maximum Transfer Unit (MTU) discovery. If you disable this setting, then the MTU settings will be calculated from the MTU's of all the hops along the path to the host (web site server) you are connecting. Again, 1 enables and 0 disables. MTU is the largest packet size that can be transferred in one physical frame at a time. Remember, the packet also contains the header and trailer information (addresses are part of each packet and are required by routers so that data can be sent to the correct addresses).
net.ipv4.tcp_sack
This refers to SACK (Selective Acknowledgment). The handling of out-of-sequence or duplicate data. When a packet is receive by a computer (the receiver), it send out an acknowledgment to the sending computer (the sender). In other words...
Receiver says to sender: "I got your packet. Please send the next packet".
But what happens when there are duplicate packets? According to www.ietf.org/rfc/rfc2883.txt (lots of details in this link), when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgment.
net.ipv4.tcp_fack
This refers to the control of data flow. Particularly to work with Sack (net.ipv4.tcp_sack above) in avoiding bottlenecks/data congestion. In other words, avoiding data traffic jams. It's a good idea to enable it "1".
net.ipv4.tcp_window_scaling
This refers to the increasing or decreasing of the window sizes. If memory serves me correctly, in Windows the size is static, but in Linux it is dynamic. Therefore, turning this on (by setting it to 1) enables the ability to change window sizes as needed.
net.ipv4.tcp_timestamps
Timestamps are used for RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences). RTTM I think is self-explanatory. PAWS protects against the old/duplicate packet overlaps. You can find more detailed information here: http://www.ietf.org/rfc/rfc1323.txt and here: http://www.scit.wlv.ac.uk/rfc/rfc13xx/RFC1337.html
net.ipv4.tcp_ecn
This ads ECN (Explicit Congestion Notification), details of which can be found here http://www.ietf.org/rfc/rfc3168.txt and here: http://www.ietf.org/rfc/rfc2884.txt
net.ipv4.route.flush
This simply flushes the routing cache. Systems store the routing information in a cache. How to get from point A to point B - In other words where to route (or send) the data, so that it gets to the next (correct) router.
As I mentioned, this follow-up is far too technical (in my opinion) that I ever intended, however it is here by request and I really do hope it helps.
And I hope some of you technical gurus can correct any mistakes or inaccuracies.
