Achim Gratz writes:
The thing to note is that you need to boot with "nohz=off",
Tom was asking what that kernel parameter meant and does.
UNIX used to have a fixed frequency interrupt called TICK that would do
its thing HZ times per second (typically HZ=100, but later on HZ=1000 on
some systems). Without going to deep into the details, many powqer
saving features don't really work if you wake up the CPU too often, so
something called a "tickless" Linux kernel was developed and the config
switch to use it is CONFIG_NO_HZ. The tick interrupt is still there in
such a kernel, but it can be suppressed in order to save power. The
kernel poarameter "nohz=off" tells the kernel to not use this facility
and hence faithfully run a kernel interrupt for each TICK. It also
prevents the kernel from shifting the deadlines of other kernel timers
in order to create "bunches" of work, which is what I needed in this
case.
Just one reference, you can dive in from there if you need to know more:
https://stackoverflow.com/questions/9775042/how-nohz-on-affects-do-timer-in-linux-kernel
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Hi
One of the gotcha’s with “cell phone” based timing is discovering that the provider
has been a bit lax about making sure the time stamp on the signal is what it should
be. The problem is less common with 800 MHz CDMA than other bands / services.
One of the reasons we see a lot of this sort of gear on the secondary market is that
… errr …. they had problems …. ( = trust but verify ….)
Bob
On Jul 22, 2019, at 7:38 PM, K5ROE Mike K5ROE@roetto.org wrote:
You may want to look at something an Endrun CDMA ntpserver for the datacenter; don't need view of the sky. Available on the used market sub $1k
Standard solution for this scenario.
K5ROE Mike
On 7/22/19 10:50 AM, wildylion via time-nuts wrote:
Yeah, of course I will NOT do anything home-grown for the datacenter.
But currently it uses 3 Stratum 2 NTP servers, one per DC, with them referencing a list of 4 close-by Stratum 1 sources.
ntpstat generally says that time is correct within ~50 ms, while jitter and offset generally don't exceed 1ms, the root dispersion is quite large.
Also these Stratum 2 NTPs are run from Cisco routers, which I doubt are very good at timekeeping.
When I implemented this scheme, I offered to have S2 on a set of x86 servers, but was overruled by management who said it'll be better if we run S2's off Cisco gear.
So what if we add a couple GPSDO's into the mix, using them as primary time sources alongside public Stratum1 NTP servers for sanity check? And of course moving the S2's to something more stable.
My own, homegrown S1 pool NTP is another matter entirely - I think just a tuned Raspi with a M8N will be enough?
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, 22 July 2019 г., 17:38, Taka Kamiya tkamiya9@yahoo.com wrote:
If you have 100 production servers with database, I am going to strongly discourage you from taking a "home grown" route. You will need multiple redundant implementation with fail-over. You mentioned budget. How much are your bosses willing to pay for consultation fees for failed or corrupted data? I am assuming you are talking about Oracle RDBMS with minimum of 2 way RAC.
If you are using collocation services, doesn't the center itself offer ntp service for fee?
If you need 24 hour hold-over, I will take nothing less than multiple ovenized crystal OSC GPSDO with redundancy per center. Then feed that into ntp server with multi-location fail over.
If I were responsible for managing such system and if my boss will want me to go cheap route, I will seriously fight it. If it's successful, your boss will get credit for spending little and getting a big benefit. WHEN it fails, it's going to be your fault for not mitigating risk sufficiently. Try pricing out 2 days of consulting fees....
(Mr.) Taka Kamiya
KB4EMF / ex JF2DKG
On Monday, July 22, 2019, 10:05:56 AM EDT, wildylion via time-nuts time-nuts@lists.febo.com wrote:
Hello there,
I wanted to ask for advice regarding NTP
Situation 1:
What I currently have is a uBlox M8N GPS puck I'm planning to use with the Raspberry PI. Seems like it should work almost out of the box with some kernel tuning, but I have a question about short term stability in the event of GPS loss - how well will the board hold over if it's lost GPS for, say, 24 hours?
Situation 2:
Also, there's a need for more dependable NTP time sources for our colocated spaces.
What we have is about 100 servers, some of them running DBMS that wouldn't like clock drift at all. After a recent incident involving NTP I've got an idea to install GPSDO time servers in each datacenter and slave them to stratum2's that will be actually distributing time to clients.
All the certified GNSS disciplined clocks are really expensive (way more than the management would approve), so what I'm planning to do is possibly getting a couple LeoNTP units and using them as the root time sources, would this be a good plan? Of course, all the NTP infrastructure will be monitored, and possibly we'll use Stratum 2 servers which would be slaved to GPSDO S1's AND the public NTP pool for sanity checks.
Maybe BG7TBL's units instead of LeoNTP?
Is that a good idea?
Sent with ProtonMail Secure Email.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.