Well you all decide where this vps needs placed. I think it will be able to handle about 15k a second but that’s a guess but I need to test loads. I understand from the thread China is seeing large load that is why I started it out at 10mbit and will test load averages once the score is prime for usage and take deletions into consideration by at least half. It needs to be a taken out of global and Asia zones though.
Thanks for your contribution… I think you need to turn the speed down to the minimum and then slowly increase it. I think that a 10Mbps setting will push it out very fast.
Not 100%, but a couple of times when .cn crashed I saw that the information on the website regarding .cn changed from x.cn.pool.ntp.org to x.asia.pool.ntp.org, so I am under the impression that the DNS is configured with the same behavior as well.
Hi, I want help to do something, plz add it to CN pool
https://www.ntppool.org/scores/176.9.100.107
Both you and avij argue from a perception that there is enough resources in the .cn pool and that we can just tune our equipment. This is not the case. The resources are being pushed out faster then they enter.
I have previously asked for special consideration or tuning if you will. Not for me, Leo or other individuals, but for the .cn zone in general while the long term solution is being finalized. The tuning would hopefully also allow more of the local Chinese ntp servers to actually stay in the pool as well.
2 Likes
OK, Paul, I’ve had enough of this… I have donated almost a Petabyte of traffic most of which got sunk into .cn If I was demanding anything, it was to stop preventing me to donate more traffic but this does not seem to be working and turning personal. “Run by volunteers” just means “monitoring remained dysfunctional for years and will probably remain so for foreseeable future.”
For the last time I’ll say it again - the biggest problem of ntppool is its broken monitoring.
Pool admins, please remove 85.199.214.100 and 85.199.214.101 from .cn zone.
Good luck and goodbye.
Leo Bodnar
@LeoBodnar
I completely understand your frustation with the current situation. I just want to say thank you for for your invaluable contributions over the last year
It will be more than difficult to maintain any kind of service in .cn without your 200Mbps of capacity and I fear we will fail seconds after your hosts are removed.
1 Like
Some people insisted that every pool server must attain 100% availability or they should be removed or degraded to lower bandwidth. I understand this point, as SNTP clients will not query multiple servers, and we all hope that clients can get the time when querying. But this is NOT the case when servers for a given zone drops ≦ 4. At this point the bandwidth setting is useless and every server receives at least 25% of total traffic. Therefore server volunteers can not do anything to reduce the incoming traffic and prevent overloading, and removing any server from the roster will further burden the other also heavy loaded ones. And new volunteers can hardly survive this packet storming with ordinary equipment, like the 20+ international servers joining cn zone showed. This is total collapse of a zone, happened everyday in Asia and other less developed continents.
If you can not help, then at least please do not blamestorm the one who are willing to help.
As an Asian volunteer, I must repeat my suggestions:
- Enable IPv6 reply right now, at least in selected underserved by IPv4 zones. One more client querying IPv6 server means one less client querying IPv4 server. In Europe you have many servers to choose from; but in Asia we must utilize every servers to survive the packet storm.
==Below needs some code work thus not in first priority== - Provide total amount of registered bandwidth of a given zone in the management page, as an indication showing in what proportion one server will receive the total traffic. 384kbps out of 3840kbps (384kbps * 10) is very different to 384kbps out of 9000384kbps (1000Mbps * 9 + 384kbps).
- Also, provide some easy way to join in and out of zones, like a textbox to edit ccTLD entries. Admins’ human workhours shall be devoted to coding and infrastructure management, not in these general affairs.
6 Likes
Switched to 384kbit while the score is only hovering sub 10 around 9 it may have been due to load last night. It is morning time and if you give me a little while I will look into things.
Noah
Minor point: I’m not aware of anyone in this thread suggesting that, and certainly the monitoring system doesn’t require that. Anything with a score over 10 is included.
…
Excellent suggestions, and I would be willing to help develop/test these. I’ll have a poke at @ask’s repo when I get a chance and see how hard they would be to implement.
Thanks @paulgear for clarification. Your message saved me from some typing.
I believe Leo might have an incentive to show that his NTP server equipment can handle the full 100Mbps line capacity. Yes, we have seen that it can do that, mission accomplished, great. Take a screenshot as an evidence, publish it somewhere for others to see and then, maybe, think of all this from the NTP Pool and its users’ point of view.
When someone queries the pool, they generally expect a response. If the query gets directed to a server which can’t handle the query, that’s bad. I think some of you guys are barking at the wrong tree. The monitoring server is doing its job just fine. If despite all tunables that you can tune the servers get too much traffic, that traffic should be spread to a larger area. That is not the monitoring server’s job, but it’s still within the NTP Pool’s problem area.
Now some maths. Based on the CSV log the score of 85.199.214.100 was >= 10 around 45% of the time. If the server can serve 400 million requests per hour when it’s in the pool and maybe 200 million requests per hour when it’s out (based on the above graphs that Leo posted), you will end up handling 24 * ( 0.45 * 400 + 0.55 * 200 ) = 6960 million requests each day. That’s quite a lot already, I might add. These might not be exact figures, but please bear with me.
Now if you tried to follow my suggestion to try to keep the traffic below the 100Mbit line speed to better keep its score >= 10, the daily amount of traffic served by your server might actually increase. If after this change your server was included in the pool for 95% of the time, you would reach the same amount of daily traffic with only an average of 295 million queries per hour (6960 - 200 * 24 * 0.05) / (24 * 0.95). The 200 in that calculation is the amount of hourly traffic while out of the pool, same as in the previous calculation. That way you would not drop as much packets as before, and you would still serve the same amount of daily traffic. If you manage to tweak the netspeed settings so that you’d actually send more than that without hitting your line speed, say, at 350M responses per hour, that’d be even better for the pool.
I’d also like to point out that at this particular moment the netspeed setting is indeed effective. One of my servers (set to 384kbps) that serves exclusively the .cn zone currently pushes out packets at an average of around 30k qps (averaged over the last 14 hours), with 5 min peaks of around 65k qps. That is easily within the limits of a 100Mbps connection, so you can stay under 100Mbps if you want. It’s up to you, the tunables are there for you.
Edit 1 + 2: fixed/refined maths, sorry.
Currently I am seeing a load average of .17 and ntp utilization of 15%. ‘time tcpdump -n port 123’ caught 69057 relevant packets in 9.655 seconds and half of those are responses so 69057 / 2 / 9.6 is 3596 queries a second. Multiply that by 48 bytes per request and divide by 1024 for KiByte and it comes to about 168 KiByte a second. This should suffice for half a TiByte a month.
Current problems for this VPS instance: I just switched it to 384KiBit from from 10MiBit per suggestion and dont know if it will keep seeing enough requests yet. Also scores are 9.5 and 9.7. Maybe that had to do while it was at 10MiBit. I will keep checking up on this today.
Someone removed it from global which is good but it is also in Asia which I’m not sure if it should just be in HK.
It’s not much help and maybe in the future I can find and afford something unmetered.
Edits:
KiB Mem : 262144 total, 85984 free, 4920 used, 171240 buff/cache
KiB Swap: 262144 total, 257520 free, 4624 used. 164630 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
448 root 0 -20 25668 1880 1300 S 20.0 0.7 59:10.28 ntpd
Memory
172MB Used + Cached
256MB Total
My VPS portal says a little more than 3% of bandwidth has been utilized so this is pretty much right on schedule for a month since I also transfered a 100MiByte file from NJ/USA to test throughputs. Sad to say it will be difficult to park it right at these figures. IPv6 for tick.hk.china.logiplex.net is currently .5 above 10 while IPv4 is at 5 
I will watch the thread but be back in some hours to provide more detail at 384KiBit and out of the global zone.
Thanks,
Noah
If the netspeed setting is <= 512 kbps, the server won’t be in the global pool. This happens automatically.
Ok. I’d like to have it in HK only and possibly china if there is such a zone.
5.103.139.163 has been removed from the cn zone.
You just delivered the perfect argument why these settings doesnt work for the cn zone. You tell us that at the pools lowest setting you need a 60Mbps connection. This is equipment where no normal users can contribute to the pool.
Please move tick.hk.china.logiplex.net out of the Asia zone and into the cn zone and keep it in the hk zone.
Edit: I also provided some edits with more load and resource information above in my todays first post.
Thanks,
Noah
https://logiplex.net
I don’t disagree with the minimum de-facto speed requirement for .cn, I’m fully aware of the current situation.
@avij I see, I’m sorry. Well there are two choices. Let it eat up the monthly bandwidth and drop off during the month or keep it in hk at a higher rate.
Edit: maybe I read wrong but if you are seeing 30+ thousand packets a second at 384KiBit then my VPS will not be much help in the CN zone and I should just keep it probably at 384KiBit in Asia and HK zones. Maybe 512KiBit I will check back later.
Noah
For those who might need this: I have two servers in the .cn pool, but their monthly bandwidth quota is 4TB for each. To make sure I don’t exceed the quota I need to throttle the traffic somehow. I do this by blocking probes from the monitoring server’s netblocks. I don’t block the traffic originating from elsewhere. The scripts I use are available at http://miuku.net/ntp/limit-speed.html
Hopefully this helps someone.