dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
1187

AndrewRichmn
@96.49.9.x

AndrewRichmn

Anon

[BC] Unbelievable slow Internet every evening

Hi, I'm Andrew from Richmond, BC, Canada.
Every single evening I experience the same problem: Internet speed drops to 1-2 Mbit instead of payed 50 Mbit. Numerous calls to tech support have not resolved the problem.
Below info is when my MacBook Air is connected through a cable, not wifi.
Here is my traceroute:
andrews-air:~ andrewrebrovskiy$ traceroute google.ca
traceroute to google.ca (173.194.33.175), 64 hops max, 52 byte packets
1 router.asus.com (192.168.212.1) 1.959 ms 2.555 ms 1.947 ms
2 * * *
3 rd3bb-tge0-4-0-6-1.vc.shawcable.net (64.59.147.145) 179.246 ms 241.508 ms 224.452 ms
4 rc2bb-tge0-14-0-12.vc.shawcable.net (66.163.68.133) 244.360 ms
rc2bb-tge0-5-0-4.vc.shawcable.net (66.163.68.209) 221.004 ms
rc2bb-tge0-13-0-6.vc.shawcable.net (66.163.69.137) 183.766 ms
5 rc5wt-tge0-2-0-15.wa.shawcable.net (66.163.78.226) 279.939 ms 257.304 ms 287.759 ms
6 72.14.195.250 (72.14.195.250) 255.243 ms 337.463 ms 308.320 ms
7 66.249.94.214 (66.249.94.214) 28.908 ms 28.498 ms 21.112 ms
8 209.85.244.65 (209.85.244.65) 19.652 ms 23.746 ms 41.446 ms
9 sea09s18-in-f15.1e100.net (173.194.33.175) 30.701 ms 18.308 ms 18.576 ms
Here is my ping to the third hop (the first one is my router, the second does not respond to ping):
PING 64.59.147.145 (64.59.147.145): 56 data bytes
64 bytes from 64.59.147.145: icmp_seq=0 ttl=253 time=36.337 ms
64 bytes from 64.59.147.145: icmp_seq=1 ttl=253 time=31.792 ms
64 bytes from 64.59.147.145: icmp_seq=2 ttl=253 time=37.755 ms
64 bytes from 64.59.147.145: icmp_seq=3 ttl=253 time=37.604 ms
Request timeout for icmp_seq 4
64 bytes from 64.59.147.145: icmp_seq=4 ttl=253 time=1384.281 ms
64 bytes from 64.59.147.145: icmp_seq=5 ttl=253 time=383.484 ms
64 bytes from 64.59.147.145: icmp_seq=6 ttl=253 time=291.525 ms
64 bytes from 64.59.147.145: icmp_seq=7 ttl=253 time=259.860 ms
64 bytes from 64.59.147.145: icmp_seq=8 ttl=253 time=307.401 ms
64 bytes from 64.59.147.145: icmp_seq=9 ttl=253 time=278.529 ms
64 bytes from 64.59.147.145: icmp_seq=10 ttl=253 time=316.201 ms
64 bytes from 64.59.147.145: icmp_seq=11 ttl=253 time=19.860 ms
64 bytes from 64.59.147.145: icmp_seq=12 ttl=253 time=46.987 ms
64 bytes from 64.59.147.145: icmp_seq=13 ttl=253 time=57.988 ms
64 bytes from 64.59.147.145: icmp_seq=14 ttl=253 time=46.655 ms
64 bytes from 64.59.147.145: icmp_seq=15 ttl=253 time=45.583 ms
64 bytes from 64.59.147.145: icmp_seq=16 ttl=253 time=286.237 ms
64 bytes from 64.59.147.145: icmp_seq=17 ttl=253 time=457.364 ms
===
I believe, the picture is pretty much obvious; so my question is should I be waiting and hoping Shaw will resolve the issue with overloaded line withing reasonable time OR should I switch to Telus right away?

Thanks!
Andrew
zod5000
join:2003-10-21
Victoria, BC

