|
to ruiner3
Re: Telus Peering.They have enough money already and more then capable hardware possibly. Maybe one of us should start a petition or something . |
|
|
Mike_C join:2007-07-19 Vancouver, BC |
Mike_C
Member
2012-Dec-15 7:34 pm
said by jtl999:They have enough money already and more then capable hardware possibly. Maybe one of us should start a petition or something . A petition would be a waste of time. The percentage of people that are worried about pings and routing is tiny for any ISP. The vast majority only care if their internet works and as a result, the needs of the many are going to far outweigh the needs of the extreme few in any business decisions whether it's an ISP or any other business. |
|
pfak Premium Member join:2002-12-29 Vancouver, BC |
to WhosTheBosch
Both Shaw and TELUS are kind of sad. gw:/root # traceroute -i eth2 50.22.184.114
Note: the -i and -I options were exchangedfor compability with LBL traceroute
Use -I for ICMP, and -i <ifname> to specify the interface name
traceroute to 50.22.184.114 (50.22.184.114), 30 hops max, 40 byte packets using UDP
1 64-46-15-1.quebec-gw.novuscom.net (64.46.15.1) 0.302 ms 0.334 ms 0.387 ms
2 216-19-176-125.stc.novuscom.net (216.19.176.125) 0.390 ms 0.481 ms 0.399 ms
3 72.51.24.189 (72.51.24.189) 0.657 ms 0.506 ms 0.395 ms
4 10ge-xe-0-1-0.van-spenc-dis-1.peer1.net (216.187.115.130) 0.658 ms 0.485 ms 0.402 ms
5 10ge.xe-1-0-0.sea-wes7-dis-1.peer1.net (216.187.88.30) 4.874 ms 4.999 ms 4.867 ms
6 te1-5.bbr01.wb01.sea01.networklayer.com (206.81.80.140) 5.001 ms 4.852 ms 5.002 ms
7 ae0.dar02.sr01.sea01.networklayer.com (173.192.18.159) 6.600 ms ae0.dar01.sr01.sea01.networklayer.com (173.192.18.199) 23.865 ms ae0.dar02.sr01.sea01.networklayer.com (173.192.18.159) 5.470 ms
8 po2.fcr02.sr03.sea01.networklayer.com (67.228.118.227) 5.490 ms 5.393 ms po1.fcr02.sr03.sea01.networklayer.com (67.228.118.225) 5.385 ms
9 * * *
|
|
Ikarasu join:2004-01-09 Port Coquitlam, BC |
Anyone have a Teksavvy or other wholesaler able to post pings?
I'm interested in the comparisson. I know when I was with Teksavvy before, they had way better pings - Now theyre way larger, but IIRC, they had peering agreements with all the major providers.
You'd think the Major ISPS would offer a higher quality of service... Shaw was always better than Telus for me, but even shaw seemed kind of slow. Then again... Idont do much FPS, I was basing it on when I used to play world of warcraft ping >_> |
|
|
ISPs try to offer a more reliable quality of service for the majority of clients. Ping on a game server is relative. It is going to depend where in the world it is and in many cases how busy it and the various paths to it are as well. If the hardcore gamers were in the majority of users, it is possible there would be a larger focus on ping. At this point, the focus will remain on stability. Try asking again after everyone and their grandparents start playing CoD or some other real game and all become as obsessed with ping as the significant minority are right now, then you might get an ISP to do something. |
|
CartelIntel inside Your sensitive data outside Premium Member join:2006-09-13 Chilliwack, BC |
to jtl999
I found this! » aurora.on.tac.net/Telus West round-trip min/avg/max = 40/40/44 ms Telus East round-trip min/avg/max = 76/79/80 ms |
|
pfak Premium Member join:2002-12-29 Vancouver, BC |
to Ikarasu
said by Ikarasu:Anyone have a Teksavvy or other wholesaler able to post pings? Both TekSavvy and Novus use Peer1 for the bulk of their upstream. |
|
|
to jtl999
Like stated, they all don't care much about pings or routes. Only latency sensitivity applications really need the lowest latency possible and games fall under that. No ISP cares about your precious ping in games. With that being said, both Shaw and Telus had terrible routes at times. A lot of it being with who the connect is. Overall, since the switch back to Shaw Biz, my routes have improved compared to my Optik. Take it for what it is. |
|
|
to nss_tech
said by nss_tech:ISPs try to offer a more reliable quality of service for the majority of clients. Ping on a game server is relative. It is going to depend where in the world it is and in many cases how busy it and the various paths to it are as well. If the hardcore gamers were in the majority of users, it is possible there would be a larger focus on ping. At this point, the focus will remain on stability. Seriously? Routing packets across the country to go next door is more stable and reliable than peering somewhere closer? More like they would rather do the bare minimum to provide a qos that enough of their customer base is happy with. |
|
DKSDamn Kidney Stones
join:2001-03-22 Owen Sound, ON |
said by ruiner3:said by nss_tech:ISPs try to offer a more reliable quality of service for the majority of clients. Ping on a game server is relative. It is going to depend where in the world it is and in many cases how busy it and the various paths to it are as well. If the hardcore gamers were in the majority of users, it is possible there would be a larger focus on ping. At this point, the focus will remain on stability. Seriously? Routing packets across the country to go next door is more stable and reliable than peering somewhere closer? Yes, as weird as that sounds, it is true. Much of my traffic on Bell is routed through Chicago. And it's fast. I get better pings to Chicago than I do to Toronto, although the physical distance is twice as far. |
|
|
ruiner3
Member
2012-Dec-18 12:35 am
Its not true. You're either being routed somewhere else first before Toronto (such as Chicago), or the link you're checking is heavily saturated and needs more bandwidth.
More likely its being routed somewhere else first. You don't always get to see what's going on inside the AS as its being routed to the next peer. |
|
DKSDamn Kidney Stones
join:2001-03-22 Owen Sound, ON |
said by ruiner3:Its not true. You're either being routed somewhere else first before Toronto (such as Chicago), or the link you're checking is heavily saturated and needs more bandwidth.
More likely its being routed somewhere else first. You don't always get to see what's going on inside the AS as its being routed to the next peer. ROTFL! Sorry, it's true. Their routing here is through Kitchener and on to Toronto or Chicago, where Bell peers again. Geographic distance does not and never has had any relationship to efficiency of routing as expressed by lower pings or number of connections. |
|
1 edit |
Are you for real?
First, light travels at roughly 200,000 km/s in fibre. So take the trip from Vancouver to Chicago, 3500 km = ~17.5 ms each direction or 35 ms. Then you add in the time from Chicago to Seattle, 3300 km or 33 ms. Now look at Vancouver to Seattle at 230 km or 2.3 ms RTT. Just your propagation delay adds around 65 extra ms.
Typically a longer distance link will introduce more hops, which adds transmission delay, and queuing delay for each additional hop on top of the additional propagation delay. |
|
DKSDamn Kidney Stones
join:2001-03-22 Owen Sound, ON |
said by ruiner3:Are you for real?
First, light travels at roughly 200,000 km/s in fibre. So take the trip from Vancouver to Chicago, 3500 km = ~17.5 ms each direction or 35 ms. Now look at Vancouver to Seattle at 230 km or 2.3 ms RTT. Right there you have a lower ping.
Typically a longer distance link will introduce more hops, which adds transmission delay, and queuing delay for each additional hop. I am for real. Not to break the laws of physics, but there are are other factors involved. Distance is basically a negligible factor, other factors having more impact. I get a ping of 65 ms on my office connection through Bruce Telecom to Wightman in Clifford; about 70 km. I get 35 ms ping on the Teksavvy server in Toronto, 200 km. away. The reason? Bruce Telecom probably has better peering in Toronto, where Teksavvy is located, than it has to Wightman. Peering and other factors affect ping. Distance, not so much. |
|
pfak Premium Member join:2002-12-29 Vancouver, BC |
pfak
Premium Member
2012-Dec-18 11:22 am
said by DKS:Peering and other factors affect ping. Distance, not so much. I'd like some of what you're smoking ... » en.wikipedia.org/wiki/La ··· r_Optics |
|
DKSDamn Kidney Stones
join:2001-03-22 Owen Sound, ON |
Absolutely nothing. Just reflecting empirical data. As it has always been. In the real world, distance is less important than other factors. |
|
your moderator at work
hidden : Personal attacks
|
|
to DKS
Re: Telus Peering.said by DKS:I get a ping of 65 ms on my office connection through Bruce Telecom to Wightman in Clifford; about 70 km. I get 35 ms ping on the Teksavvy server in Toronto, 200 km. away. The reason? Bruce Telecom probably has better peering in Toronto, where Teksavvy is located, than it has to Wightman. Peering and other factors affect ping. Distance, not so much. Yes, for short distances which we weren't talking about. Try reading the thread you're posting in. You also realize that at each hop that is showing up, your packet can be routed through an internal network where you can't see what is going on either. Plus a lot of routers process ICMP low priority. So if the router is under load it could be in the queue for longer than a regular packet. |
|
DKSDamn Kidney Stones
join:2001-03-22 Owen Sound, ON |
said by ruiner3:said by DKS:I get a ping of 65 ms on my office connection through Bruce Telecom to Wightman in Clifford; about 70 km. I get 35 ms ping on the Teksavvy server in Toronto, 200 km. away. The reason? Bruce Telecom probably has better peering in Toronto, where Teksavvy is located, than it has to Wightman. Peering and other factors affect ping. Distance, not so much. Yes, for short distances which we weren't talking about. Try reading the thread you're posting in. If you look at the OP's post, they were pinging a server less than 100 km from Vancouver. |
|
|
to jtl999
Seattle is 200 km from Vancouver. Stuff is being routed to Chicago first, which adds an additional 65 ms just from propagation delay alone.
Then when you factor in that sometimes traffic to California is routed through Chicago, what should be a ~60ms RTT turns into 120+ ms. |
|
Lanelen Premium Member join:2000-08-02 Dallas, TX |
to WhosTheBosch
said by WhosTheBosch:Here's mine, I'm in Vancouver on Telus as well. Looks like I'm one less hop than you though which causes 20ms more time.
Tracing route to 50.22.184.114-static.reverse.softlayer.com [50.22.184.114] over a maximum of 30 hops:
3 30 ms 30 ms 30 ms 204.225.244.101 4 30 ms 30 ms 30 ms eqix-ix.softlayer.com [198.32.176.207] 5 33 ms 32 ms 31 ms ae3.bbr01.eq01.sjc02.networklayer.com [173.192.1 8.240] 6 49 ms 49 ms 49 ms ae0.bbr02.wb01.sea02.networklayer.com [173.192.1 8.146] 7 48 ms 48 ms 48 ms ae1.dar01.sr01.sea01.networklayer.com [173.192.1 8.143] 8 50 ms 49 ms 48 ms po1.fcr02.sr03.sea01.networklayer.com [67.228.11 8.225] 9 50 ms 50 ms 49 ms 50.22.184.114-static.reverse.softlayer.com [50.2 2.184.114]
Trace complete.
What's really messed up is that for some reason it's routed to Toronto on 204.225.244.101 (»www.geobytes.com/IpLocat ··· .244.101) and then New York on 198.32.176.207 (»www.geobytes.com/IpLocat ··· .176.207) and then goes from there to San Jose. The reason it goes to NY from TO is the right thing for SL to do though as that's probably the closest node to TO. I have no idea why Telus decides to send West Coast traffic through Toronto, it's mind boggling.
After reviewing it, the main reason for an extra 20ms appears to be this part where it's hitting different nodes for some reason:
Shaw 7 35 ms 35 ms 34 ms te1-7.bbr01.eq01.sjc01.networklayer.com [206.223 .116.176] 8 34 ms 35 ms 35 ms ae0.bbr02.wb01.sea02.networklayer.com [173.192.1 8.146]
Telus 5 33 ms 32 ms 31 ms ae3.bbr01.eq01.sjc02.networklayer.com [173.192.1 8.240] 6 49 ms 49 ms 49 ms ae0.bbr02.wb01.sea02.networklayer.com [173.192.1 8.146]
I still think if Telus came around and manned up to joining SIX in Seattle, they could really improve their West Coast routing:
»www.seattleix.net/partic ··· ants.htm Small update to this issue, it looks like Telus has joined the SIX and we're currently peering with them there. The new path looks to be around 16ms instead of 70ms. traceroute to 142.179.56.1 (142.179.56.1), 64 hops max, 72 byte packets
3 slr01.sea01.softlayer.com (67.228.118.97) 0.623 ms 3.146 ms 0.425 ms
4 ae4.dar02.sr01.sea01.networklayer.com (67.228.118.210) 0.365 ms 0.349 ms 0.279 ms
5 ae9.bbr01.wb01.sea02.networklayer.com (173.192.18.158) 0.600 ms 0.601 ms 0.522 ms
6 six.telus.com (206.81.80.227) 0.729 ms 0.694 ms 0.622 ms
7 75.154.215.192 (75.154.215.192) 4.953 ms 5.791 ms 4.668 ms
8 d142-179-56-1.bchsia.telus.net (142.179.56.1) 15.589 ms 15.897 ms 15.659 ms
|
|
2 edits |
to WhosTheBosch
1 1 ms 1 ms 1 ms 192.168.1.254 2 6 ms 6 ms 6 ms 10.31.206.1 3 11 ms 10 ms 10 ms 75.154.217.103 4 46 ms 11 ms 10 ms te1-5.bbr01.wb01.sea01.networklayer.com [206.81.1.140] 5 11 ms 11 ms 11 ms ae0.dar01.sr01.sea01.networklayer.com [173.192.1.199] 6 11 ms 13 ms 12 ms po1.fcr02.sr03.sea01.networklayer.com [67.228.11.225] 7 11 ms 11 ms 11 ms 50.22.184.114tatic.reverse.softlayer.com [50.2.184.114] Trace Complete My tracert is 11 ms to that address And on another note, my pings in general are better to seattle than ever before. |
|
pfak Premium Member join:2002-12-29 Vancouver, BC |
to Lanelen
said by Lanelen:Small update to this issue, it looks like Telus has joined the SIX and we're currently peering with them there. The new path looks to be around 16ms instead of 70ms.
traceroute to 142.179.56.1 (142.179.56.1), 64 hops max, 72 byte packets
3 slr01.sea01.softlayer.com (67.228.118.97) 0.623 ms 3.146 ms 0.425 ms
4 ae4.dar02.sr01.sea01.networklayer.com (67.228.118.210) 0.365 ms 0.349 ms 0.279 ms
5 ae9.bbr01.wb01.sea02.networklayer.com (173.192.18.158) 0.600 ms 0.601 ms 0.522 ms
6 six.telus.com (206.81.80.227) 0.729 ms 0.694 ms 0.622 ms
7 75.154.215.192 (75.154.215.192) 4.953 ms 5.791 ms 4.668 ms
8 d142-179-56-1.bchsia.telus.net (142.179.56.1) 15.589 ms 15.897 ms 15.659 ms
.. And satan skates to work. Guess I need to bother my ISP. traceroute to 75.157.x.x (75.157.x.x), 30 hops max, 60 byte packets
1 10.242.7.21 (10.242.7.21) 0.498 ms 0.383 ms 0.456 ms
2 204.14.120.65 (204.14.120.65) 0.937 ms 1.004 ms 1.059 ms
3 216.18.227.9 (216.18.227.9) 0.914 ms 0.909 ms 0.966 ms
4 border2.te13-2.farreachnet-2.sea.pnap.net (206.253.223.189) 1.305 ms 1.354 ms 1.427 ms
5 core1.t6-1-bbnet1.sea.pnap.net (63.251.160.16) 1.262 ms 1.264 ms 1.304 ms
6 xe-0-3-0-5.r05.sttlwa01.us.bb.gin.ntt.net (198.104.202.45) 1.127 ms 0.747 ms 0.891 ms
7 xe-0-1-0-2.r05.sttlwa01.us.ce.gin.ntt.net (198.104.202.206) 1.519 ms 1.821 ms 1.812 ms
8 d75-157-x-x.bchsia.telus.net (75.157.x.x) 7.909 ms 7.902 ms 7.879 ms
/sigh. |
|
(Software) pfSense MikroTik CRS125-24G-1S-RM Ubiquiti UniFi AP-LR
|
to Lanelen
Yup.
|
|
|
I wonder if this has to do with the Netflix announcement and they have their caches at SIX? Or are they stored directly on Telus' network? |
|
|
Whatever the reason, this is a pretty nice move on their part. Most of the horrible latency to the West Coast problems should be fixed. |
|