- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For the last 4 or 5 days my download speeds have been lower than the u/l speeds.
Here are the results for the verizon speed test:
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done SendBufferSize set to [8192] running 10s outbound test (client to server) . . . . . 721.89Kb/s
running 10s inbound test (server to client) . . . . . . 607.76kb/s
Information: Network Middlebox is modifying MSS variable Server IP addresses are preserved End-to-End Information: Network Address Translation (NAT) box is modifying the Client's IP address Server says [141.152.52.206] but Client says [192.168.1.41]
And the transceiver stats:
Transceiver Revision: | 7.2.3.0 | |
Vendor ID Code: | 4 | |
Line Mode: | G.DMT Mode | |
Data Path: | Interleaved | |
Transceiver Information | Downstream Path | Upstream Path |
DSL Speed (Kbits/Sec) | 3360 | 864 |
Margin (dB) | 18.5 | 15.0 |
Line Attenuation (dB) | 28.5 | 15.5 |
Transmit Power (dBm) | 9.3 | 11.9 |
Extremely frustrating to say the least.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also me. I got my dsl configured at 3360 Kbps download, but it will never go higher than 2.8Mbps
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2.88 is about the max you'll get after factoring in the overhead. I consistently ran at that speed until a few days ago. What is perplexing is it is only affecting the d/l side.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@ralphamolina wrote:Also me. I got my dsl configured at 3360 Kbps download, but it will never go higher than 2.8Mbps
2.8Mbps is correct for the 3Mbps package. Verizon needs to overprovision the lines a bit more to account for overhead. My Frontier DSL line, which syncs at 3712kbps on the downstream, maxes at 3,200kbps (measured) after overhead when it isn't suffering from shoddy network planning out in Rochester, NY that causes congestion. There's roughly a 15% Data Communication overhead due to ATM + PPPoE + TCP/IP which takes the max theoretical speed of 3360kbps and reduces it down to 2900kbps max possible. The overhead only gets worse as you go up in speed, pretty much increases exponentially. It's why 15Mbps lines run 2.6Mbps higher than the rated speed, but why 1Mbps lines run at only 200kbps higher than their rated speed. Also, to the above post, the overhead also affects the upstream as well. 768kbps lines at 864kbps lines really max at about 740kbps, if you can even get that sustained. It's much worse on the upstream especially if you're fragmenting packets because the network runs at an MTU of 1500, and PPPoE allows for a max of 1492 whereas ATM allows for a max of 1530.
@Popster: Are these slow speeds taking place during the evening or night time hours, or do they take place all the time? If it's all the time, please visit http://www.giganews.com/line_info.html and provide to us the traceroutes that are shown on that page to your line.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All the time. Here's the info from giganews:
news.giganews.com
1 gw1-g-vlan201.dca.giganews.com (216.196.98.4) 0 ms 0 ms 0 ms
2 xe-2-3-0.er1.iad10.us.above.net (209.66.64.189) 0 ms 0 ms 0 ms
3 xe-0-0-0.er2.iad10.us.above.net (64.125.26.234) 0 ms 0 ms 0 ms
4 above-uu.iad10.us.above.net (64.125.13.174) 0 ms 0 ms 0 ms
5 0.ae1.RES-BB-RTR2.verizon-gni.net (152.63.32.157) 0 ms 1 ms 1 ms
6 so-6-0-0-0.RIC01-CORE-RTR1.verizon-gni.net (130.81.20.169) 34 ms 161 ms 23 ms
7 P3-0-0.RIC01-DSL-RTR3.verizon-gni.net (130.81.4.26) 7 ms 7 ms 5 ms
8 * * *
9 * * *
10 * * *
Max number of unresponsive hops reached (firewall or filter?)
news-europe.giganews.com
1 vl201.gw2.ams.giganews.com (216.196.110.2) 20 ms 0 ms 0 ms
2 208.174.49.145 (208.174.49.145) 0 ms 0 ms 0 ms
3 cr2-tengig-0-5-1-0.frankfurtft3.savvis.net (204.70.207.209) 8 ms 9 ms 8 ms
4 cr1-bundle-pos1.NewYork.savvis.net (204.70.196.137) 101 ms 102 ms 102 ms
5 er2-tengig-2-1.NewYork.savvis.net (204.70.198.14) 94 ms 94 ms 95 ms
6 0.xe-9-2-0.BR2.NYC4.ALTER.NET (204.255.168.89) 94 ms 94 ms 94 ms
7 0.xe-1-1-1.NY325-BB-RTR2.verizon-gni.net (152.63.1.206) 101 ms 101 ms 94 ms
8 so-6-0-0-0.RIC01-CORE-RTR1.verizon-gni.net (130.81.20.169) 108 ms 100 ms 98 ms
9 P3-0-0.RIC01-DSL-RTR3.verizon-gni.net (130.81.4.26) 100 ms 98 ms 106 ms
10 * * *
11 * * *
12 * * *
Max number of unresponsive hops reached (firewall or filter?)
Thanks for the help.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmm, not seeing much that stands out in those traces. If this is still a problem, I'd take bets that there is an equipment issue somewhere if it is 24/7.