| |
to DKS
Re: Telus Peering.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. |
|
