Problem with my download speeds.

[seanb1982]

Hi all, I'm having problems with my download speeds over the last few weeks.
Any help would be great appreciated.

I have dsl2+.

I used to be able to download at 3.5 - 4.5 mps, but lately my d/l speeds are no more than 1.6mps.
But it drops down to 0.2....very up and down, never stays at the same speed for more than 5 seconds.

I checked my speed at speedtest.net and it show speeds of about 3.1mps but there are times when a speed test shows 1.6mps, it's up and down like a yo-yo.

I have a EDIMAX AR-7284wna wireless router modem.
I use my internet 90% of the time on my desktop but I do have a laptop also.
I only use it wireless for my laptop.
But the computers are never used at the same time.

I have also tried my spare modem which does the same.
I have antivirus which does automated scans every single day and I also have malware bytes which both found nothing.

my isp insists there shouldn't be a problem from their end.
I have been with this isp since march and up until the start of this month the speeds have been very consistently excellent.

Any tips or suggestions would be greatly appreciated.

Thanks.

 

[HappyOldGoat]

Not sure if the ISP can check signal strength to the DSL modem but they may not be testing the connection as thoroughly as we need. However, for now assume the signaling is healthy. We may be able to isolate the problem ( a little complex). From the DOS prompt issue the command:

"tracert -n www.google.com" and type Ctrl-c after about 6 entries

You will get an output similar to this:


Tracing route to Google [74.125.113.147]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 192.168.2.1
2 22 ms 23 ms 21 ms 10.32.128.1
3 13 ms 11 ms 10 ms 24.95.84.177
4 13 ms 13 ms 11 ms 65.25.137.197
5 13 ms 10 ms 32 ms 65.189.140.142
6 42 ms 20 ms 23 ms 66.109.6.68
7 25 ms 22 ms 23 ms 107.14.17.147
^C

The first line above has an IP address of 192.168.2.1 which is my local router.
Test this path and all the others with the command:

"ping -n 1000 192.168.2.1"

Then use the same command on the next 5 IP addresses.
You should get NO timeouts.
If one of the addresses give timeouts, identify from the list printed as output from the command:

"tracert www.google.com"

This will give you a name for the IP and the bottleneck in your speed problems.

Post your results and the results of :

"netstat -s"

before and after a download.

Hope this helps!!

 

[manowar]

Just a small edit, but you could just use the -t command, instead of -n 1000, its the same thing, really, as I cannot see anyone sitting there and watching 1000 echo requests!

so ping <IP of your router/gateway/remote server> -t

eg. ping www.google.c0m -t

-t just infinately pings an address.

 

[i3oodlei3ear]

If above doesn't help and everything seems to be fine and dandy...

...Have you read the fine print in your contract? A lot of companies that offer internet, have tons of fine print of what they can regulate. For instance, in October, AT&T started regulating the speed that the old "Unlimited Data Usage" can DL at. So they may DL 3mbs for the first week, then the week after that, AT&T drops it down to 1.5mbs to help regulate the traffic. Comcast also does this. They use to advertise their cable being able to perform faster than any other cable out there (They would show ridiculous MBS). But the catch was, that it was only temporally for the first 30 seconds (or maybe it was a minute) of the download and then the rest was at a regular pace.

 

