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
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
wildylion via time-nuts writes:
> The point is: do we ever need S1 NTPs? I think, this could be a nice
> addition if properly realized, but right now I'm not sure if I can
> propose it.
You really can't properly monitor any stratum-2 sources you have
configured if you don't have your own
US operators are planning to shut down their CDMA networks. See for example
https://www.fiercewireless.com/wireless/verizon-to-shut-down-2g-cdma-1x-network-by-end-2019
I wouldn't be surprised to see this date get pushed back though.
On Mon, Jul 22, 2019 at 8:05 PM K5ROE Mike wrote:
> You
do well in
holdover situations for example).
Kind Regards,
Peter Membrey
- Original Message -
From: "Luiz Paulo Damaceno"
To: "wildylion" , "Discussion of precise time and
frequency measurement"
Sent: Tuesday, 23 July, 2019 01:31:34
Subject: Re: [time-nuts] No
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
Alright, I agree.
The point is: do we ever need S1 NTPs? I think, this could be a nice addition
if properly realized, but right now I'm not sure if I can propose it.
Anyway, going to plan moving these NTPs from the Cisco gear (where they didn't
belong from the start, anyway).
Sent with
On 7/22/19 07:50, wildylion via time-nuts wrote:
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.
Will you have access to a good location for the
On 7/22/19 11:52, Achim Gratz wrote:
Well, I have jitter (PPS timestamps) within ~2µs and the occasional
"hair" that goes out to about 30µs. The distribution is a little bit
wider on the three systems that are loaded with extra server tasks, but
not much. The thing to note is that you need to
On 22/07/2019 18.46, Achim Gratz wrote:
> Tim Shoppa writes:
>> The Raspberry Pi processor clock, like any motherboards', will often be off
>> by off anywhere from +/-200ppm but the good news is that it usually varies
>> by less than +/-10ppm over a day and ntpd does a good job tracking this and
Paul Theodoropoulos via time-nuts writes:
> I've also found that my Raspi's give the best results with board temp
> right around 60°C. However, I found that the 'CPU as heater', while it
> does help dramatically compared to nothing at all, it introduces a lot
> of jitter on its own. Much better
On 7/22/19 09:46, Achim Gratz wrote:
All rasPi I've bought so far (5 of them, all different models from three
different sources) were ~10ppm slow at RT and within -6ppm and 0ppm at
the apex temperature point of the crystal (around 60°C). It is possible
to keep the temperature within about 0.2K
Dear colleagues, i've made some tests and wrote an article about Raspberry
Pi as a timeserver. I think we can trust on it and this board can keep a
good time from GNSS PPS. I'm open to suggestions. I hope this can help in
the decision making process. The link: rpi_article
wildylion via time-nuts writes:
> 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
Tim Shoppa writes:
> Real ntpd uses a drift file to track the local processor's frequency offset
> and has a good estimate of processor clock drift after a day of tracking.
That assumes stable median temperature and predictable temperature
swings.
> The Raspberry Pi processor clock, like any
On Mon, Jul 22, 2019 at 5:03 PM wildylion via time-nuts <
time-nuts@lists.febo.com> 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.
>
>
From: wildylion via time-nuts
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
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
Real ntpd uses a drift file to track the local processor's frequency offset
and has a good estimate of processor clock drift after a day of tracking.
The Raspberry Pi processor clock, like any motherboards', will often be off
by off anywhere from +/-200ppm but the good news is that it usually
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
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
21 matches
Mail list logo
