Fastest ISP?

[Henry Ng]

You having problem with HE or Cogent? Likely is IX connection because from HE looking glass it shows to GTHost prefix is not a customer route. Yes a lot of network prefer IX even with a lot of prepending. Recently Telstra are advertising M1 prefixes in a few overseas IX and messing the inbound routing for us becos their network sucks but other ISP prefer to use this route (even though it must hop thru SH first) because dunnid need to pay expensive transit fees.


Interesting. I just try and also having spikes to HK with HE. No issue on GSL. Why everything so congested recently ah? Major attacks going on?




False.. ISP has the responsibility to ensure its upstream providers are reliable and have sufficient capacity. If they rely on poor upstream connections, that will reflect degraded service compared to another ISP that optimises their redundancy routes/peering agreements to minimise the impact of overseas congestion. But if you are saying touchwood got some extreme incident like multiple cable cuts or DC burned down which affects all ISPs, then that is a different matter.

Singapore ISP is only responsible for local connection as it is beyond their control and that is what Singtel, M1 and Starhub mentioned to me earlier when i asked their CSO and backend engineer about overseas speed and connection.

 

[Henry Ng]

See what AI has to say:

Singapore ISPs are generally not legally responsible for slow upload speeds to specific overseas servers. Factors such as geographical distance, the capacity of intermediate international networks, and the destination server's own infrastructure are typically outside the ISP's direct control.

 

[seowbin]

Packet loss rate is the key for smooth streaming. Latency is less important.

This one I got research a bit leh. Nowadays video are streamed in multiple smaller files. If packet loss , should be able to get it again.

I strongly believe it's congested at certain point between providers and providers.

I recall last time I tried to stream some Europe content as well behind Deutsche Telekom. The experience quite poor, I manipulated a bit using bgp community so that they return traffic via other isp back to me. It works well

 

[Henry Ng]

See what AI say:

Singapore ISPs have numerous international peering partners, which vary by provider and are typically established through major global Internet Exchange Points (IXPs) and bilateral agreements. These partnerships are extensive and not restricted to a "standard" list for home users.

Key Aspects of Peering for Singapore ISPs

• Internet Exchange Points (IXPs): ISPs interconnect at various IXPs to exchange local and international traffic efficiently. Key IXPs in Singapore include the Singapore Internet Exchange (SGIX), Singapore Open Exchange, and Equinix Internet Peering Exchange.
• Global Transit and Peering: Singapore ISPs generally use a mix of both peering arrangements and purchasing IP Transit from Tier 1 carriers to ensure global connectivity. This gives them access to a vast global backbone network.
• Selective Peering Policies: Major ISPs like Singtel and StarHub often have "selective" peering policies, meaning they review requests to peer on an individual basis rather than automatically peering with all networks.
• Content Delivery Networks (CDNs): Many large content providers and CDNs (such as Akamai, Amazon, Apple, Google, Microsoft, and Netflix) have a direct presence and peer within Singapore, which significantly improves performance and reduces latency for accessing popular overseas content.
  
  
• These articles explain StarHub's selective peering policies and Singapore's Internet peering landscape:
  Peering Policy - About StarHub
  Information for Potential Peering Partners: The StarHub IP network consists of several Autonomous System Numbers (“ASNs”).
  
  https://corporate.starhub.com/about...s-and-conditions/business/peering-policy.html
  
  Major Overseas Peering Partners
  
  
  
  The exact list of overseas peering partners is dynamic and commercially sensitive, but the major ISPs connect with global telecommunications companies and content providers in key international peering locations (e.g., Hong Kong, the United States, Europe, Japan). Common partners and transit providers mentioned in public information and peering databases include:

• Tier 1 Carriers/Transit Providers: Arelion (fka. Telia Carrier), Cogent Communications, NTT America, Telstra Global, TATA Communications, and Hurricane Electric.
• Global IXPs: Singapore ISPs have points of presence (PoPs) or access to global IXPs, such as:
  • AMS-IX (Amsterdam Internet Exchange)
  • BBIX (BroadBand Internet eXchange) in Japan and Singapore
  • DE-CIX (German Internet Exchange) in various global locations
  • LINX (London Internet Exchange)
• Content Providers and Hyperscalers: Large entities like Amazon (AWS), Apple Inc., ByteDance, Cloudflare, Google, and Microsoft are common peering partners.