[seanb82`]

Browsing web pages seems to be fine...it's just downloading that's giving me the issue.
I've only been able to d/l at 10-20kbs.
I tend to think it has something to do with my ISP.
But I have been with my ISP since March and I have downloaded a lot more in the past than I have lately so they shouldn't be slowing me down.

Here's my stats:

C:\Users\Sean Bakhtiar>ping -n 1000 192.168.2.1

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
Control-C
^C
C:\Users\Sean Bakhtiar>netstat -s

IPv4 Statistics

Packets Received = 42009
Received Header Errors = 0
Received Address Errors = 1
Datagrams Forwarded = 0
Unknown Protocols Received = 0
Received Packets Discarded = 270
Received Packets Delivered = 395780
Output Requests = 392884
Routing Discards = 0
Discarded Output Packets = 520
Output Packet No Route = 89
Reassembly Required = 0
Reassembly Successful = 0
Reassembly Failures = 0
Datagrams Successfully Fragmented = 0
Datagrams Failing Fragmentation = 0
Fragments Created = 0

IPv6 Statistics

Packets Received = 18
Received Header Errors = 0
Received Address Errors = 0
Datagrams Forwarded = 0
Unknown Protocols Received = 0
Received Packets Discarded = 7
Received Packets Delivered = 58786
Output Requests = 64800
Routing Discards = 0
Discarded Output Packets = 0
Output Packet No Route = 46
Reassembly Required = 0
Reassembly Successful = 0
Reassembly Failures = 0
Datagrams Successfully Fragmented = 0
Datagrams Failing Fragmentation = 0
Fragments Created = 0

ICMPv4 Statistics

Received Sent
Messages 396 445
Errors 0 0
Destination Unreachable 152 198
Time Exceeded 0 0
Parameter Problems 0 0
Source Quenches 0 0
Redirects 0 0
Echo Replies 244 0
Echos 0 247
Timestamps 0 0
Timestamp Replies 0 0
Address Masks 0 0
Address Mask Replies 0 0
Router Solicitations 0 0
Router Advertisements 0 0

ICMPv6 Statistics

Received Sent
Messages 23 55
Errors 0 0
Destination Unreachable 5 5
Packet Too Big 0 0
Time Exceeded 0 0
Parameter Problems 0 0
Echos 0 0
Echo Replies 0 0
MLD Queries 0 0
MLD Reports 0 0
MLD Dones 0 0
Router Solicitations 0 45
Router Advertisements 18 0
Neighbor Solicitations 0 5
Neighbor Advertisements 0 0
Redirects 0 0
Router Renumberings 0 0

TCP Statistics for IPv4

Active Opens = 37576
Passive Opens = 109
Failed Connection Attempts = 36340
Reset Connections = 78
Current Connections = 11
Segments Received = 321423
Segments Sent = 235061
Segments Retransmitted = 76154

TCP Statistics for IPv6

Active Opens = 60
Passive Opens = 60
Failed Connection Attempts = 0
Reset Connections = 58
Current Connections = 0
Segments Received = 930
Segments Sent = 930
Segments Retransmitted = 0

UDP Statistics for IPv4

Datagrams Received = 62235
No Ports = 220
Receive Errors = 0
Datagrams Sent = 76498

UDP Statistics for IPv6

Datagrams Received = 38828
No Ports = 7
Receive Errors = 0
Datagrams Sent = 58883

 

[HappyOldGoat]

The ping stat are good, but that is a local address. I suspect that pinging an address on the internet like Google may not be so good. The IPV4 stats are not good, nearly 1 of 3 segments sent are being lost in the internet. This is a problem with the ISP. Most likely they are either metering your traffic or have a router that is getting errors. Try downloading from various sources and looking at the stats.

TCP Statistics for IPv4

Active Opens = 37576
Passive Opens = 109
Failed Connection Attempts = 36340
Reset Connections = 78
Current Connections = 11
Segments Received = 321423
Segments Sent = 235061
Segments Retransmitted = 76154

76154/235061 + 100 = 32%

 

[Ethereal_Dragon]

Given the TCP stats listed in the above post, I would suspect the issue to be with "the last mile", or the physical connection from your place of residence to the CO or the DSLAM. It is possible that the issue could be somewhere else in the ISP's network, but that isn't likely.

Scenario 1 (most likely): Errors on the local loop. Errors in this part of the network will cause packets to become corrupted, and will fail CRC (if that is used) or also the checksum will fail. The reason that this is the most likely is that this is a dedicated physical medium from your place of residence to the local CO (Central Office) or DSLAM (DSL Access Multiplexor). At the CO or the DSLAM, it is no longer a dedicated physical medium, it is shared, so any issues there would be experienced by many people in the area. This is possible, but not likely as you said it has been happening for several weeks now.

Scenario 2: Traffic isn't reaching the destination, so there is no ACK sent from the dest back to you, and packets get retransmitted. This is a much less likely scenario, as this would be more common for you to experience this issue to a single dest, not various dest's. Also, MANY people would experience this issue, and it wouldn't persist for weeks.

My suggestion is that you see if there are any diagnostics within the modem showing errors coming into it. Also keep in mind that the ISP's responsibility does NOT go all the way to the modem (generally, unless you have a special service). Their 'end point' or 'Demarcation' (Demarc) point is called a NID (Network Interface Device), and is usually a small gray box on the outside of your home. The cabling from that box to your DSL modem is GENERALLY your responsability. If you want to eliminate your "inside wiring" from the equation, take a long phone cord, and connect your DSL modem DIRECTLY to the NID on the outside of your house. The NID is split into 2 halves. 1 half is locked, and only the local Telco can access it, and the other half should just be secured by a small screw. you will see a phone jack inside of there, just unplug that line, and plug in your DSL modem. If you still have the trouble, then the issue is between the NID and the CO (assuming that the phone cable, and the modem are both ok).

If you want to ensure that the ISP is PROPERLY testing the line, call them up to report trouble again, and while they are 'testing', unplug your phone cable from the DSL modem. If they still tell you everything is fine, then they are either not looking at something properly, or testing the wrong line. At this point I would demand that they dispatch out a tech to come and meter your cable pairs from the NID to see if they see errors on the local loop.

Also, since this is DSL, do you have a voiceline on the same physical line? Does that have any issues, static, disconnects, anything? This would further point to the issue being with the last mile.