Thank you very much.
I do not approve of any war. And it’s not only Russia…
As this system isn’t about war, it should not affect the system.
It’s about time-keeping, and I do thank you for sticking to English.
As such, we ALL should refrain from problems in the world and stick to helping normal people getting their computers on time.
That is what this pool is about.
Please people, we are about timekeeping…act as such! Thank you.
+1. If somebody thinks that we are very happy of some stuff that happens - we are not.
Pool is great. Let’s make the time go on, because who if not we!
I am going to sleep. See you tomorrow.
Leave politics, war etc out of it…WE USE ENGLISH and help all that want to keep time correct for the world.
PLEASE STOP IT…it’s time…and time we trust…
Time is universal, regardless anything…we keep time…stick to it.
All the rest is BULLSHIT! The pool is time, and time alone…deal with it.
Thank you, @Bas. Let’s keep that #*it out of here.
Time must go on! That matters. Nothing else.
This post is entirely repetitive of another very recent post of yours. Please do not shout with capitals and please do not post the same things repetitively. It just makes it less likely @Ask or other participants will wade through such a ridiculously long thread, and annoys the rest of us with the wasted time reading your duplicate post.
We see time problems for users in Russia, China and others.
The thing is, how do we fix it for the people?
Time should be as normal to get as internet, water or food.
It should be universal available to everybody.
Dave are you again trying to pick a fight with me? As you are not a nice person.
Like yours.
1vCPU 2GB Ram.
The system struggles later on high cpu load of ntpd / chrony and softirq which was handling the network stuff.
You - cannot help from abroad (and you hardly should). We should do that, so this thread may be used for coordination of people that are willing to un-sink a sunk ship, make some patches at the holes, drain water out and raise the sails with ‘yo-ho-ho, we did that!’
And what net speed does it have?
From the evidence gathered here, such as it all starting at one point in time, going from normal traffic to extreme overload of many .ru.pool.ntp.org servers at once, I’m more and more convinced the root of the problem is a DDoS targeting ru.pool.ntp.org and/or its subzones (1, 2, 3, 4).
Keep in mind that a DDoS means the IP addresses sourcing the floods are likely not belonging to the attacker, but are compromised devices (routers and/or hosts) that are under control the person(s) behind the likely-politically-motivated attack. If you are reporting abusive IP addresses to the responsible ISP (via lookup of the AS number of the IP) you should probably mention that the attack is part of a widespread DDoS so the ISP’s client is probably not an attacker, but has compromised device(s).
I’m far from a fan of Russia under Putin, though I have no problem with the Russian people, but I am opposed to vigilante tech warfare by anyone anywhere. Leave it to the combatants and their allies, both sides have extensive internet warfare capabilities which will operate strategically to have the most useful effect. Vigilante actions could well be counterproductive due to timing or other reasons. For example, Ukraine and their allies might want to throw off NTP service (either by shifting time or denying all pool service) timed to enable some other action to be more effective.
I think the kernel would use a second CPU and that might greatly accelerate the network stack.
I parsed a log of 10M NTP packets gathered from my home in a few minutes.
It does not look as abuse. Packet rates are relatively high, but the addresses may be NAT of ISPs hiding thousands of clients under the hood.
4093 185.108.19.x
3098 212.33.240.x
2945 171.22.215.x
2384 185.108.19.x
1735 81.23.13.x
1555 185.108.19.x
1532 91.195.204.x
1448 91.195.204.x
1441 91.195.204.x
1416 185.108.19.x
Is 212.33.240.x 212.33.240.169? If yes, then I have many abuse entries.
Yes, 169. Maybe should write complaints to these network’ admins.
A second or third or fourth CPU won’t make much difference with a single-threaded server. When the server sends, the same CPU goes down into to the kernel and does the network stack work to send the packet. When it receives, whichever CPU services the interrupt from the network interface does the network stack work and is likely to come back up into the server process to handle the packet. Yes, there are opportunities for more than one CPU to be involved such as the NTP server replying on one processor to a previous packet while another handles an interrupt from the network interface, but with the interrupt coalescing usually enabled in the network driver, a busy server won’t be intrerrupting on every packet. Much of the processing is limited to one or two "CPU"s (cores/hyperthreads) so the modern systems which usually have at least 4 cores can benefit from @mlichvar’s multithreaded NTP front end when under heavy load.
I think the real solution to the overloading is sadly down to playing whack-a-mole with compromised IP addresses or convincing the vigilante cyberwarriors their attack is misguided, unless @Ask makes changes to the monitoring to be much more liberal with keeping overloaded .ru.pool.ntp.org servers in the pool so the zone doesn’t collapse so easily under DDoS. That would not be trivial as he would need to add geolocation lookup to the monitoring code, and special-case the scoring for affected zones. It might be useful for other country zones like China and the Phillipines, too.
I doubt he would spend cycles on that type of work, though, as he has been working on a more general project to make the per-country zones behave like the global or continental zones to address the collapse issue and generally provide clients with a better server selection, and would probably focus on that work over a band-aid hack to certain country zones.
Tss, guys, slow down. We are speaking about time.
I do not mind if you want to discuss political stuff, but please open another (politically motivated) thread, and leave this thread for pure technical things.
I’m not the one starting it.
You have the wrong person.
Dave is doing this over and over again.
Target him please. He’s the one bringing it up over and over again.
Did you miss he’s dong this?
Please take your personal issues to private messages. Enough of this.
To keep this post more on-topic, here are some statistics for kkursor’s new NTP servers, as observed from .fi:
Dave, I opened another thread, the topic is how to regulate the load of an NTP server? An NTP server should never receive load bigger, than his owner predefined. Not even if there is not enough capacity in the pool. If we make the theoretical experiment that everybody puts his/her server in ‘test only’ mode except one, even that single server should not receive more NTP requests. The pool code should scale well to that edge case, giving DNS answers containing no IP addresses.
My small VM (1vCPU) passed score 10 and it seems that it survives with netspeed 512k.