The collective result of these extensive interconnections and partnerships ensures that home internet users in Singapore have efficient and reliable access to global online services.

 

[Henry Ng]

global Tier 1 network is already the highest level available.

https://www.ams-ix.net/ams/connected-networks

 

[ieatcable]

This one I got research a bit leh. Nowadays video are streamed in multiple smaller files. If packet loss , should be able to get it again.

I strongly believe it's congested at certain point between providers and providers.

I recall last time I tried to stream some Europe content as well behind Deutsche Telekom. The experience quite poor, I manipulated a bit using bgp community so that they return traffic via other isp back to me. It works well

Yesterday during the congestion when I was testing the download file on FDC servers, no issues when download from web browser and I can get 10-20MB/s. But if I use curl single stream, sometimes they put me on a congested route and the download suffer at 200KB/s with constant pausing. The buffering on the stream from @probablye that could be due to the bad paths used during some TCP streams.

At times like this bo bian just tell the upstream not to advertise your prefixes so that traffic can flow from a backup upstream with less problems. It may not be your fault there is a congestion, but end users are still going to demand a certain service standard from you

See what AI has to say:

Singapore ISPs are generally not legally responsible for slow upload speeds to specific overseas servers. Factors such as geographical distance, the capacity of intermediate international networks, and the destination server's own infrastructure are typically outside the ISP's direct control.

Go ahead if u think AI slop knows more than some who have insights in the industry and u want to normalise poor traffic engineering lots of misinformation from above I dunno where to start.

 

[seowbin]

At times like this bo bian just tell the upstream not to advertise your prefixes so that traffic can flow from a backup upstream with less problems. It may not be your fault there is a congestion, but end users are still going to demand a certain service standard from you

If successful, let me know.

 

[ieatcable]

If successful, let me know.

Need to do more testing tonight and see if M1 support can do anything. My worry is how to re-create the problem so that their NOC can investigate. Maybe by the time I report, the congestion is over. By the way if you not venturing into home ISP ah, consider VPN/VPS service leh ... Let us use your network

 

[Henry Ng]

Need to do more testing tonight and see if M1 support can do anything. My worry is how to re-create the problem so that their NOC can investigate. Maybe by the time I report, the congestion is over. By the way if you not venturing into home ISP ah, consider VPN/VPS service leh ... Let us use your network

Earlier when i was with Singtel, they told me not within their control as mentioned by their backend. Later i went to M1 and also give same answer that not within their control. Now SH also said not within isp control.
You try and see whether M1 give you the same answer. They said the plan i signed is only for local speed.

 

[Henry Ng]

ISP: This means that your internet connection is very healthy.

 

[cyberet]

Spoiler

I wish to consult the network gurus here on something please.

Why does Singtel often perform better (in my experience at least) despite always having the worst results?

Previously I had Viewqwest and Singtel broadband. I now use MyRepublic (Gamer), with the Singtel line expiring soon but I still have access to it.

I don't watch local TV, so I stream video from all around the world, mostly US, UK and Australia, sometimes there's a Switzerland based server also.

Here's my frustration - no matter how much better the latency and routing are on VQ and MR, ST always streams better from these video services in comparison!

There's one particular US service hosted on FDCServers in LA which is particularly problematic. But the thing is, whenever I get buffering on VQ/MR, ST would stream without issue. I've even tried Cloudflare Warp but somehow ST still manages to maintain a decent stream when all else fails.

I put this question to AI and it tells me this:
1) Even though both ST and MR use Tata's uplink to the US, MR's link could be congested / less direct;
2) ST shows some local congestion but their upstream transit has bigger capacity and therefore performs better / does not suffer from congestion overseas;
3) MR has low latency but this is good only for short bursts of low data traffic (like gaming), but for HD video streaming, an ISP with higher bandwidth could work better, even despite lousier routing that hairpins through the US;
4) As a Tier 1 ISP, ST could have a private arrangement for priority traffic even when the routes appear to be the same;
5) Even though MR is now part of Starhub, MR still has its own ASN and may be bottlenecked by the amount of capacity that SH shares with it.
6) Overall, it's still better to use an ISP like ST that has Tier 1 peers and upstream providers, because they own the subsea cables and have excess bandwidth to cater for their large customer base.

