hello everyone.
I have a VPS server in China with an upstream bandwidth of 3Mbps. But the traffic in the Chinese pool is too large. Even with the minimum limit set, it is still several times my available bandwidth. I had to set it to ‘monitor only’ mode. I am unable to add the server to the pool.
Discussion related to this thread:
But can I use my server as a monitoring server for the China region? Due to the possibility that cross-border network connectivity may not always be ideal, I have another NTP server（ pool.ntp.org: Statistics for 47.92.198.198 ）Most of the monitors used to monitor it are in Europe or North America - network transmission requires crossing half the globe!
My server is located in the Alibaba Cloud Beijing data center, with a good network environment (Alibaba Cloud can connect to multiple operators through line connections). At the same time, my server remains idle throughout the year, and the average CPU utilization is very low. So I want to know if it can be used as a monitoring server, maybe to improve the score of other NTP servers in China.
I am trying to provide support@ntppool.org Sent an email, but the system prompts that this email address does not exist:
Mx.google.com refuses to send your email to the following email address:
support@ntppool.org ( support@ntppool.org )
The email sending address cannot be found in the target domain. This may be a spelling error in the address or the address does not exist. Please try to solve the problem by performing one or more of the following actions:
I want to ask: Who should I contact? Are there any additional requirements as a monitoring server?
thanks！
I’m not sure if 47.92.198.198’s problems can be directly attributed to poor international connectivity. It could also be something else.
But as you have your other server, it might be interesting to see if there is packet loss between those two servers. When you ping 47.92.198.198 from your 3Mbps VPS server, do you see packet loss? When I ping 47.92.198.198 from various places around the world, I see 20-40% packet loss. This correlates with the results of the NTP monitors.
Based on recent discussions, I have some educated speculation to offer.
I think it is misleading to label the root cause as “poor international connectivity”. China is not some tiny island nation in the middle of the Pacific. There is enormous internet connectivity across China’s borders. There’s more to the story, and it’s specific to China. Whether it’s Great Firewall or enforcing the subsidization of way-below-cost residential internet with extremely-over-cost commercial internet, it’s entirely unlike the experiences of the rest of the global internet.
In almost all of the rest of the world, borders are meaningless to the internet experience. For NTP particularly, what matters most is the jitter, or variability of latency. Obviously packet loss leads to extreme jitter.
I speculate the pool administrators are very selective in choosing monitors, as they are crucial to the quality of pool service seen by users. I believe they vet potential monitor operators by looking at the performance of pool servers as seen by the existing pool monitors.
This suggests the paucity of pool monitors in China is blocked by a chicken-and-egg problem. Potential monitor operators (except those with very deep pockets and very altruistic intentions) cannot demonstrate the desired combination of elements that lead to good NTP service and monitoring because their systems have miserable connectivity outside China, in terms of stable low jitter.
Now that the server’s score dropped below 10 and it’s no longer in the pool, the server seems to respond to pings just fine. This does not point to problems with international connections, but it’s probably something closer to the server itself. Maybe it’s the server, maybe it’s the ISP.
Let’s check the basics first. Do you see anything in “dmesg” output about dropped packets? Or /var/log/messages? Does “conntrack -L” show a long list of IP addresses sending packets to port 123? See also this post about connection tracking.
Besides that, it looks like 47.92.198.198’s netspeed setting could be set lower. I’m not sure what the netspeed has been set to at the moment, but looks like it is currently at least 12 Mbit/s. Try the lowest 512 Kbit/s setting first and observe the results.
Ah, my server (IP: 47.92.198.198/) uses shared 200MB bandwidth, which means it cannot provide stable bandwidth during peak hours.
What host do I want to use for monitoring pool.ntp.org: Statistics for 123.57.221.61 The network performance of this host is good most of the time, but I am unable to add it to the pool. After joining the pool, the DDOS cleaning of the cloud service provider will be automatically triggered in an instant due to the inflow of traffic far exceeding the protocol limit. So I only set it to ‘monitor only’ mode. I want to use this server as a monitoring server, which may provide better monitoring results for other NTP servers within China
I think it may be due to the QoS strategy of the service provider during peak hours. Although China has a large number of cross-border Internet connections, China also has a huge number of Internet users. According to the information I found, the total export bandwidth of China is only 13Tbps (which may not be accurate), and there is still a large amount of bandwidth that needs to be reserved for enterprises or high priority businesses. As NTP packets are UDP packets, I believe they are easily dropped by routers during peak periods, resulting in some monitoring stations being unable to connect.
Of course, this is just my guess, please correct any shortcomings.
My opinion is that deploying a monitoring site on servers within China may improve this situation (perhaps…?)
Elsewhere in recent discussions here someone mentioned you can set the level of participation to any arbitrary number, not just the offered choices like “monitoring only”, 1 Mbps, 10 Mbps, 25 Mbps, etcetera. Apparently you just need to use a wee bit of cleverness to figure out how the choices offered translate to the request sent back and put in your own numbers. If 1 Mbps (or whatever the lowest choice offered) is too much, try 1/10th as much. If still invoking packet loss (or as you put it “DDOS cleaning”), try 1/100th, and so on. With just a bit of persistence you should be able to get your server participating at a level where it won’t trip your provider’s packet rate limiting.
You are mistaken in assuming it is common practice to drop UDP traffic more than TCP or other protocols when circuits fill. Depending on the positioning, common practice is to either queue or drop packets without categorization. If you think UDP and TCP are the only IP protocols you’re also mistaken.
Yes, I understood which server you wanted to use for monitoring. I just felt that the other server you have might suffer from problems that you could fix yourself. Could you please check anyway? Try running “conntrack -L | grep port=123”. If it shows hundreds of entries, your server is doing connection tracking. Connection tracking may cause issues for busy NTP servers. If the conntrack command is not available, you may need to install the conntrack-tools package or similar.
In addition, my recommendation to set the server’s netspeed to the lowest setting (512 Kbit/s) still holds. Your server’s zones are currently listed as “@ asia cn”. Servers get assigned to the global @ zone only if their netspeed setting is at 12 Mbit/s or more. From the point of view of a NTP pool client, it’s better if your server can handle 100% of one million requests than 50% of two million requests, and your server doesn’t seem to be handling the higher load at the moment.
As long as I used connection tracking, I also had problems with my server. It started dropping packets as soon as the connections filled up the tracking table. I recommend completely disabling connection tracking for NTP packets.