What happens to my Bandwidth?

Hi everyone. I have a TP-Link TD-W8970 V1 and OpenWRT 19.07.2. I using a dsl PPPoE connection for WAN and Internet access.
The Package I bought from my ISP comes with 16 Mbps bandwidth.
But I have a problem in last afew days. My internet connection becomes too slow! maybe 50 or 60 Kbps! I call them several times and they just tell me everything fine and they can't detect my problem. They just tell me maybe problem caused by my modem and recommend me to upgrade the firmware or buy a new one! I also check the telephone line and I see no problem. This is my DSL Status and a I expected, my current bandwidth set to 18Mb/s

Line State:UP [0x0]
Line Mode:G.992.5 (ADSL2+)
Line Uptime:4h 18m 16s
Data Rate:18.384 Mb/s / 2.400 Mb/s
Max. Attainable Data Rate (ATTNDR):21.480 Mb/s / 2.783 Mb/s

The Data Rate Parameter seems OK. Help me to find the problem.

Which speed do you get when the download is run on the router itself?

time wget -O /dev/null https://...
1 Like

This command do not show the speed to me. Just showing the time and size of the package.

You can calculate it from the output with this formula:
(speed in bit/s) = 8 * (size in bytes) / (time in seconds)

In addition, please post the whole DSL status:

/etc/init.d/dsl_control status

OK. Here is the results,

My DSL Status:

ATU-C Vendor ID:                          Broadcom 147.158
ATU-C System Vendor ID:                   00,00,30,30,30,30,00,00
Chipset:                                  Lantiq-VRX200
Firmware Version:               
API Version:                    
XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4, 0x0
Annex:                                    M
Line Mode:                                G.992.5 (ADSL2+)
Line State:                               UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS):  Near: 0 / Far: 0
Errored seconds (ES):                     Near: 443 / Far: 159
Severely Errored Seconds (SES):           Near: 25 / Far: 26
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
Unavailable Seconds (UAS):                Near: 72 / Far: 72
Header Error Code Errors (HEC):           Near: 473 / Far: 85219
Non Pre-emtive CRC errors (CRC_P):        Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
Power Management Mode:                    L0 - Synchronized
Latency [Interleave Delay]:               0.25 ms [Fast]   0.25 ms [Fast]
Data Rate:                                Down: 18.384 Mb/s / Up: 2.400 Mb/s
Line Attenuation (LATN):                  Down: 16.0 dB / Up: 8.2 dB
Signal Attenuation (SATN):                Down: 13.9 dB / Up: 7.7 dB
Noise Margin (SNR):                       Down: 10.2 dB / Up: 13.2 dB
Aggregate Transmit Power (ACTATP):        Down: 16.8 dB / Up: 12.8 dB
Max. Attainable Data Rate (ATTNDR):       Down: 21.076 Mb/s / Up: 2.855 Mb/s
Line Uptime Seconds:                      25443
Line Uptime:                              7h 4m 3s

And also speed of downloading a file by router. I try to get a ~60 MB File from a stable hosting and as you can see:

/dev/null              1% |                               |   607k  1:04:34 ETA

about 1 hour for a 60 MB file!

Still only 124 kbit/s. This experiment was meant to reveal a potential problem on the LAN side, but I would say there is not enough evidence.

Sorry for some basic questions:

  • Does your ISP contract come with a data cap?
  • Did you try downloading from multiple servers and found all of them being slow?

Looks mostly good to me, but I am not a DSL expert.

I wonder about this one:

Does the number of far end HEC errors (85219) increase over time? If so, how fast?

1 Like

Yes, but I don't think this happens because of that. sometimes I have no problem and some times it happens.

Yes, all hosts and servers become slow. except ping! it's still good and same as normal!

After about 2 hours of previous measurements, it remains constant (still 85219).

Seems to be OK.

Please make sure you are not affected by bandwidth throttling because the data cap has been exceeded.
In case of doubt, ask your ISP.

Next, run mtr or traceroute while also creating some network load. This might reveal the location of the bottleneck with a sudden increase of the round-trip time or packet loss.

1 Like