I truly hate ST with a vengeance. But if I didn't look at all these traceroutes and ping tests, I have to admit that it tends to work better.

Can anyone explain? Are the points made by AI correct? I would really like to understand this better.

thats funny, I have ST/VQ and MR (via wireguard). I experience buffering on ST which is resolved when I switch to VQ/MR. Didn't take note which server it was streaming from though.

 

[Henry Ng]

Yesterday during the congestion when I was testing the download file on FDC servers, no issues when download from web browser and I can get 10-20MB/s. But if I use curl single stream, sometimes they put me on a congested route and the download suffer at 200KB/s with constant pausing. The buffering on the stream from @probablye that could be due to the bad paths used during some TCP streams.

At times like this bo bian just tell the upstream not to advertise your prefixes so that traffic can flow from a backup upstream with less problems. It may not be your fault there is a congestion, but end users are still going to demand a certain service standard from you


Go ahead if u think AI slop knows more than some who have insights in the industry and u want to normalise poor traffic engineering lots of misinformation from above I dunno where to start.

See what My Republic say about international speed below.
https://support.myrepublic.net/en/a...rience-can-i-expect-with-myrepublic-s-network

 

[seowbin]

Not within their control is correct depending on what context

https://www.thousandeyes.com/blog/path-quality-surprising-impact-one-percent-packet-loss

 

[ieatcable]

HE's link to HK and Korea congested is it?

I've been seeing multi week ping spikes to servers in HK and Seoul via HE.

Asked HE NOC about the HK spikes. They said it was congestion "due to multiple subsea cable cuts in the region."

According to public info, looks like APG and TGN-IA are having outage. I lose access to insider info liao. Maybe @seowbin have sub cable subscription to HK can know what's up

 

[seowbin]

Asked HE NOC about the HK spikes. They said it was congestion "due to multiple subsea cable cuts in the region."

According to public info, looks like APG and TGN-IA are having outage. I lose access to insider info liao. Maybe @seowbin have sub cable subscription to HK can know what's up

I don't know leh. If affected then will know. Haha. I using c2c , not affected. Adding ADC.

 

[lightningroood]

This one I got research a bit leh. Nowadays video are streamed in multiple smaller files. If packet loss , should be able to get it again.

I strongly believe it's congested at certain point between providers and providers.

I recall last time I tried to stream some Europe content as well behind Deutsche Telekom. The experience quite poor, I manipulated a bit using bgp community so that they return traffic via other isp back to me. It works well

My packet loss theory is based on my observation from work. One day I curled an object of less than 10MB hosted in the US on AWS from a server in SG (non-AWS). The experience was very sluggish. Many many intermittent halts so that it couldn't finish even after minutes. Internet bandwidth limit was >1000 Mbps for both ends and very far from saturated. I then noticed packet loss rate was about 30% as per output by ping. Latency though was about 200ms which was normal. Eventually it's fixed by engaging support from both cloud providers. They somehow changed routing and eliminated packet loss. As a result, curl went quite smooth while ping was still 200ish ms but without any packet loss. From that day on, my belief shifted to packet loss rate from latency.
I think when congested, higher packet loss could also be a symptom. So my theory probably doesn't conflict with yours at all.

 

[cnnwatcher]

My packet loss theory is based on my observation from work. One day I curled an object of less than 10MB hosted in the US on AWS from a server in SG (non-AWS). The experience was very sluggish. Many many intermittent halts so that it couldn't finish even after minutes. Internet bandwidth limit was >1000 Mbps for both ends and very far from saturated. I then noticed packet loss rate was about 30% as per output by ping. Latency though was about 200ms which was normal. Eventually it's fixed by engaging support from both cloud providers. They somehow changed routing and eliminated packet loss. As a result, curl went quite smooth while ping was still 200ish ms but without any packet loss. From that day on, my belief shifted to packet loss rate from latency.
I think when congested, higher packet loss could also be a symptom. So my theory probably doesn't conflict with yours at all.

were you using ipv6 or ipv4?

 

[lightningroood]

were you using ipv6 or ipv4?

ipv4

 

[xiaofan]

Today's results (13-Oct-2025), 9:30pm on a Sunday evening.

Singtel results will always look bad for this test -- probably due to bad peering policy.

Similar wireless setup, just a new laptop.