zod5000

Member

Honest opinion. Any time someone says it slows down in the evening (ie peak times) the first thing that pops up in my mind is your on an overcrowded node. It's not really something Shaw will fix on a Whimsy. I do believe if a an area is congested they will eventually split the node (ie make an extra node so each has half the demand), but the speed at which they do it can be weeks to months or longer.

If it's that bad and Shaw tech support can't fix it, try out Telus for a while.
ilianame
join:2002-06-05
Burnaby, BC

ilianame to AndrewRichmn

Member

to AndrewRichmn
It has been considered "normalcy" for when dealing with Shaw ever since Rogers @Home appeared to have your plan tailored to the lowest physical speed in peak-hours that your area is capable of:

If you are getting slowed down that much you should have the lowest plan, as Shaw is never pro-active in prorating their charges, and getting a refund on your own request is usually met with the standard troubleshooting hops before you are taken seriously.

But, on the flip side, Shaw has never charged for the extra speed customers may be getting in areas of no congestion (they have since changed their plans and provisioning related to speedboost).

I used to get a sustained 32mbps on a 25mbps plan in a light residential area where the coaxial has just been replaced (from the 70's thin-style), while I could hardly get over 10mbps on a 25mbps plan in a large high-rise.
analog andy
join:2005-01-03
Surrey, BC

analog andy to AndrewRichmn

Member

to AndrewRichmn
LOl for the last 1-2 weeks in Surrey I've noticed around 12-1am I start getting huge ping spikes and intermittent total loss. During the day was fine until today where its just plan sad.

I get this with speed tests Oops, something is wrong. Your test results are lower than expected. Please consult our help section for troubleshooting.

Estimated on hold wait 1hr.

For what I'm paying I can't wait till my ADSL is provisioned and then second cable connection for Lightspeed or Tek.

ping google.ca
PING google.ca (173.194.33.88) 56(84) bytes of data.
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=1 ttl=55 time=1042 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=2 ttl=56 time=1185 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=3 ttl=56 time=1372 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=4 ttl=55 time=1359 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=5 ttl=55 time=1217 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=6 ttl=56 time=1006 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=7 ttl=55 time=854 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=8 ttl=55 time=1280 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=9 ttl=56 time=1427 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=10 ttl=55 time=1362 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=11 ttl=55 time=1315 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=12 ttl=56 time=1180 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=13 ttl=56 time=896 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=14 ttl=55 time=1281 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=15 ttl=56 time=1447 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=16 ttl=56 time=1353 ms
64 bytes from sea09s15-in-f24.1e100.net (173.194.33.88): icmp_seq=17 ttl=56 time=1187 ms

ping na.killer.xxx
PING na.killer.xxx (192.99.36.127) 56(84) bytes of data.
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=1 ttl=54 time=1395 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=2 ttl=54 time=1224 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=3 ttl=54 time=528 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=4 ttl=54 time=1269 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=5 ttl=54 time=1373 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=6 ttl=54 time=1408 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=7 ttl=54 time=1380 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=8 ttl=54 time=1301 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=9 ttl=54 time=1244 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=10 ttl=54 time=1349 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=11 ttl=54 time=1475 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=12 ttl=54 time=1438 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=13 ttl=54 time=1420 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=14 ttl=54 time=1241 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=15 ttl=54 time=1263 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=16 ttl=54 time=1491 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=17 ttl=54 time=1516 ms
64 bytes from na.killer.xxx (192.99.36.127): icmp_seq=18 ttl=54 time=1439 ms

capdjq
Be Kind, Be Calm & Be Safe
Premium Member
join:2000-11-01
Vancouver

capdjq to AndrewRichmn

Premium Member

to AndrewRichmn
I live in Richmond. Haven't noticed any problems. Do you live in apartment?

Batman
@24.244.23.x

Batman

Anon

Hey Andrew. There is an open ticket for saturation on your node. There is no ETR, but the good news is engineering are aware of the problem and are working to resolve the issue.