I can confirm here that my traffic to this site is routed through Toronto then Chicago - does synclive use a local P2P connection pool to other participants when it's not going to the main site? I can't see why if it's going to Chicago, then it would stay in Ottawa otherwise.
However, paradoxically: I also see the same result when I ping between two ISPs listed as on OGIX to their main web site. I am not aware if I am missing anything here as a user. Perhaps I did not pay for OGIX access in my more basic plan and no general bulk users get that route. (See results below.)
Can anyone with another ottawa colo provide an IP to ping/traceroute from another OGIX peer? I want to see it work, so far no luck keeping the traffic local between ISPs.
A bell fibre circuit is said to be terminated in Toronto, and as such wouldn't be local to Ottawa, anyway with a given local ISP - so the Toronto exchange is the one you want to be local to for most Ottawa traffic - except if you are near Montreal perhaps?
Thus any Tor / Ott colo would do for this task if your users are connected through that same exchange. Can't see how the ping time would get an lower otherwise - thus in agreement with the original poster.
- Allan
# ping 172.67.72.99 # syncspace.live
PING 172.67.72.99 (172.67.72.99): 56 data bytes
64 bytes from 172.67.72.99: icmp_seq=0 ttl=57 time=19.904 ms
64 bytes from 172.67.72.99: icmp_seq=1 ttl=57 time=20.638 ms
64 bytes from 172.67.72.99: icmp_seq=2 ttl=57 time=19.798 ms
..
# traceroute 172.67.72.99
traceroute to 172.67.72.99 (172.67.72.99), 64 hops max, 40 byte packets
1 * (*) 3.238 ms 0.625 ms 0.666 ms
2 * (*) 2.214 ms 2.281 ms 2.256 ms
3 tcore4-ottawatc_tengige0-0-0-8.net.bell.ca (64.230.49.206) 22.608 ms 19.815 ms tcore3-ottawatc_tengige0-0-0-8.net.bell.ca (64.230.49.204) 20.848 ms
4 tcore3-toronto21_hundredgige1-9-0-0.net.bell.ca (64.230.49.199) 19.873 ms tcore4-toronto63_hundredgige1-5-0-0.net.bell.ca (64.230.50.93) 17.678 ms 19.637 ms
5 tcore4-chicagocp_hundredgige0-5-0-0.net.bell.ca (64.230.79.155) 24.143 ms 17.148 ms 23.927 ms
6 bx6-chicagodt_0-7-0-0.net.bell.ca (64.230.79.87) 18.964 ms 19.308 ms 19.377 ms
7 141.101.73.14 (141.101.73.14) 33.423 ms 18.478 ms 18.223 ms
8 172.67.72.99 (172.67.72.99) 20.108 ms 20 ms 19.991 ms
# ping www.hawkigs.net
PING www.hawkigs.net (209.87.247.234): 56 data bytes
64 bytes from 209.87.247.234: icmp_seq=0 ttl=52 time=18.297 ms
64 bytes from 209.87.247.234: icmp_seq=1 ttl=52 time=18.154 ms
64 bytes from 209.87.247.234: icmp_seq=2 ttl=52 time=18.599 ms
^C
--- www.hawkigs.net ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 18.154/18.350/18.599/0.185 ms
# ping www.storm.ca
PING www.storm.ca (209.87.239.67): 56 data bytes
64 bytes from 209.87.239.67: icmp_seq=0 ttl=53 time=15.361 ms
64 bytes from 209.87.239.67: icmp_seq=1 ttl=53 time=15.235 ms
64 bytes from 209.87.239.67: icmp_seq=2 ttl=53 time=15.178 ms
^C
--- www.storm.ca ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 15.178/15.258/15.361/0.077 ms
# ping www.rogers.com
PING e14237.e12.akamaiedge.net (104.65.57.235): 56 data bytes
64 bytes from 104.65.57.235: icmp_seq=0 ttl=57 time=4.734 ms
64 bytes from 104.65.57.235: icmp_seq=1 ttl=57 time=4.687 ms
64 bytes from 104.65.57.235: icmp_seq=2 ttl=57 time=4.734 ms
^C
--- e14237.e12.akamaiedge.net ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 4.687/4.718/4.734/0.022 ms
# ping www.bell.ca
PING e8711.a.akamaiedge.net (104.65.46.148): 56 data bytes
64 bytes from 104.65.46.148: icmp_seq=0 ttl=57 time=4.173 ms
64 bytes from 104.65.46.148: icmp_seq=1 ttl=57 time=4.130 ms
64 bytes from 104.65.46.148: icmp_seq=2 ttl=57 time=4.113 ms
^C
--- e8711.a.akamaiedge.net ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 4.113/4.139/4.173/0.025 ms
# ping www.google.ca
PING www.google.ca (172.217.0.227): 56 data bytes
64 bytes from 172.217.0.227: icmp_seq=0 ttl=115 time=7.226 ms
64 bytes from 172.217.0.227: icmp_seq=1 ttl=115 time=7.226 ms
64 bytes from 172.217.0.227: icmp_seq=2 ttl=115 time=7.060 ms
# traceroute www.rogers.com
traceroute to e14237.e12.akamaiedge.net (104.65.57.235), 64 hops max, 40 byte packets
1 * (*) 4.501 ms 0.617 ms 0.662 ms
2 206.47.91.193 (206.47.91.193) 2.307 ms 2.419 ms 2.321 ms
3 tcore3-ottawatc_tengige0-0-0-8.net.bell.ca (64.230.49.204) 7.135 ms 4.776 ms 7.964 ms
4 tcore4x-ottawa23_hundredgige0-9-0-0.net.bell.ca (64.230.50.225) 5.176 ms tcore3x-ottawa23_hundredgige0-9-0-0.net.bell.ca (64.230.50.223) 8.105 ms tcore4x-ottawa23_hundredgige0-9-0-0.net.bell.ca (64.230.5$
.225) 8.15 ms
5 tcore4-montreal02_1-9-0-0.net.bell.ca (64.230.79.127) 7.498 ms tcore4-montreal01_0-14-0-0.net.bell.$
a (64.230.79.125) 5.446 ms tcore4-montreal02_1-9-0-0.net.bell.ca (64.230.79.127) 6.844 ms
6 64.230.33.142 (64.230.33.142) 5.491 ms bx1-montrealgz_et-0-0-5.net.bell.ca (64.230.26.135) 5.614 m$
6.246 ms
7 akamai_bx1-montrealgz.net.bell.ca (184.150.158.193) 14.14 ms 5.115 ms 8.168 ms
8 * * *
^C
# traceroute www.storm.ca
traceroute to www.storm.ca (209.87.239.67), 64 hops max, 40 byte packets
1 * (*) 3.014 ms 0.533 ms 0.605 ms
2 * (*) 2.214 ms 2.352 ms 2.216 ms
3 tcore3-ottawatc_tengige0-0-0-8.net.bell.ca (64.230.49.204) 10.099 ms tcore4-ottawatc_tengige0-0-0-8.net.bell.ca (64.230.49.206) 8.817 ms 9.234 ms
4 tcore4-toronto63_hundredgige1-5-0-0.net.bell.ca (64.230.50.93) 10.279 ms tcore3-toronto21_hundredgige1-9-0-0.net.bell.ca (64.230.49.199) 8.841 ms tcore4-toronto63_hundredgige1-5-0-0.net.bell.ca (64.230.5$
.93) 10.2 ms
5 * * *
6 dis3-torontoxn_ae1.net.bell.ca (64.230.97.183) 7.421 ms 7.434 ms dis3-torontoxn_ae0.net.bell.ca (64.230.97.181) 7.403 ms
7 204.101.124.42 (204.101.124.42) 7.197 ms 7.109 ms 7.19 ms
8 204-187-144-166.storm.ca (204.187.144.166) 7.305 ms 7.478 ms 7.255 ms
9 g0-0-0-2210.core-4.rtr.storm.ca (209.87.239.200) 15.072 ms 15.083 ms 14.974 ms
10 bdi982.core-2.rtr.storm.ca (209.87.239.129) 15.129 ms 18.773 ms 16.057 ms
11 * * *
12 bdi982.core-2.rtr.storm.ca (209.87.239.129) 15.217 ms^C
# traceroute www.hawkigs.net
traceroute to www.hawkigs.net (209.87.247.234), 64 hops max, 40 byte packets
1 148.59.149.1 (148.59.149.1) 3.414 ms 0.565 ms 0.606 ms
2 206.47.91.193 (206.47.91.193) 1.931 ms 1.968 ms 1.906 ms
3 tcore3-ottawatc_tengige0-0-0-8.net.bell.ca (64.230.49.204) 7.902 ms 7.618 ms tcore4-ottawatc_tengi$
e0-0-0-8.net.bell.ca (64.230.49.206) 6.889 ms
4 tcore4-toronto21_hundredgige2-4-0-2.net.bell.ca (64.230.74.9) 10.231 ms 12.804 ms 7.965 ms
5 * * *
6 dis3-torontoxn_ae1.net.bell.ca (64.230.97.183) 7.042 ms 6.974 ms 6.926 ms
7 204.101.124.42 (204.101.124.42) 6.758 ms 7.061 ms 7.043 ms
8 bdi2.core.rtr.storm.ca (204.187.144.166) 6.959 ms 7.012 ms 6.953 ms
9 g0-0-0.core-4.rtr.storm.ca (209.87.239.216) 14.568 ms 14.64 ms 14.803 ms
10 po1.access-6.rtr.storm.ca (209.87.239.136) 17.62 ms 17.76 ms 17.627 ms
11 * * *
It's certainly not the default for TekSavvy or Rogers; which definitely use Toronto for their cable modems, even just to get your cable modem online - you're out to Toronto already - as many might have known. But is Rogers nice enough to route between cable modems in the same neighbourhood or city for such P2P / realtime applications? This I cannot confirm.
----- Original Message -----
From: "Ian! D. Allen" <idallen [ at ] idallen [ dot ] ca>
To: linux [ at ] linux-ottawa [ dot ] org
Sent: Saturday, February 13, 2021 2:33:35 PM
Subject: Re: [linux] Ottawa lack of IXP peering
On Sat, Feb 13, 2021 at 12:31:51PM -0500, Brett Delmage wrote:
> On Sat, 13 Feb 2021, Ian! D. Allen wrote:
> > "Known issues with Internet routing: Some of the issues we are aware of
> > with ISPs failing to keep local traffic local:
> > Ottawa, Canada; Rogers, TekSavvy, CanNet, Acanac, Start, and Virgin
> > route all traffic via Toronto (or worse). If you or any people in your
> > ensemble are using one of these ISPs it’s probably best to use a
> > Toronto server. Bell will route directly to our Ottawa servers with 2
> > – 5ms roundtrip network latency. It seems Videotron is also good."
>
> According to who?
According to syncspace.live right here:
https://syncspace.live/get-started/
"With these kinds of situations, it may mean that it is best to use a
server in a different city. For example, if everyone in an ensemble is
getting 5ms to the server but some people are getting 30ms because their
traffic is being routed out of town and then back, it may be best to
locate the server in one of those cities that the traffic is going
through so that everyone gets roughly equal latency even though it might
not be as low as it could be for some people. These routing problems
with ISPs are beyond our control and we already put in a huge amount of
effort to locate our strategically in the most central places with the
best peering so that we can offer the lowest possible latency for the
largest number of people in that city.
If you need help sorting things out or you have more information to add
regarding problematic routing in one of our regions, please feel free to
contact us."
--
| Ian! D. Allen, BA, MMath - idallen [ at ] idallen [ dot ] ca - Ottawa, Ontario, Canada
| Home: www.idallen.com Contact Improvisation Dance: www.contactimprov.ca
| Former college professor (Free/Libre GNU+Linux) at: teaching.idallen.com
| Defend digital freedom: http://eff.org/ and have fun: http://fools.ca/
To unsubscribe send a blank message to linux+unsubscribe [ at ] linux-ottawa [ dot ] org
To get help send a blank message to linux+help [ at ] linux-ottawa [ dot ] org
To visit the archives: https://lists.linux-ottawa.org
To unsubscribe send a blank message to linux+unsubscribe [ at ] linux-ottawa [ dot ] org
To get help send a blank message to linux+help [ at ] linux-ottawa [ dot ] org
To visit the archives: https://lists.linux-ottawa.org