Singtel ZTE F8648P ONR bridged 10G LAN port --> Intel N100 OpenWRT virtual router --> 2.5G/10G switch --> TUF-BE6500 router --> wireless --> Acer Swift Go 14 2024 Laptop running Windows 11 25H2 (Intel Core Ultra 5 125HCPU, 16GB/1TGB, Intel Killer BE1750 WiFi 7 adapter)

https://www.meter.net/tools/world-ping-test/#0-442290-bd2b45

Same wireless setup as the above test.

Singtel IPv4 address is 119.74.xxx.xxx (different Singtel IPv4 segment may have different performances)

Today's results (19-Jan-2026), 7:30pm on a Monday evening.
https://www.meter.net/tools/world-ping-test/#0-564438-e0cef3

 

[ieatcable]

Same wireless setup as the above test.

Singtel IPv4 address is 119.74.xxx.xxx (different Singtel IPv4 segment may have different performances)

Today's results (19-Jan-2026), 7:30pm on a Monday evening.
https://www.meter.net/tools/world-ping-test/#0-564438-e0cef3

This prefix 119.74.0.0/16 is not advertised by Zayo. The effect is that it can reflect better latency than other ST prefixes that has Zayo for EU servers. lesser chance for incoming traffic trombone to USA. Interestingly, the IP (121.7.129.x) which I tested last week also no longer going via Zayo.

Comparing 119.74.0.0/16 and 118.200.0.0/16 from OVH.

HOST: lil2.lg.ovh.net                                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS16276  141.94.18.1                                                      0.0%     3    0.3   0.3   0.2   0.3   0.0
  2. AS???    192.168.143.254                                                  0.0%     3    0.3   0.3   0.2   0.3   0.1
  3. AS???    10.225.10.126                                                    0.0%     3    0.4   0.4   0.4   0.4   0.0
  4. AS???    10.225.4.184                                                     0.0%     3    0.5   0.5   0.4   0.5   0.1
  5. AS???    10.225.17.158                                                    0.0%     3    0.6   0.7   0.6   0.8   0.1
  6. AS???    10.73.240.66                                                     0.0%     3    0.6   0.7   0.6   0.7   0.1
  7. AS???    172.20.16.40                                                     0.0%     3    4.1   3.5   2.8   4.1   0.7
  8. AS16276  37.59.16.31                                                      0.0%     3    1.1   1.0   0.9   1.1   0.1
  9. AS16276  be102.par-th2-sbb1-nc5.fr.eu (213.186.32.215)                    0.0%     3    5.4   5.2   5.0   5.4   0.2
 10. AS???    10.200.2.77                                                      0.0%     3    5.2   5.2   5.2   5.3   0.0
 11. AS???    ???                                                             100.0     3    0.0   0.0   0.0   0.0   0.0
 12. AS1299   prs-bb1-link.ip.twelve99.net (62.115.125.170)                    0.0%     3    5.6   5.7   5.6   5.8   0.1
 13. AS1299   mei-b5-link.ip.twelve99.net (62.115.124.55)                      0.0%     3   15.7  15.4  15.2  15.7   0.3
 14. AS1299   singaporetelco-ic-349155.ip.twelve99-cust.net (62.115.179.183)   0.0%     3  153.8 153.8 153.7 153.8   0.1
 15. AS4845 7473203.208.158.161                                                  0.0%     3  154.4 155.6 154.3 158.0   2.1
 16. AS7473   203.208.158.9                                                    0.0%     3  155.2 155.4 154.5 156.5   1.0
 17. AS7473   203.208.183.90                                                   0.0%     3  154.4 154.6 154.2 155.1   0.5
 18. AS7473   203.208.149.26                                                   0.0%     3  154.5 155.8 154.3 158.6   2.4
 19. AS7473   203.208.177.214                                                 66.7%     3  238.9 238.9 238.9 238.9   0.0
 20. AS3758   SN-SINQT1-BO307-ae4.singnet.com.sg (165.21.138.82)               0.0%     3  241.1 241.1 241.1 241.2   0.1
 21. AS3758   165.21.138.242                                                  33.3%     3  236.8 237.0 236.8 237.1   0.2
 22. AS3758   165.21.193.22                                                    0.0%     3  241.2 243.1 241.1 247.2   3.5
 23. AS???    ???                                                             100.0     3    0.0   0.0   0.0   0.0   0.0
 24. AS9506   bb119-74-171-1.singnet.com.sg (119.74.171.1)                    33.3%     3  240.5 240.6 240.5 240.6   0.1

