dslreports logo


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 See Profile edited by JMGullett See Profile
last modified: 2007-02-27 10:30:30


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:
  • 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.

    2012-01-08 14:18:16 (turkman143 See Profile)

edited by JMGullett See Profile
last modified: 2007-02-23 16:43:58

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 See Profile edited by JMGullett See Profile
last modified: 2007-02-23 16:45:03

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:
  • Gracias. la velocidad es buena y gracias por la ayuda que brindan, muy útil

    2014-10-19 18:37:52

  • Great test thanks

    2012-02-06 13:59:50

  • very helpful, Thank You.

    2011-09-01 14:42:32

  • Thanks very much for your service.

    2011-08-20 12:22:22

  • Test works great..used the recomendations and Improved speed and Quality..thx

    2011-07-27 02:57:19 (SlowFreddy See Profile)

  • excellent site. have been using for years, both at home and when configuring others set ups

    2011-06-18 17:30:56

  • thank you! I am not pc literate but this was quite simple to identify any problems :)

    2011-06-02 15:52:24

  • Thank you. Good information I will try to use.

    2010-11-13 16:12:13

  • pretty good :)

    2010-09-09 22:02:47 (vinicius See Profile)

  • Pretty cool! Thanks for the test.

    2010-07-20 15:29:45

by Pinan See Profile edited by JMGullett See Profile
last modified: 2007-02-23 16:46:07

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:
  • I CAN SEE THE JAVA ICON BUT WHEN I CLICK ON IT NOTHING HAPPENS,IT HAS ALWAYS WORKED BEFORE

    2007-12-08 22:14:05 (antoinefinch See Profile)

edited by JMGullett See Profile
last modified: 2007-02-23 16:48:34

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 See Profile edited by JMGullett See Profile
last modified: 2007-02-23 16:49:04

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 See Profile edited by JMGullett See Profile
last modified: 2007-02-23 16:50:01

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:
  • 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

    2008-12-31 20:36:04 (jokin39 See Profile)

by Pinan See Profile edited by JMGullett See Profile
last modified: 2007-02-23 16:51:34

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 See Profile edited by JMGullett See Profile
last modified: 2007-02-23 16:59:08

(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:
  • I turned Path MTU Discovery on as suggested yet still get the indication that the upload packet is bigger than your MTU. Any other suggestions. Normal DSL connection on Win98SE.

    2012-06-19 18:33:50 (MikeM01 See Profile)

  • You will get this if you are on Vista/7 and you have the nagle algorithm turned off (NoTCPDelay on) .

    2012-06-04 11:43:00 (darkwish See Profile)

  • This did not fix my problem. PPPoE & DSL Router with WinXP.

    2012-06-03 16:30:21 (OriginalDrM See Profile)

  • 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

  • Suggestion did not fix MTU warning for me.

    2011-02-24 18:34:02 (steffey0 See Profile)

  • 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.

    2011-02-20 18:15:47 (klickinc See Profile)

  • 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.

    2011-01-25 19:29:42 (drshock See Profile)

  • did not fix this problem

    2009-08-31 22:43:45

  • 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.

    2009-02-11 13:04:15 (RARPSL See Profile)

  • The comment about Mac also applies to Linux.

    2009-01-31 22:02:28

  • 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.

    2008-09-29 15:03:32 (Mosley See Profile)

  • 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?

    2008-08-26 12:34:53 (dsaunder See Profile)

  • slackware 12.1 linux, raspppoe, mtu 1492 for ppp0 Tester show 1480 issue same as Mac...

    2008-08-05 18:36:41

  • 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.

    2008-05-01 11:36:42 (Selenia See Profile)

  • 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.

    2008-05-01 11:33:11 (Selenia See Profile)

  • I did the suggestion and it still gives me the upload MTU warning.

    2008-04-24 18:42:11

  • 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?

    2008-01-13 03:11:01 (RARPSL See Profile)

  • 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?

    2008-01-04 14:43:16 (pflog See Profile)

  • What about Ubuntu Linux?

    2007-11-08 19:01:38

by Pinan See Profile edited by JMGullett See Profile
last modified: 2007-02-23 17:00:41