|
Home | Reviews | Speed Test | Tools | News | Forums | Info | About | Join |
7. Tweaks Tester
______________________________ The Window surrounded in red will appear before the test is completed. You must fill it in correctly for valid results. Using the drop-down menus: 1. Enter the type of service that you have, in this case, Cable. 2. Enter the advertised speed from your ISP, which, in this case, is 3000kbps. If you have cable, you may have to pry this answer out of them. 3. The operating system that you use, in this case, Windows 98SE. 4. The connection type that you have, in this case, Normal. If you use PPPoE, enter which one. ~~~~~~~~~~~~~~~~~~~ The following are the only settings/readings to be concerned with: "Receive Window" is the RWIN that your machine is actually reporting, regardless of what may be entered into your registry and DRTCP. Suggestions for this setting are given at the bottom of the test. Note that the above test is recommending a lower RWIN setting. "Path MTU Discovery" should be ON for most every connection, or upload MTU (see "Max packet recd") will be compromised. "Windows Scaling" is only needed when RWIN is greater than 65535. Should read "OFF" if lower than 65536. "Time Stamping" may be used on lines that experience packet loss. "Selective Acks" should be on. "MSS" is the "Maximum Segment Size." In practice, that means the amount of space used in each packet to hold your "data." It is the size of the "Data Field" of your packets, generally both downloaded and uploaded packets. This should always be 40 less than your MTU (Max packet recd on tester). "TTL" is time to live, and it should be 64 or 128 (not a speed setting!). If you use a router/firewall, the number shown may be inaccurate. ~~~~~~~~~~~~~~~~~~~ "Max packet sent" (MTU) is download and the size packet that DSLReports sent you during the test. "Max packet recd" (MTU) is upload and the size that DSLReports received from you. If this is less than Max packet sent, your Path MTU Discovery may be OFF (seeing 576 is common if it's OFF). For PPPoE, MTU should be between 1454 and 1492. For non-PPPoE, and PPPoA, it should be 1500. "Transfer efficiency" refers to how well the packets sent to you were received. 90-100% is considered acceptable. This will vary throughout the day and night as traffic varies on the Net. ~~~~~~~~~~~~~~~~~~~ "ICMP (ping) check" is to show basic ping packet loss. Make yourself pingable before running the test. This can show line issues not otherwise seen. Note that in this test the user was not pingable. Also note that ping is non-adjustable. ~~~~~~~~~~~~~~~~~~~ Follow FAQs suggested (if any) to fix issues noted. As the test states at the bottom, "Still stuck? Copy/paste this URL." Please post that URL to the Tweaks Forum if you require assistance. You must also answer the other 11 questions found here. by Pinan edited by JMGullett The purpose of TCP is to cope with links that may exhibit packet loss, or may even allow packets to arrive out of order or in duplicate. The tweak tester can notice packet retransmissions during the test file transfer. This is not a disaster. The Internet has weather, and the weather is not always sunny. When there are storms (congestion or other problems en-route), packets can get dropped and must be sent again. Persistent and high numbers of retransmissions may also be due to a high RWIN (receive window) on your end, which is why they are reported. Retransmissions of data reduce throughput, reducing the speed at which you receive data. Particularly lossy links (perhaps representing ISP congestion, or even problems on your own line), wreak havoc on download speeds, even reducing them to a crawl. A Line Quality Test may reveal more about the source of your packet loss problems. Feedback received on this FAQ entry:
edited by JMGullett Finding the ideal RWIN is one very good reason for becoming pingable, as RWIN is found using a calculation of latency (ping) and speed. The Line Quality test needs you to be pingable as well. Once testing is completed, simply make yourself non-pingable again. by Pinan edited by JMGullett This problem is quite common and is not a big issue. Congestion on the Net is the cause, which will fluctuate throughout the day/night. If it is a consistent finding, run a Line Quality Test and look for slow, bogged-down servers (red & yellow warnings). The most important thing is speed. If your speeds are fine, then don't be concerned with this. Feedback received on this FAQ entry:
by Pinan edited by JMGullett There are several reasons why the tweak tester might not work for you: • It is offline. • It was too busy at the time you requested the test. • You've tested more than 5 times in a short period. • Your Java setup is broken. • Your MTU is too high. The last reason needs some further explanation: the tweak applet, if it loads ok, starts by sending some data upstream to us. If all this data is not received, then the tweak test results may not even get reported back to you. This is probably an MTU problem. Some hardware firewalls require that you lower your MTU slightly. Try the test without the firewall to see if it works. Or, just try to lower your MTU using DrTCP, described elsewhere in this FAQ. Feedback received on this FAQ entry:
edited by JMGullett Sorry. Starband locks their settings to those below. There is no "fix" for this as of yet. Receive Window (RWIN): 11344 Window Scaling: off Path MTU Discovery: OFF RFC1323 Window Scaling: OFF RFC1323 Time Stamping: OFF Selective Acks: OFF TTL: 64 MSS requested: 1418 Max packet sent (MTU): 1458 Max packet recd (MTU): 882 by Pinan edited by JMGullett If you have a hardware firewall and the Tweaks Tester won't run for you, forward these ports: 1. First step communicates on 8086 2. Second step uses 8085 3. Third is icmp:8 to icmp:0 Overall, you need 80, 8086 and 8085 -- icmp is optional. by Pinan edited by JMGullett The need for Time Stamping seems to be in question, at least with RWIN under 65535. If you have a line where latency varies a lot, or a "long fat pipe" (for example, pure satellite connection), then Time Stamping should be beneficial, so experiment with it. Time Stamping defaults to off (No). To set Time Stamping, download DRTCP021.exe. from this page. Set Time Stamping to Yes (or No) using the drop down menu. Tab to "Apply" and click it. Then reboot and retest. Feedback received on this FAQ entry:
by Pinan edited by JMGullett Extensive testing has shown that enabling time stamping when using a DirecPC-based connection does slightly increase download speed (about 5% on average). However, it also causes significant problems with certain websites. In particular, interactive sites and secure sites often will not load completely or will not load at all with time stamping enabled. In addition, enabling time stamping with these systems will cause large email attachments to fail to download. For these reasons, it is recommended that time stamping not be used on DirecPC, Earthlink, AOL+ and Pegasus Express satellite broadband systems. by PetDude edited by JMGullett (Windows) This issue is most often caused by Path MTU Discovery being turned Off, which tends to decrease your upload speeds, sometimes considerably. Download DrTCP021.exe (for Windows OS's only) from this page to your desktop. Open it and set Path MTU Discovery to either "Default" or "Yes" (same thing). Click Save, then reboot and retest. (Mac) This is a false issue on the Mac; the TweakTester deducts 12 bytes (the timestamp segment) from the MTU. The actual MTU is whatever is shown plus 12. Feedback received on this FAQ entry:
by Pinan edited by JMGullett |