HOST: lil2.lg.ovh.net                                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS16276  141.94.18.1                                                      0.0%     3    0.3   0.3   0.3   0.3   0.0
  2. AS???    192.168.143.254                                                  0.0%     3    0.3   0.3   0.3   0.3   0.0
  3. AS???    10.225.10.126                                                    0.0%     3    0.5   0.5   0.4   0.6   0.1
  4. AS???    10.225.4.184                                                     0.0%     3    0.5   0.6   0.5   0.7   0.1
  5. AS???    10.225.17.158                                                    0.0%     3    0.6   0.7   0.6   0.8   0.1
  6. AS???    10.73.240.67                                                    33.3%     3    0.7   0.7   0.7   0.8   0.0
  7. AS???    172.20.16.56                                                     0.0%     3    2.8   2.5   1.9   2.8   0.5
  8. AS16276  37.59.16.29                                                      0.0%     3    1.4   1.4   1.4   1.4   0.0
  9. AS16276  be102.par-gsw-sbb1-nc5.fr.eu (91.121.215.177)                    0.0%     3    5.0   5.1   5.0   5.2   0.1
 10. AS???    10.200.2.7                                                       0.0%     3    4.8   4.9   4.8   5.0   0.1
 11. AS???    ???                                                             100.0     3    0.0   0.0   0.0   0.0   0.0
 12. AS6461   ae18.cr1.cdg12.fr.zip.zayo.com (64.125.26.68)                   33.3%     3  143.4 144.9 143.4 146.3   2.0
 13. AS???    ???                                                             100.0     3    0.0   0.0   0.0   0.0   0.0
 14. AS???    ???                                                             100.0     3    0.0   0.0   0.0   0.0   0.0
 15. AS6461   ae14.cr1.dfw1.us.zip.zayo.com (64.125.19.20)                    33.3%     3  142.5 142.5 142.5 142.6   0.1
 16. AS6461   ae0.cr2.dfw7.us.zip.zayo.com (64.125.20.63)                      0.0%     3  142.5 142.4 142.4 142.5   0.0
 17. AS6461   ae2.cr1.lax10.us.zip.zayo.com (64.125.25.78)                    33.3%     3  142.2 142.2 142.2 142.3   0.1
 18. AS6461   ae1.cr2.lax20.us.zip.zayo.com (64.125.26.5)                      0.0%     3  142.3 142.3 142.2 142.5   0.1
 19. AS???    ???                                                             100.0     3    0.0   0.0   0.0   0.0   0.0
 20. AS6461   ae14.mpr1.lax12.us.zip.zayo.com (64.125.27.39)                   0.0%     3  144.9 145.1 142.4 148.0   2.8
 21. AS6461   64.125.35.198.IPYX-145641-003-ZYO.zip.zayo.com (64.125.35.198)   0.0%     3  246.7 243.3 239.8 246.7   3.4
 22. AS7473   203.208.171.118                                                  0.0%     3  240.3 241.3 240.3 242.8   1.3
 23. AS7473   203.208.172.165                                                  0.0%     3  239.0 238.2 236.6 239.1   1.4
 24. AS7473   203.208.158.9                                                    0.0%     3  237.8 239.1 236.7 242.7   3.2
 25. AS7473   203.208.158.206                                                  0.0%     3  236.5 239.1 236.5 240.8   2.3
 26. AS7473   203.208.143.130                                                  0.0%     3  319.8 321.2 319.8 323.1   1.7
 27. AS3758   165.21.139.133                                                   0.0%     3  324.7 337.5 321.3 366.5  25.2
 28. AS3758   165.21.139.170                                                   0.0%     3  320.2 321.4 320.2 323.4   1.7
 29. AS3758   165.21.193.234                                                   0.0%     3  320.5 320.9 320.5 321.7   0.6
 30. AS9506   bb118-200-106-173.singnet.com.sg (118.200.106.173)               0.0%     3  323.2 325.4 323.2 326.9   1.9

Could be mitigation for the packet loss issue last week by cutting traffic coming through US POP. Not a proper fix, but at least it works somewhat?