Add ny-monitor.dslreports.com - This is our New York server. This takes care of the Security Scan, the Tweaks Test Applet and the East Coast Line Quality Test server.
Add sfo-monitor.dslreports.com - This is our San Francisco server.
Add sjc-monitor.dslreports.com - This is our San Jose server.
You should add those three domains to a "friendly" (local) zone with a lower protection rating. Zone Alarm users click here for instructions.
Zone Alarm Pro users: To become pingable, click Security > Customize (Internet side) > check off "Allow incoming ping (ICMP echo)." Click Apply then Ok. This will allow your machine to be totally pingable.
When you use tool points to pay for a priority line quality test, your test is recorded as priority -- meaning, you're next in line when the queue processor picks a test to do. You just have to wait a few minutes for the test that's currently underway to be completed. During that time, it will look as if you've been placed at the end of the queue. You really will be queue-jumping, but not until whatever is being processed at that moment is completed.
You need to be pingable since the test results can show accurate latency (ping time) for your connection. Your firewall or router prevents pings from being responded to, if properly set. If you're not pingable, the test will show a 100% loss at your address for both coasts.
If you're using a router, set it to allow pings. If you're using a firewall, the quickest way to become pingable is to tone down on the security level or just turn it off for the duration of the test. Some firewalls have an option to add IPs into a local or trusted zone that will give this IP more access than the general pool. These are the IP addresses that do the Monitor / Line Quality work.
Reason to be pingable: This allows you to see if there are congestion problems, bottlenecks, bad routers and/or if something is wrong at your location. If you're not pingable, the only thing the test is useful for is a fancy traceroute.
This is often a sign of an unpingable router. Your packets are being routed correctly to and from the router, but we cannot ping it. The network engineers probably made the router itself unpingable. Some ISPs and backbones make their routers unpingable to minimize "wasted" bandwidth.
You're using a Qwest/MSN-provided Alcatel CPE. There is nothing you can do about it.
OR
There is an issue with your current network configuration.
Go back to the Desktop, right click on "Network Neighborhood" - "Properties." The Network Configuration window should pop up. In the white box, check for any duplicate TCP/IP or any duplicate hardware adapters. Leave only one and delete any extras. Reboot. You should run another Line Quality test to see if the problem persists. It shouldn't, but it's always good to check.
Another thing for Windows users to do is to have your NIC (ethernet card) installation disk handy, load into Windows Safe Mode, delete all the hardware adapters and start from scratch.
If you do not know how to enter into safe mode and make changes, just start a new topic asking for assistance in our Microsoft Help Forum.
1. Host LOSS - This indicates the percentage of packets dropped by that particular router.
2. Best - Lowest ping to the router Avg. - Average ping to the router Worst - Highest ping to the router
The lower the ping, the better.
3. Gateway - The second to the last hop is your gateway. The gateway is a node on a network that serves as a entrance for local users onto the ISPs network.
4. (YOUR ADDRESS) - This is your computer. A dropped packet (shows as 2% dropped) loss is very common with an ICMP stream.
It's possible that there is something wrong with your setup. Here are a few things that you can do to possibly fix the problem:
- Make sure that your modem is at least 12 inches (roughly 30 centimeters) clear of anything that emits electromagnetic interference (such as a CRT monitor). Make sure that all cables are not physically damaged and are properly connected. Halogen lighting and light dimmers in proximity to the computer can also cause a problem.
- Ensure that your ethernet card is seated properly and that your drivers are up to date.
- Reset your modem. Unplug it for about a minute or two, then plug it back in and let it regain sync.
If none of the above correct the issue, it would be in your best interest to contact your ISP and have them do an inspection of the line itself.
If you see a "Host Precedence Violation" on your Line Quality test results page accompanied by a really high reported gateway ping, don't panic!
Here's the technical definition for a Host Precedence Violation (under RFC-1812): "Sent by the first hop router to a host to indicate that a requested precedence is not permitted for the particular combination of source/destination host or network, upper layer protocol and source/destination port."
Keep in mind, this is just a reference; there is a much-easier-to-digest explanation.
Let's go back to your Test History page. Find a Line Quality test then open it. Go down and look at the "your first hop ping" row. Check your gateway's IP. Most likely, it is between 10.0.0.0 & 10.255.255.255, 172.16.0.0 & 172.31.255.255 or 192.168.0.0 & 192.168.255.255, correct?
Those three domain ranges are in something dubbed the "Private IP Network" domains. With the way the Internet works, your ISP has set up an "exclusive LAN." Your ISP has your gateway set up so that it is dedicated to only Internet traffic coming from you and going to you. The DSLreports servers are not recognized within your ISP's network, so your gateway doesn't respond to any packets being sent directly to it. Your first hop ping is then estimated. Nearly all of the time, it shows up as way higher than it really is.
Do you want to know what your first hop ping really is?
With your Windows PC, go to "Start" - "Run" - then type "ping -t Your Gateway's IP here."
With your Mac OS X PC, open Terminal and type "ping IP here." or Open the Network Utility and fill in the text box. With your Linux PC, go to a shell, then type "ping Your Gateway's IP here."
Since the gateway recognizes you as a part of your ISP's "happy family," it will correctly respond to a ping and return accurate results.
The router watch list is formed by sweeping the individual line quality tests done over the last three weeks so we can compile a list of Internet routers that were discovered to be the source of packet loss. The only way to be added is to be a bad router.
If you really want to be added, we recommend beating your main switch with a herring.*
*Please be nice to routing equipment and the herring.
If you are also seeing packet loss from these points all the way to the final hop of your test, that points to a problem on the device first showing packet loss or on the inbound connection to that device.
However, if you are not seeing packet loss all the way to the final hop, this apparent packet loss may not be an issue.
Some providers are rate-limiting how often they respond with the TTL-exceeded ICMP packets used by traceroute and similar tools like the Packet Loss Test. This is done to prevent attacks against these routers, since responding to these packets requires much more CPU time than simply forwarding the packet does. If the router is set up to rate-limit, it will respond to a certain number of traceroute packets per second, and once that many have been received, it will stop responding to them for that second -- which will appear as packet loss. You are not losing any "real" traffic, assuming the final hop of your traceroute isn't showing any loss.
Please verify that you have flash browser plugin version 8 or above. You probably have version 7 or below. The link to verify this is right above the flash test!
First, ensure that ZONE ALARM and any other PC browser security products are not blocking the operation of the test. Disable them temporarily and if the test functions correctly then you have found the culprit.
Are you using FIREFOX with a PLUGIN enabled? We are noticing a small percentage of users, all running Firefox, are not able to fully utilize the test. We believe this is because they all have the same Firefox plugin enabled. If you find out WHAT plugin breaks the flash test, please let us know.
Note: We are receiving some reports that the FasterFox addon is inhibiting the flash test. If this is true for you, please contact a site moderator to add your report. Stay tuned.
Our current version is, unfortunately, CPU intensive. We are working to fix this. It is probably that the flash test is utilizing ALL your CPU during the animation phase, and this is depressing the results.
We expect to release a test that will work for slower CPUs very soon.
Possible reason #2
Some fixed wireless ISPs are getting artificially low results for UPLOAD SPEED under flash. This pattern is not just our flash test -- all flash tests show the problem, and some other technology online speed tests show it as well. Our Java test, and a basic ftp test, do not show this problem. We don't yet have an idea why this may be, but we are collecting data.
Possible reason #3
The flash plugin is not efficient enough to test VERY HIGH SPEED connections (fiber). If you are on fiber, you are advised to stick to the Java plugin-based speed test, which can test 100mbit and beyond. Flash is unable to fully utilize a 100mbit connection, so it under reports very fast connections.
The graph is upload and download data from other users, by default, on the same domain as you. You can change this to display results based on other selection information. The X axis is speed. The Y axis is the number of samples around that speed. Grey is for download speed. Blue is for upload speed. Your current and past results are marked by green and red chevrons. Common products for the domain should show as peaks. For instance, 3mbit and 6mbit may be two common products and may show two peaks on the download section of the graph.
The maximum speed the flash test will correctly report varies according to your PC performance. Flash is not as efficient as Java for very high speed connections, so if your connection speed is going to be above 20mbit, then you should also try the Java-based speed tester to verify that you are fully exercising your connection during the test. We have had reports from users on 100mbit connections and moderately powerful PCs that they cannot get more than 25 mbit reported by flash (any flash-based speed test, not just ours), but they can get 80 or 90 mbit reported by the Java test.
This downloadable Windows-based program "pings" various routers on the Internet, external to dslreports.com, to get a fairly accurate reading of your average "ping" time. The lower the value (response time in milliseconds), the quicker your packets reach their destination.
No. Dr. Ping does not store or send your private information or usage habits to DSLreports. The only thing it does store is your best result for display on a page basically for bragging rights (that is, if you make it) and to display which customers on which ISPs are getting low pings.
Dr. Ping's list of routers are old and could be updated. Some ISPs / backbones could have changed the DNS or IPs, made themselves unpingable or, in some cases, done a bellyup.com and are no longer available.
The good thing is Dr. Ping's results will put you in the general ballpark of your average latency.
Doctorping.exe is just a program -- no installer was necessary. You can remove it by simply deleting the file. If your Windows PC tells you the "file is busy" or you get some other error message, then quit the program first, or reboot if you are unsure how to find and quit programs.
Then, just delete the file. (Use Start .. Search .. doctorping.exe on your entire C: or whatever drive, if you have lost where you placed the program.) Last, select the icon using the RIGHT button and find DELETE on the menu that pops up.
However, if you have an existing diary, you can continue to maintain it. If your diary is public, the diary can be accessed from the member’s "user profile page." Click on the link next to "Connection Diary."
If the connection diary is private, the "user profile page" will not have the link. To access the diary, you need to use this link: /dsl_diary/
This page will include info from your member profile page. If any of this info is incorrect, you can click on "use preferences to modify this" under your location. Note that the default setting for a completely private diary is "YES." If you want your diary to be public with the option of keeping certain entries private, click on "to tell people what you’re up to." Otherwise, just click on "New Entry," "New Event" or "click here to create one."
If you decide to go public, the Current (Public) Attitude page will load. You must check the box next to "Has one or more public entries" to change your default private setting to public. Your membership profile will now show that you are "Keeping a Connection Diary."
After you click on "Update," you will return to the previous page, and you can start posting entries.
Open the diary, then click on "update your plan." The diary template page will load. You must check the box next to "Has one or more public entries" to change your default private setting to public. Your membership profile will now show that you are keeping a Connection Diary.
You can also choose which diary entries are public or private. Once it's submitted, under the "Public" column you'll see a check if it's a public entry. If it's private, you'll see a dot. If you want to change it, just click on the check or the dot to switch it.
The Control Panel for this tool is here: »/metashare
Click on "describe my network."
Click the "Add new" pull down menu to add all of your devices. Use the button after you have selected a device to update the screen. When you are satisfied, publish the network description by checking the "Public?" box. Click the Go button again so you can fill out the network title and the description.
Click on "My Network" (Note: if you click on the "Describe My Network" button again, you will create another network description!).
Click on edit.
Follow the same instructions above to add items or edit existing entries. After you modify the contents of the network boxes, click on the edit button in the box, which updates the info. When you are ready, click the display button at the top to verify your changes.
No. It is impossible for this Java-based speed test to overestimate speed. It can, however, underestimate due to prevailing "Internet weather" between you and the test site (which is why, if you are most interested in your last mile speed, finding a nearby test site is important), but it can never overestimate.
If you try a few different test servers, including some of the third-party ones that also use our Java test applet, then the highest speed reported is closest to your last mile speed.
Don't forget that protocol overhead will mean that you never reach the actual speed advertised by your ISP. In some cases, especially PPPoE connections, you can lose almost 15% of advertised speed in protocol overhead.
The fact is, 90% of the speed tests out there are junk. They provide results that are not reproduceable from run to run. There is at least one speed test (visualware) that offers ISPs a server-side program that claims to eliminate all speed test error. If your ISP is prepared to locate a speed test server inside its network, then it will give you the most accurate measure for last mile speed -- but is that the speed you are most interested in? Or are you more interested in testing whether your ISP is well connected to the Net and can give you full speed to many high performance download servers?
Either way, we have a large selection of Java-based speed tests located both in ISPs and elsewhere on our speed test list. If your ISP is one of those, then you will probably be able to test last mile speed the best by using their local test server. If you are interested in real world test results, then pick another well-connected server. It is your choice.
For the purposes of presenting speed test results, we adopt the data communications convention of k = 1000, not k = 1024. For example, 28.8k modems ran at 28800 bits per second, and 56k modems ran at 56000 bits per second.
The transfer rate expressed as kilobytes per second is based on 1024 as per data storage conventions.
This program was created to make life easier for everyone who desires to "tweak" various TCP/IP network settings that affect downstream performance. Dr. TCP is a short-cut into the registries of Windows-based PCs. It makes the task of tweaking various keys take only a moment instead of a few minutes.
Dr. TCP is a program, not the "one stop" patch that is found on other sites. You have complete control of what values are changed. The program does not change any settings on its own.
If you need assistance, please post in our Tweaks Forum.
For any question you have about the tweaking process, check out the Tweaks FAQ.
If your answer is not the Tweaks FAQ, before you post for help in the Tweaks Forum, read everything in the Tweaks Forum header (the text above the posts) to make the process easier for everyone.
The objective of the Port Scan is to see how secure your PC is from people who want to break into your machine. DSLreport's port scan originates from "monitor.dslreports.com" as stated on the port scan page. What it does is send various packets that look for open TCP and UDP ports. It will let you know if you have open, closed or filtered port(s).
Stop by the Security Forum if you fail on information on a firewall. (A firewall is a must have for broadband connected machines.)