You're mixing ping and latency with speed/bandwidth for delivery and regular browsing or video viewing.Moreover, that ms speed does not affect experience if there is bandwidth.
Regarding CDNs being slower, like everything cant be labelled on latency when it comes to contend download. The CDNs you mentioned, i checked that they did not seem to have any slow speed or bottleneck with PTCL.
Regarding low latency which is required in audio/video calling, yes, and routing is based on BSR mostly and some instances PTCL is better and in some other bandwidth providers depending upon transit and where they have best service available.
Regarding GPON, although this isnt a GPON thread, but GPON shouldn't require port refresh, why would you do that?
It may appear that I'm mixing pings with bandwidth, but I'll tell you why I made that relationship: CDNs. Or IPTV. I have used IPTV services with servers/mirrors in Singapore, and in the UK (?). When switching channels, the Singapore service would switch faster vs. the UK service. That's latency. But speed? You know if you get connected to a farther away service, that means lots of computers in between, and if one chain in between is acting up, the rest will act up as well, correct? CDNs were made so that there's low latency/high speeds to the end-users. Otherwise, we wouldn't be using CDNs in the first place. Google does this. Akamai does this. Amazon, Cloudfare, Fastly and other websites do this. That's the connection.
These CDNs (thankfully) don't have slow speeds but what about websites that aren't CDN-based? Because the routing to the UK is shot, one bad apple is having a ripple effect. Most websites I know are now using CDNs but CNN and 300ms latency is insane because they have a mirror - in the UAE - and PTCL is connected to the UAE IX, where pings are as low as 50ms if properly configured. But instead, it's 300ms. If I want to talk to someone in - for example, the Middle East, there shouldn't be a lagfest. It's like talking to the person next to you, but with delayed responses. And since the concept follows Chinese whispers, everything will slow down because of one retarded hop in between. Bandwidth for VOIP isn't important - QOS is. And PTCL's QOS to Cloudfare or some European services is not good. So far, I haven't come across many websites impacted by speeds (which is great!) but I'm not getting a responsive service.
You mentioned "routing is based on BSR" - could you explain this in very simple terms (for the benefit of everyone, including myself)? You seem to know networking more than we do, so it would help. Also, you said "some instances PTCL is better and in some other bandwidth providers depending upon transit and where they have best service available" - I also agree with this. Cloudfare UAE is good in terms of the number of hops, but the latency?
(before I continue, you wrote "GPON shouldn't require port refresh, why would you do that?" - I only mentioned it because my 4g connection is wireless and Mobilink managed to fix it via a simple port refresh, so I thought that might work with GPON too. I'm not familiar with the nitty gritty, and hence, my suggestion).
Let me give another example where there's inconsistent routing, for reasons beyond my understanding. I'm going to refer to my GPON connection and a third party website in Pakistan which permits me to conduct traces. I'm only sharing these because there's something in the network which is triggering a ripple effect on all OTHER websites - so basically, unrelated IPs "maar khaa rahay hain muft main" whereas they could be fixed. And they were fixed about two or so months ago. What happened in between, God knows.
CNN:
Tracing route to turner-tls.map.fastly.net [151.101.1.67]
over a maximum of 30 hops:
1 2 ms 2 ms 1 ms 192.168.100.1
2 4 ms 3 ms 3 ms 182.176.0.120
3 5 ms 4 ms 4 ms 10.0.2.221
4 4 ms 4 ms 5 ms 10.0.2.149
5 28 ms 27 ms 27 ms 10.1.1.6
6 33 ms 30 ms 29 ms khi275.c1.nxb.ptcl.com.pk [221.120.248.51]
7 28 ms 29 ms 29 ms hi77c2-Sw494b.pie.net.pk [202.125.128.134]
8 294 ms 295 ms 294 ms 195.229.27.217
9 286 ms 284 ms 285 ms 195.229.0.93
10 304 ms 303 ms 302 ms 195.229.0.241
11 302 ms 286 ms 286 ms 195.229.4.245
12 300 ms 296 ms 303 ms 151.101.1.67
Trace complete.
I've highlighted the hop where the hop is inordinately high. As for Nexlinx's portal (lg.nexlinx.net.pk), this is what I *should* get, given that I'm on the same route:
[FONT="]Target: 151.101.1.67, IP: 151.101.1.67, FQDN: [/FONT]
HOST: queue.nexlinx.net.pk Loss% Snt Last Avg Best Wrst StDev
1. FE-3-0-100M-CORE.nexlinx.net 0.0% 1 0.3 0.3 0.3 0.3 0.0
2. 10.10.80.11 0.0% 1 0.4 0.4 0.4 0.4 0.0
3. 119.159.233.113 0.0% 1 1.4 1.4 1.4 1.4 0.0
4. lhr63.pie.net.pk 0.0% 1 3.9 3.9 3.9 3.9 0.0
5. rwp44.pie.net.pk 0.0% 1 24.1 24.1 24.1 24.1 0.0
6. hi77c2-Sw494b.pie.net.pk 0.0% 1 22.2 22.2 22.2 22.2 0.0
7. 195.229.27.213 0.0% 1 40.7 40.7 40.7 40.7 0.0
8. 195.229.0.89 0.0% 1 38.5 38.5 38.5 38.5 0.0
9. 195.229.0.160 0.0% 1 40.0 40.0 40.0 40.0 0.0
10. 195.229.4.245 0.0% 1 38.3 38.3 38.3 38.3 0.0
11. 151.101.1.67 0.0% 1 40.6 40.6 40.6 40.6 0.0
I've highlighted in red the hop with the same subnet, but with a MUCH LOWER latency. I suspect this portal is in Lahore, so add another 10ms for Islamabad, I guess.
Here's another:
www.s-cool.co.uk (54.171.167.116) (also CDN)
My connection:
Tracing route to ec2-54-171-167-116.eu-west-1.compute.amazonaws.com [54.171.167.116]
over a maximum of 30 hops:
1 2 ms 5 ms 2 ms 192.168.100.1
2 6 ms 5 ms 4 ms 182.176.0.120
3 9 ms 4 ms 4 ms 10.10.100.2
4 12 ms 9 ms 10 ms 10.0.2.149
5 29 ms 27 ms 28 ms 10.1.1.6
6 29 ms 29 ms 28 ms khi275.c2.nxa.ptcl.com.pk [221.120.248.12]
7 34 ms 32 ms 28 ms khi494.nxa.2c.ptcl.com.pk [221.120.248.5]
8 131 ms 140 ms 131 ms te0-7-0-12.ccr21.mrs01.atlas.cogentco.com [149.14.126.17]
9 133 ms 132 ms 135 ms be3092.ccr41.par01.atlas.cogentco.com [130.117.49.153]
10 150 ms 150 ms 150 ms be12497.ccr41.lon13.atlas.cogentco.com [154.54.56.129]
11 151 ms 151 ms 154 ms be3487.ccr51.lhr01.atlas.cogentco.com [154.54.60.6]
12 152 ms 150 ms 154 ms be3671.agr21.lhr01.atlas.cogentco.com [130.117.48.138]
13 154 ms 151 ms 151 ms amazon.demarc.cogentco.com [149.11.167.138]
14 277 ms 277 ms 277 ms 52.94.34.48
15 * * * Request timed out.
16 * * * Request timed out.
17 298 ms 372 ms 294 ms 176.32.106.237
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * ^C
From lg.nexlinx.net.pk
[FONT="]Target: www.s-cool.co.uk, IP: 54.171.167.116, FQDN: ec2-54-171-167-116.eu-west-1.compute.amazonaws.com[/FONT]
HOST: queue.nexlinx.net.pk Loss% Snt Last Avg Best Wrst StDev
1. FE-3-0-100M-CORE.nexlinx.net 0.0% 1 0.3 0.3 0.3 0.3 0.0
2. 10.10.80.11 0.0% 1 0.6 0.6 0.6 0.6 0.0
3. 119.159.233.113 0.0% 1 1.2 1.2 1.2 1.2 0.0
4. lhr63.pie.net.pk 0.0% 1 1.9 1.9 1.9 1.9 0.0
5. rwp44.pie.net.pk 0.0% 1 22.4 22.4 22.4 22.4 0.0
6. static.khi77.pie.net.pk 0.0% 1 21.0 21.0 21.0 21.0 0.0
7. te0-0-0-9.ccr21.mrs01.atlas. 0.0% 1 131.7 131.7 131.7 131.7 0.0
8. be3092.ccr41.par01.atlas.cog 0.0% 1 133.8 133.8 133.8 133.8 0.0
9. be12497.ccr41.lon13.atlas.co 0.0% 1 140.4 140.4 140.4 140.4 0.0
10. be3487.ccr51.lhr01.atlas.cog 0.0% 1 143.7 143.7 143.7 143.7 0.0
11. be3671.agr21.lhr01.atlas.cog 0.0% 1 149.8 149.8 149.8 149.8 0.0
12. a100-row.demarc.cogentco.com 0.0% 1 150.7 150.7 150.7 150.7 0.0
13. 52.95.61.94 0.0% 1 159.3 159.3 159.3 159.3 0.0
14. 52.95.61.103 0.0% 1 155.0 155.0 155.0 155.0 0.0
15. ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
16. 54.239.42.181 0.0% 1 163.6 163.6 163.6 163.6 0.0
17. ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
18. 52.93.6.174 0.0% 1 174.4 174.4 174.4 174.4 0.0
19. 52.93.101.57 0.0% 1 159.5 159.5 159.5 159.5 0.0
20. 52.93.101.24 0.0% 1 169.1 169.1 169.1 169.1 0.0
21. 52.93.7.103 0.0% 1 165.1 165.1 165.1 165.1 0.0
22. ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
BBC: my connection
Tracing route to
www.bbc.net.uk [212.58.244.71]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.100.1
2 8 ms 3 ms 3 ms 182.176.0.120
3 5 ms 4 ms 4 ms 10.10.100.10
4 5 ms 4 ms 4 ms 10.0.2.149
5 28 ms 27 ms 28 ms 10.1.1.6
6 27 ms 30 ms 30 ms khi275.c2.nxa.ptcl.com.pk [221.120.248.12]
7 30 ms 31 ms 28 ms static.khi77.pie.net.pk [202.125.128.151]
8 161 ms 146 ms 139 ms te0-0-0-1.ccr21.mrs01.atlas.cogentco.com [149.14.125.209]
9 134 ms 135 ms 133 ms be3092.ccr41.par01.atlas.cogentco.com [130.117.49.153]
10 275 ms 276 ms 276 ms prs-b2-link.telia.net [213.155.141.226]
11 292 ms 293 ms 291 ms prs-bb4-link.telia.net [62.115.122.10]
12 279 ms 282 ms 319 ms ldn-bb4-link.telia.net [62.115.114.228]
13 292 ms 291 ms 292 ms ldn-b5-link.telia.net [213.155.132.197]
14 252 ms 289 ms 326 ms atos-ic-315186-ldn-b5.c.telia.net [62.115.144.161]
15 * * * Request timed out.
16 280 ms 277 ms 277 ms ae0.er01.telhc.bbc.co.uk [132.185.254.109]
17 283 ms 282 ms 304 ms 132.185.255.148
18 276 ms 286 ms 275 ms bbc-vip116.telhc.bbc.co.uk [212.58.244.71]
Trace complete.
lg.nexlinx.net.pk
[FONT="]Target: 212.58.244.71, IP: 212.58.244.71, FQDN: bbc-vip116.telhc.bbc.co.uk[/FONT]
HOST: queue.nexlinx.net.pk Loss% Snt Last Avg Best Wrst StDev
1. FE-3-0-100M-CORE.nexlinx.net 0.0% 1 0.3 0.3 0.3 0.3 0.0
2. 10.10.80.11 0.0% 1 0.6 0.6 0.6 0.6 0.0
3. 119.159.233.113 0.0% 1 1.2 1.2 1.2 1.2 0.0
4. lhr63.pie.net.pk 0.0% 1 4.1 4.1 4.1 4.1 0.0
5. rwp44.pie.net.pk 0.0% 1 25.4 25.4 25.4 25.4 0.0
6. khi494.nxa.2c.ptcl.com.pk 0.0% 1 28.8 28.8 28.8 28.8 0.0
7. te0-4-0-27.ccr21.mrs01.atlas 0.0% 1 128.9 128.9 128.9 128.9 0.0
8. be3092.ccr41.par01.atlas.cog 0.0% 1 128.7 128.7 128.7 128.7 0.0
9. prs-b2-link.telia.net 0.0% 1 136.5 136.5 136.5 136.5 0.0
10. prs-bb4-link.telia.net 0.0% 1 158.1 158.1 158.1 158.1 0.0
11. ldn-bb4-link.telia.net 0.0% 1 145.9 145.9 145.9 145.9 0.0
12. ldn-b5-link.telia.net 0.0% 1 146.3 146.3 146.3 146.3 0.0
13. atos-ic-315186-ldn-b5.c.teli 0.0% 1 143.3 143.3 143.3 143.3 0.0
14. ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
15. ae0.er02.telhc.bbc.co.uk 0.0% 1 148.2 148.2 148.2 148.2 0.0
16. 132.185.255.148 0.0% 1 148.1 148.1 148.1 148.1 0.0
17. bbc-vip116.telhc.bbc.co.uk 0.0% 1 148.3 148.3 148.3 148.3 0.0
See the red text.
These are all CDN-based websites. I'm not going to paste a Twitter trace here since that's similar. I decided to conduct a trace to tfl.gov.uk and O2's website - they both report pings under 170ms (which is perfectly fine for Islamabad), but all CDN-based websites are slower, which is inherently contradictory to their purpose. Since I'm unable to directly test the IPs of various ISPs, I'm going to not comment on that (since I don't have any proof), but based on the information above, my deduction would be that there would be a slowdown especially in VOIP. But what I don't understand is why Nexlinx's route and my route are giving different ping times (even the DSL services are giving ping times akin to Nexlinx's responses, but GPON services don't, despite using the same route). I know this because my mamoo has DSL (I set it up at their place) and I test using their connection now and then. We have fiber. We don't live next door anymore so I can't readily test their connection at the same time, but lg.nexlinx.net.pk helps.
I hope I'm able to express my point of view once again. I see you've been participating in a few other threads as well, so on behalf of the "victims" of PTCL, thank you. And apologies for the long post.