|
| |||||
| Home | Reviews | Tools | Forums | FAQs | Find Service | ISP News | Maps | About |
how-to block ads |
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 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.
The local network segment to which your PC is connected has a high level of Internet Protocol (IP) errors. IP is the "language" used by many computers to communicate with one another. If the problem persists, notify your system administrator about the problem.If the problem persists, notify your system administrator about the problem. by edited by JMGullett The Line Quality test needs you to be pingable as well. Once testing is completed, simply make yourself non-pingable again. by Pinan 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. excellent site. have been using for years, both at home and when configuring others set ups 2011-06-18 17:30:56 Thank you. Good information I will try to use. 2010-11-13 16:12:13 Thanks very much for your service. 2011-08-20 12:22:22 Pretty cool! Thanks for the test. 2010-07-20 15:29:45 Great test thanks 2012-02-06 13:59:50 thank you! I am not pc literate but this was quite simple to identify any problems :) 2011-06-02 15:52:24 Test works great..used the recomendations and Improved speed and Quality..thx very helpful, Thank You. 2011-09-01 14:42:32 by Pinan • 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.
I CAN SEE THE JAVA ICON BUT WHEN I CLICK ON IT NOTHING HAPPENS,IT HAS ALWAYS WORKED BEFORE by edited by JMGullett 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 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 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.
Using DrTCP I have tried many times to switch Timestamping ON. However the TWEAK TEST always shows it at OFF?
I also tried a tip from another person :
To turn Timestamping On/Off
At Run type :
FSUTIL behavior set disablelastaccess 1 = OFF
FSUTIL behavior set disablelastaccess 0 = ON
Acording to Tweak Test this doesn't work either?
What can I do?
Thanks Jokin39
by Pinan
by PetDude 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.
Ditto: I did the suggestion and it still gives me the upload MTU warning. Does any avail FAQ offer a suggestion if DR TCP does not change result? What about Ubuntu Linux? 2007-11-08 19:01:38 The note for Mac is also true for Linux and FreeBSD. Perhaps the test can determine the host OS (from the HTTP headers?) and automatically add 12, so as not to report an erroneous value? In addition to the suggestion of checking the HTTP Headers, you can also do the "Add 12" if the user STATES that they are a Mac (or Linux). You have been provided with the platform in the query - Why not use it as you do with the provisioned speed? I did the suggestion and it still gives me the upload MTU warning. 2008-04-24 18:42:11 Reply to other feedback: The TCP stack in Ubuntu Linux closer resembles the Mac than it does Windows. It can be set to parameters, but it is an autotuning stack. It is also UNiX based, like the Mac. I would assume that could be the issue and it's safe to ignore the warning, as long as data stream is good. My upload/download comes close to my ISP's claimed max, which generally does require a properly tuned stack in this area on Roadrunner. Seems I was wrong as to why, but my advice was good. Linux(including Ubuntu)/UNiX/BSD/Mac OS X do all use timestamps, which I briefly forgot about. They can be turned off via your sysctl.conf file, but I wouldn't recommend it. Consider yourself ok. slackware 12.1 linux, raspppoe, mtu 1492 for ppp0
Tester show 1480 issue same as Mac... 2008-08-05 18:36:41 I use Mac Leopard 10.5.5 and MacPilot (<-program) in place of DrTCP. Under the 'network' heading you can change all your set up configurations to speed both your network connections and your computer. It doubled my connection speeds for both upload and download and reduced my latency (ping time) from and average of 67ms to average of 47ms = big performance boost when watching videos or large pics on the internet. The comment about Mac also applies to Linux. 2009-01-31 22:02:28 In addition to my earlier comment about looking at the HTTP header (to see what platform the browser claims) and the user's response in the OS selection query box, Section 1 (Your Tweakable Settings) says "RFC1323 Time Stamping: ON" so the system KNOWS that there is a 12 byte timestamp segment but does not allow for it when reporting the MTU. BAD DESIGN in my opinion. did not fix this problem 2009-08-31 22:43:45 For Windows 7 you can tweek MTU by opening cmd as Administrator. Then using following commands,
Netsh
interface ipv4
set subinterface "local Area Connection" MTU=1500 store=persistant
you can test the setting by typing show interface.
hope thats helpful, tho it did not change the error reported by dslreports but it is now most certainly set to 1500. and i have noticed a difference in page loads. What does this error mean for Vista and Windows 7? Don't think this can be tweaked but getting this warning/FAQ on my upload results. Same as the user Dsaunder.
Ditto: I did the suggestion and it still gives me the upload MTU warning. Does any avail FAQ offer a suggestion if DR TCP does not change result? 2011-09-28 03:02:01 by Pinan | ||||||||||||
| Thursday, 24-May 13:40:33 | Terms of Use & Privacy | feedback | contact | Hosting by nac.net - DSL,Hosting & Co-lo over 12.5 years online © 1999-2012 dslreports.com. |