As long as there is at least one server in a zone, only that (or those few) server(s) will be handed out to clients. The fall-back to the continent zone only happens when there is no server at all in a zone.
I.e., when those malfunctioning servers would all be dropped from the PH zone, clients would be assigned servers from the Asia zone.
Are those NTP servers serving local clients properly? I guess there might be some geodefence in place, so monitoring failure from outside Philippines is not necessearily good indicator about their service quality.
The original post in this thread, along with two or three other thread on this forum, and the experiences of my customers in the Philippines, confirm that this problem is being experienced within the Philippines and is not just a problem of geofencing causing a lack of observability from outside the Philippines.
One particular anomaly I found interesting is that checking the Philippines-based pool servers from NTP Server Test works reliably all the time, although that site appears to send its probes from servers based in France.
I vibe coded a quick check to show this doesn’t work still.
$ /home/user/ntp_checker_enhanced.py
=== NTP Pool IP Discovery and Testing ===
Performing 100 DNS lookups...
Progress: 10/100 lookups, found 9 unique IPs so far...
Progress: 20/100 lookups, found 9 unique IPs so far...
Progress: 30/100 lookups, found 9 unique IPs so far...
Progress: 40/100 lookups, found 9 unique IPs so far...
Progress: 50/100 lookups, found 9 unique IPs so far...
Progress: 60/100 lookups, found 9 unique IPs so far...
Progress: 70/100 lookups, found 9 unique IPs so far...
Progress: 80/100 lookups, found 9 unique IPs so far...
Progress: 90/100 lookups, found 9 unique IPs so far...
Progress: 100/100 lookups, found 9 unique IPs so far...
Querying NTP pool subzones...
Querying ph.pool.ntp.org...
Querying 0.ph.pool.ntp.org...
Querying 1.ph.pool.ntp.org...
Querying 2.ph.pool.ntp.org...
Querying 3.ph.pool.ntp.org...
=== Found 14 unique IP address(es) ===
222.127.1.18
222.127.1.19
222.127.1.20
222.127.1.21
222.127.1.22
222.127.1.23
222.127.1.24
222.127.1.25
222.127.1.26
222.127.1.27
2405:8d40:f27:cd00:3d0b:a6df:43f7:e7c9
2405:8d40:f27:cd00:6121:cf9a:aeb1:497b
2405:8d40:f27:cd00:7763:703:f43f:b01b
2405:8d40:f27:cd00:8efa:be7a:8162:55cd
=== Testing NTP servers (parallel) ===
Tested 10/14 servers...
Tested 14/14 servers...
=== Results ===
------------------------------------------------------------
222.127.1.18 : ✗ FAILED (Timeout)
222.127.1.19 : ✗ FAILED (Timeout)
222.127.1.20 : ✗ FAILED (Timeout)
222.127.1.21 : ✗ FAILED (Timeout)
222.127.1.22 : ✗ FAILED (Timeout)
222.127.1.23 : ✗ FAILED (Timeout)
222.127.1.24 : ✗ FAILED (Timeout)
222.127.1.25 : ✗ FAILED (Timeout)
222.127.1.26 : ✗ FAILED (Timeout)
222.127.1.27 : ✗ FAILED (Timeout)
2405:8d40:f27:cd00:3d0b:a6df:43f7:e7c9 : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2405:8d40:f27:cd00:6121:cf9a:aeb1:497b : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2405:8d40:f27:cd00:7763:703:f43f:b01b : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2405:8d40:f27:cd00:8efa:be7a:8162:55cd : ✗ FAILED ([Errno -9] Address family for hostname not supported)
------------------------------------------------------------
Summary: 0/14 servers responded successfully
Discovery methods:
- DNS lookups found: 9 IPs
- Subzone queries found: 12 IPs
The IPs provided are Globe, and I’m on Globe with a business connection. I’ve also tested from other PH ISP connections and get the same result.
Adding a test for us.pool.ntp.org from the same connection to demonstrate the issue further
$ /home/user/ntp_checker_enhanced.py
=== NTP Pool IP Discovery and Testing ===
Performing 100 DNS lookups...
Progress: 10/100 lookups, found 25 unique IPs so far...
Progress: 20/100 lookups, found 25 unique IPs so far...
Progress: 30/100 lookups, found 25 unique IPs so far...
Progress: 40/100 lookups, found 25 unique IPs so far...
Progress: 50/100 lookups, found 25 unique IPs so far...
Progress: 60/100 lookups, found 25 unique IPs so far...
Progress: 70/100 lookups, found 25 unique IPs so far...
Progress: 80/100 lookups, found 25 unique IPs so far...
Progress: 90/100 lookups, found 25 unique IPs so far...
Progress: 100/100 lookups, found 25 unique IPs so far...
Querying NTP pool subzones...
Querying us.pool.ntp.org...
Querying 0.us.pool.ntp.org...
Querying 1.us.pool.ntp.org...
Querying 2.us.pool.ntp.org...
Querying 3.us.pool.ntp.org...
=== Found 43 unique IP address(es) ===
104.131.139.195
104.167.215.195
104.233.211.205
108.61.215.221
129.146.193.200
141.11.228.173
142.202.190.19
144.202.0.197
144.202.41.38
158.51.99.19
162.159.200.123
172.234.37.140
173.208.172.164
198.137.202.32
198.137.202.56
208.67.72.43
208.67.75.242
209.51.161.238
216.229.0.50
217.180.209.214
23.111.186.186
23.149.208.12
23.150.41.123
23.168.24.210
23.186.168.123
23.186.168.125
23.186.168.131
23.95.49.216
2600:1700:5455:a70::7b:2
2604:a880:400:d0::83:2002
2620:138:5000:0:5054:ff:fe89:6673
2a01:4ff:1f0:c33f::1
44.190.5.123
45.55.58.103
45.77.126.122
45.84.199.136
50.218.103.254
50.53.75.227
51.81.209.232
64.246.132.14
69.89.207.99
73.65.80.137
96.231.54.40
=== Testing NTP servers (parallel) ===
Tested 10/43 servers...
Tested 20/43 servers...
Tested 30/43 servers...
Tested 40/43 servers...
Tested 43/43 servers...
=== Results ===
------------------------------------------------------------
104.131.139.195 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
104.167.215.195 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
104.233.211.205 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
108.61.215.221 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
129.146.193.200 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
141.11.228.173 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
142.202.190.19 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
144.202.0.197 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
144.202.41.38 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
158.51.99.19 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
162.159.200.123 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
172.234.37.140 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
173.208.172.164 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
198.137.202.32 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
198.137.202.56 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
208.67.72.43 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
208.67.75.242 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
209.51.161.238 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
216.229.0.50 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
217.180.209.214 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
23.111.186.186 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
23.149.208.12 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
23.150.41.123 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
23.168.24.210 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
23.186.168.123 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
23.186.168.125 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
23.186.168.131 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
23.95.49.216 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
2600:1700:5455:a70::7b:2 : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2604:a880:400:d0::83:2002 : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2620:138:5000:0:5054:ff:fe89:6673 : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2a01:4ff:1f0:c33f::1 : ✗ FAILED ([Errno -9] Address family for hostname not supported)
44.190.5.123 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
45.55.58.103 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
45.77.126.122 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
45.84.199.136 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
50.218.103.254 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
50.53.75.227 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
51.81.209.232 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
64.246.132.14 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
69.89.207.99 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
73.65.80.137 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
96.231.54.40 : ✓ SUCCESS (Thu Jun 5 20:31:15 2025)
------------------------------------------------------------
Summary: 39/43 servers responded successfully
Discovery methods:
- DNS lookups found: 25 IPs
- Subzone queries found: 23 IPs
Adding just pool.ntp.org which is the problem with a lot of defaults not having a failover, and vendor domains don’t help
$ /home/user/ntp_checker_enhanced.py
=== NTP Pool IP Discovery and Testing ===
Performing 100 DNS lookups...
Progress: 10/100 lookups, found 8 unique IPs so far...
Progress: 20/100 lookups, found 8 unique IPs so far...
Progress: 30/100 lookups, found 8 unique IPs so far...
Progress: 40/100 lookups, found 8 unique IPs so far...
Progress: 50/100 lookups, found 8 unique IPs so far...
Progress: 60/100 lookups, found 8 unique IPs so far...
Progress: 70/100 lookups, found 8 unique IPs so far...
Progress: 80/100 lookups, found 8 unique IPs so far...
Progress: 90/100 lookups, found 8 unique IPs so far...
Progress: 100/100 lookups, found 8 unique IPs so far...
Querying NTP pool subzones...
Querying pool.ntp.org...
Querying 0.pool.ntp.org...
Querying 1.pool.ntp.org...
Querying 2.pool.ntp.org...
Querying 3.pool.ntp.org...
=== Found 14 unique IP address(es) ===
222.127.1.18
222.127.1.19
222.127.1.20
222.127.1.21
222.127.1.22
222.127.1.23
222.127.1.24
222.127.1.25
222.127.1.26
222.127.1.27
2405:8d40:f27:cd00:3d0b:a6df:43f7:e7c9
2405:8d40:f27:cd00:6121:cf9a:aeb1:497b
2405:8d40:f27:cd00:7763:703:f43f:b01b
2405:8d40:f27:cd00:8efa:be7a:8162:55cd
=== Testing NTP servers (parallel) ===
Tested 10/14 servers...
Tested 14/14 servers...
=== Results ===
------------------------------------------------------------
222.127.1.18 : ✗ FAILED (Timeout)
222.127.1.19 : ✗ FAILED (Timeout)
222.127.1.20 : ✗ FAILED (Timeout)
222.127.1.21 : ✗ FAILED (Timeout)
222.127.1.22 : ✗ FAILED (Timeout)
222.127.1.23 : ✗ FAILED (Timeout)
222.127.1.24 : ✗ FAILED (Timeout)
222.127.1.25 : ✗ FAILED (Timeout)
222.127.1.26 : ✗ FAILED (Timeout)
222.127.1.27 : ✗ FAILED (Timeout)
2405:8d40:f27:cd00:3d0b:a6df:43f7:e7c9 : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2405:8d40:f27:cd00:6121:cf9a:aeb1:497b : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2405:8d40:f27:cd00:7763:703:f43f:b01b : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2405:8d40:f27:cd00:8efa:be7a:8162:55cd : ✗ FAILED ([Errno -9] Address family for hostname not supported)
------------------------------------------------------------
Summary: 0/14 servers responded successfully
Discovery methods:
- DNS lookups found: 8 IPs
- Subzone queries found: 12 IPs
Vendor specific test
$ ./ntp_checker_enhanced.py
=== NTP Pool IP Discovery and Testing ===
Performing 100 DNS lookups...
Progress: 10/100 lookups, found 9 unique IPs so far...
Progress: 20/100 lookups, found 9 unique IPs so far...
Progress: 30/100 lookups, found 9 unique IPs so far...
Progress: 40/100 lookups, found 9 unique IPs so far...
Progress: 50/100 lookups, found 9 unique IPs so far...
Progress: 60/100 lookups, found 9 unique IPs so far...
Progress: 70/100 lookups, found 9 unique IPs so far...
Progress: 80/100 lookups, found 9 unique IPs so far...
Progress: 90/100 lookups, found 9 unique IPs so far...
Progress: 100/100 lookups, found 9 unique IPs so far...
Querying NTP pool subzones...
Querying openwrt.pool.ntp.org...
Querying 0.openwrt.pool.ntp.org...
Querying 1.openwrt.pool.ntp.org...
Querying 2.openwrt.pool.ntp.org...
Querying 3.openwrt.pool.ntp.org...
=== Found 14 unique IP address(es) ===
222.127.1.18
222.127.1.19
222.127.1.20
222.127.1.21
222.127.1.22
222.127.1.23
222.127.1.24
222.127.1.25
222.127.1.26
222.127.1.27
2405:8d40:f27:cd00:3d0b:a6df:43f7:e7c9
2405:8d40:f27:cd00:6121:cf9a:aeb1:497b
2405:8d40:f27:cd00:7763:703:f43f:b01b
2405:8d40:f27:cd00:8efa:be7a:8162:55cd
=== Testing NTP servers (parallel) ===
Tested 10/14 servers...
Tested 14/14 servers...
=== Results ===
------------------------------------------------------------
222.127.1.18 : ✗ FAILED (Timeout)
222.127.1.19 : ✗ FAILED (Timeout)
222.127.1.20 : ✗ FAILED (Timeout)
222.127.1.21 : ✗ FAILED (Timeout)
222.127.1.22 : ✗ FAILED (Timeout)
222.127.1.23 : ✗ FAILED (Timeout)
222.127.1.24 : ✗ FAILED (Timeout)
222.127.1.25 : ✗ FAILED (Timeout)
222.127.1.26 : ✗ FAILED (Timeout)
222.127.1.27 : ✗ FAILED (Timeout)
2405:8d40:f27:cd00:3d0b:a6df:43f7:e7c9 : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2405:8d40:f27:cd00:6121:cf9a:aeb1:497b : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2405:8d40:f27:cd00:7763:703:f43f:b01b : ✗ FAILED ([Errno -9] Address family for hostname not supported)
2405:8d40:f27:cd00:8efa:be7a:8162:55cd : ✗ FAILED ([Errno -9] Address family for hostname not supported)
------------------------------------------------------------
Summary: 0/14 servers responded successfully
Discovery methods:
- DNS lookups found: 9 IPs
- Subzone queries found: 13 IPs
Thanks for checking. The main point here is that source IP used for the queries was from the Philippines. It is clear that there is special configuration on the server side, because some of the monitoring instants are allowed to query. Only the NTP server admin or a pool admin can do something to fix the issue.
The ten server are under one account from a big car company verified and netspeed set to 12. I’ve mailed them to take a look here.
Also Cloudflare is now supporting the PH Zone.
Great, thanks!
For IPv4, those now have a netspeed share of about 49.4% each, while most of the pre-existing servers dropped from an average of around 12% (with one at only 1.7%) to around 0.123% (and 0.0185%, respectively).
Though given the low total number of servers in the zone, the relief for other servers is probably not going to be as much as those numbers might suggest, given that the DNS responses will always have a discrete number of IP addresses in them. I.e., four for pool.ntp.org, and three for the numbered zones (up from two before the Cloudflare servers were added).
I.e., the Cloudflare servers will be in pretty much every response for pool.ntp.org, and the other 10 current servers will take turns for the other two slots in the responses. And for the numbered zones, some of them will still have only IP addresses from the pre-existing servers in them, owing to the zone generation algorithm trying to avoid that an IP address appears in more than one numbered zone.
But let’s see what the DNS statistics will say after a few days.
I still think tech companies, vendors, universities, ISPs and so on should be informed that the area is underserved and needs to be pushed. Spread the word!
Thanks to Cloudflare for their servers! But what would happen if they didn’t do that anymore?
What about vendors who use the pool, especially those who have also registered a zone (all for free)? Why don’t they provide a server? Is that so expensive?
Sorry… Just my two cents.
The pool itself also could improve the situation by finally addressing the underserved zone topic, e.g., based on any of the many ideas that are on the table, or a combination thereof, and by following through on improvement plans that had been envisioned/announced already a while ago. I am not going to re-iterate all of the ideas and plans for the nth time, just look through the forum, relevant threads tend to be among the more voluminous ones… I.e., there is no shortage of ideas how to address the issue.
More help from the community would need to be enlisted to free Ask from many routine tasks so he can focus the very little time he has available for the project on development work. Or even induct a few very trusted people to work on the implementation under Ask’s guidance. I’d think there would be enough volunteers who would be happy to chip in. Some people have expressed willingness already, I’d expect more to come forward when a call were made.
Looking back through my csv records it looks like Cloudflare were in the PH zone back in March.
filename:time_stamp,location_of_request,dns_server_used,hostname_asked_for,ip_address_returned,round_trip_time_ms
2025-03-27-pool-dns.csv:1743066135,ph-mnl-l1,8.8.8.8,pool.ntp.org,162.159.200.1,1
2025-03-28-pool-dns.csv:1743132197,ph-mnl-l1,8.8.8.8,pool.ntp.org,162.159.200.123,1
2025-03-28-pool-dns.csv:1743132197,ph-mnl-l1,8.8.8.8,pool.ntp.org,162.159.200.1,1
2025-03-28-pool-dns.csv:1743134555,ph-mnl-l1,8.8.8.8,pool.ntp.org,162.159.200.123,1
2025-03-28-pool-dns.csv:1743134555,ph-mnl-l1,8.8.8.8,pool.ntp.org,162.159.200.1,1
2025-03-30-pool-dns.csv:1743295357,ph-mnl-l1,1.1.1.1,pool.ntp.org,162.159.200.1,2
2025-03-30-pool-dns.csv:1743295357,ph-mnl-l1,1.1.1.1,pool.ntp.org,162.159.200.123,2
2025-03-30-pool-dns.csv:1743296547,ph-mnl-l1,1.1.1.1,pool.ntp.org,162.159.200.123,2
2025-03-30-pool-dns.csv:1743296547,ph-mnl-l1,1.1.1.1,pool.ntp.org,162.159.200.1,2
Also it looks like there have been quite a few servers added in the last few days so I will try and add one as before and hoping it does not get flooded. Spreading the load across many should help.
Could you ask them again? It seems the situation is still the same, ie. those 10 servers are largely unreachable from the rest of the world. For example, my own NTP server in the Philippines is unable to use any of those 10 NTP servers.
Just tested and they work for me:
bas@workstation:~$ nslookup ph.pool.ntp.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: ph.pool.ntp.org
Address: 58.71.12.13
Name: ph.pool.ntp.org
Address: 162.159.200.123
Name: ph.pool.ntp.org
Address: 162.159.200.1
Name: ph.pool.ntp.org
Address: 45.115.225.48
bas@workstation:~$ ntpdate 58.71.12.13
2026-08-21 17:28:28.485567 (+0200) -0.004231 +/- 0.164274 58.71.12.13 s2 no-leap
bas@workstation:~$ ntpdate 162.159.200.123
2026-08-21 17:28:38.958730 (+0200) +0.001351 +/- 0.006721 162.159.200.123 s3 no-leap
First is cloudflare, but the second:
bas@workstation:~$ nslookup 58.71.12.13
13.12.71.58.in-addr.arpa name = fw2-pldt.vsu.edu.ph.
so tested another:
bas@workstation:~$ nslookup 45.115.225.48
48.225.115.45.in-addr.arpa name = puhveli.miuku.net.
bas@workstation:~$ ntpdate 45.115.225.48
2026-08-21 17:31:35.404991 (+0200) -0.020564 +/- 0.118545 45.115.225.48 s4 no-leap
Works for me…
The puhveli one is mine. I’m glad it’s working for you. However, this topic and my message was about a specific set of 10 NTP servers:
https://www.ntppool.org/scores/222.127.1.18
https://www.ntppool.org/scores/222.127.1.19
https://www.ntppool.org/scores/222.127.1.20
https://www.ntppool.org/scores/222.127.1.21
https://www.ntppool.org/scores/222.127.1.22
https://www.ntppool.org/scores/222.127.1.23
https://www.ntppool.org/scores/222.127.1.24
https://www.ntppool.org/scores/222.127.1.25
https://www.ntppool.org/scores/222.127.1.26
https://www.ntppool.org/scores/222.127.1.27
Feel free to repeat your test for those, but whether those Philippine NTP servers respond to queries from a host in Belgium or not is not going to bring much more useful information into this discussion. As you can see from the score pages, those servers are largely unreachable globally.
This leads into a question: should the pool tolerate for server blocking networks? IMHO blocking large networks inside belonging cc zone is unacceptable, but in current monitoring algorithm and scenario it may be hard to verify.
I tested the first 3 of them, all of them giving this:
Belgium:
bas@workstation:~$ ntpdate 222.127.1.18
ntpdig: no eligible servers
Germany and France, same response.
Tested on other servers to see if a country matters.
And I agree, blocking servers should be excluded from the pool.
Not really, because if many monitors are unable to score, it should be removed.
As you can see only few monitors can score it, but the majority can’t.
So the monitor system could conclude it’s a blocking server and email the owner that it may be banned. To resolve the matter. As it’s not 1 monitor that shows -100, but almost all of them.
What is many? one-third or one-fourth? Back in the years when I first knew and joined NTP Pool Project, many east Asian zones like tw,hk and cn only had a handful of servers. Unable to handle the load, I did consider extreme ways including block all IPs outside tw to fight the load (HINT: admin cannot disable/un-join continental zone in any way)… Maybe that’s the same reason why this admin blocked a lot of networks. However accessible by clients in the same country zone is my bottom line.
That is not the point, they are listed as Global.
So typical 80% of the monitors should be able to reach it, probably 99%.
If you look at it, they deliberately block everything but their needed monitors to be listed.
Sorry but it should not be listed as Global. For me this is abuse of the system.
Because if they exclude everything outside .PH it wouldn’t be listed, yet they allow German monitors.
But if I check my German server:
~# ntpdate 222.127.1.18
ntpdig: no eligible servers
So it’s allowing only monitors to be listed, nothing else.
Hint: (HINT: admin cannot disable/un-join continental zone in any way) - Yes you can!
Actually, they can. Just send an e-mail to server-owner-help@ntppool.org, and it’ll be taken care of for you.
Actually, in many (not all) overloaded zones, the inverse is true. The country zone generates too much traffic, thus remove it and serve only the continent zone. I have multiple servers set up like that, e.g., in Vietnam. Serves traffic at the 120 Mbit net speed/netspeed setting without issue where 256 kbit net speed/netspeed was not doable for my server with the VN zone enabled, even without the Asia zone. Also allowed me to rejoin a server normally in the MY zone, but where 256 kbit still generated too much traffic so that I previously had to take it out of the pool entirely.
Also works in the North America zone, e.g., when monthly traffic volume is too low for higher net speeds/netspeeds (though the situation, e.g., in the US zone is not as bad as in some in Asia, i.e., net speeds/netspeeds down to 256 kbit typically reduce the traffic sufficiently even for a monthly traffic quota of only 25 GB).
But Taiwan indeed seems to be a zone where this doesn’t work, had to have the Asia zone removed from one of my servers.
There’s essentially no clients in the “@” zone, one almost doesn’t even notice the difference between a server being in the “@” zone only (no country and no continent zone), and the server being in “monitoring only”. I know this is against the prevalent view in this forum, and many people won’t believe it. But it’s what the theory says when one really grasps how the geo-targeting actually works (specifically the fallback part). And preliminary results of a test I am currently running support that.