Hal Murray via devel writes:
> Near the top, it says:
>
> // _XOPEN_SORUCE needed for strptime()
> #define _XOPEN_SOURCE
Correct. However, as you said you also need siginfo_t, it needs to be
defined with a value of at least 500, so the correct _POSIX_C_SOURCE
level gets defined in addition.
Hal Murray via devel writes:
> I expect the comment on the previous line to tell Coverity to not complain
> about this case.
>
> Is there a typo or such that I'm missing?
>
> 149/* coverity[checked_return] */
> CID 462307 (#1 of 1): Unchecked return value (CHECKED_RETURN)
> 15.
Hal Murray via devel writes:
>> Can somebody give me a lesson in why a program should close all it's
>> descriptors? We can clean up a lot of crufty code if we drop that.
>
> Nobody responded to my request, so I'll assume it isn't needed and start
> working on deleting it.
You're getting ahead
Hal Murray via devel writes:
> Does anybody have access to server class systems?
Not with bare metal Linux at the moment…
> I'm trying to setup a test environment for the thread work. Dell high end
> workstations use Xeon chips. I have a T5610, but it has TSC warp so doesn't
> use the TSC
Hal Murray via devel writes:
> I think you want to use DESTDIR if you are testing things after installing
> them.
No, never. DESTDIR is purely for packaging so that the "install" you do
has the correct directory structure, but doesn't mess up your actual
system. There is only the
Hal Murray via devel writes:
> I want to keep track of the number of times a macro has been called. That
> seems like something that would happen often enough that there would be a
> standard recipe but I haven't seen it. (Or didn't recognize it.)
You seem to be asking for the non-portable
Richard Laager via devel writes:
> With my Debian packager hat on, getting a port in Debian's /etc/services
> is another level of complication that I don't want to have to deal with.
Not to mention that /etc/services has gone away in some distributions
recently (moved to /usr/etc/services) and
Hal Murray via devel writes:
>> the assumption you are suffering from GPS rollover issues
>
> WNRO seems unlikely. That would be off by 20 years. This case if off by 2.
Did you even read what I wrote? This is ntpd assuming a WRNO and
warping the time forward in a misguided attemt at fixing it.
Udo van den Heuvel via devel writes:
> Garmin gps18x on the serial port with USB power.
> With just $GPGGA and $GPRMC enabled, so where did it find that weird date?
If you had the clockstats file enabled, you would be able to see what
message ntpd received at that point. Since you have RMC
Udo van den Heuvel via devel writes:
> May 18 10:06:48 boombox ntpd[2055]: CLOCK: time stepped by 59097600.478559
> May 18 10:06:48 boombox ntpd[2055]: CLOCK: time changed from 2020-07-03 to
> 2022-05-18
That's why you don't trust the GPS time until you know it has a good
lock and also why you
Sanjeev Gupta via devel writes:
> The file:
> -rw-r--r-- 1 root root 3558 May 9 09:39
> fullchain28.pem
> can't stat certificate (chain) from
> /etc/letsencrypt/live/ntpmon.dcs1.biz/fullchain.pem: Permission denied
It seems to me you're having NTPd look for
Udo van den Heuvel via devel writes:
> On 16-04-2020 21:15, Achim Gratz via devel wrote:
>>If so, you must use the clear edge of the PPS (flag2 1).
>
> Why is that?
Because RS232 signaling is negative logic.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk
Udo van den Heuvel via devel writes:
> When then is the jitter so low?
> If solely using NMEA the jitter and offset would be worse.
Well, run ntpq with the -u switch to see what those really are. If
you've set the serial to low latency and a fairly high speed, you can
expect jitter in the
Udo van den Heuvel via devel writes:
> Using tsc clocksource we get:
>
> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> tsc
> # ntpq -pn
> remote refid st t when poll reach delay offset
> jitter
>
Udo van den Heuvel via devel writes:
> So we went to tsc by disabling hpet but that one also has an issue.
> Now we are on acpi_pm.
That is going to suck rocks. So it's just about any clock in your
system going backwards at times except the ACPI-PM?
> See https://pastebin.com/5BbgWVFt for a
Udo van den Heuvel via devel writes:
> When booting with hpet=disable we see stuff like:
Well, what clock sources get reported on boot when you don't force
anything and which one gets ultimately selected by the kernel? Are you
actually using a kernel new enough to know about Ryzen CPU, and does
Richard Laager via devel writes:
> I do not. It seems really fragile to me. A change in an underlying
> library can break a working binary, possibly only in some scenarios.
> That's scary.
It's also somewhat the point of using it: any un-audited change rather
breaks the application than the
Hal Murray via devel writes:
> It seems obvious that we should drop root as early as possible. But it's not
> obvious that we should enable seccomp early.
Root should be dropped before ntpsec starts accepting network input.
Dropping it even earlier doesn't buy you much, since it'd only reduce
Hal Murray via devel writes:
> I'm working on a way to semi-automate generating the list. The basic idea is
> to run ntpd under strace on the type of system you are interested in to
> collect a lot of data, then run a script to extract the list of syscalls from
> the strace log file.
If you
Hal Murray via devel writes:
> I don't think there is any need for crypto randomness when fuzzing the low
> bits of time. If anybody has other opinions, please sing out.
No, you only need unbiased "white" statistics that stays iid in not too
many dimensions. That point was never questioned.
Hal Murray via devel writes:
> Back in December, I fixed get_systime to use random() rather than
> ntp_random()
> which calls RAND_bytes().
I still consider that change to be wrongdoing. If NTP has a use case
for both fast and cryptographically secure randomness, then you should
have ntp_*
Richard Laager via devel writes:
> Upon further investigation, there is a concern about the GPS antenna
> placement.
What concern(s)?
> Does anyone have recommendations for GPS antenna RF-to-fiber converters
> or other ways to have the GPS antenna a long way (in a building) from
> the GPS
Udo van den Heuvel via devel writes:
> On 13-12-2019 11:31, Udo van den Heuvel via devel wrote:
>> No change in ntpd behaviour...
>
> Certificates ended up in /etc/pki/tls/certs/ca-bundle.trust.crt and
> /etc/pki/tls/certs/ca-bundle.crt
>
> But after an ntpd restart no change...
You didn't
Mike Yurlov via devel writes:
> I recently started the public server for ntppool (Yo, Ask) on
> FreeBSD. Yesterday I was migrate from Classic NTPd to NTPSec (oh, it
> was painful!). I'm copy ntp.conf to ntpsec.conf and only convert
> "magic" 127.127.20 x to refclock. When I looking to "top" I see
Hal Murray via devel writes:
> I was trying to suggest using web browser to contact a few non NTS sites as
> a
> way to check the local collection of root certificates.
Web browsers often don't use the certificate chain of the system they're
running on. I generally use either use the gnutls
ASSI via devel writes:
> is… intriguing. If you follow the code through the function, ts_min in
> the log should always be ts_prev+sys_fuzz; these two values can't be
> identical or differ by any other value, ts_min must strictly be greater
> than ts_prev by sys_fuz
Richard Laager via devel writes:
> Also, what does this mean and is it a problem (it's an ERR level)? I'm
> seeing it on both servers.
>
> 2019-11-23T01:49:33.497786-06:00 ntp1 ntpd[28568]: CLOCK: ts_prev 1574495373
> s + 497394102 ns, ts_min 1574495373 s + 497388500 ns
>
Gary E. Miller via devel writes:
> There is a gpsd program in the contrib/ directory. It tests your
> CPU granularity. On a Raspberry Pi that is about 52 ns. Worse
> on an Intel chip.
The actual granularity on RasPi can't be better than 52ns (the clock
it's based on is 19.2MHz) and you can
Richard Laager via devel writes:
> I now have a second stratum 1 server, with an independent setup. This
> allows me to compare the two. Why does ntp1 have this very specific
> repeating pattern of local clock offset? It's roughly +7 us, -5 us, +2
> us, -4 us and then repeats again, over and over.
folkert via devel writes:
> Can I concatenate the loopstats-files to get statistics over longer
> time? Or is there some catch?
Sure. The standard statistic files are rotated daily and I pull these
from the servers regularly (I should set up a proper time series
database eventually). For
Richard Laager via devel writes:
> I'm working with a small, Canadian Internet exchange that offers an NTP
> service. They originally had one CDMA and one NTP master clock NTP
> server feeding (via NTP) 3x Ubuntu + NTP Classic servers facing the
> world. This is in a data center. They have one GPS
Udo van den Heuvel via devel writes:
> yet:
>
> # grep PPS .config
> CONFIG_PPS=y
> # CONFIG_PPS_DEBUG is not set
> CONFIG_NTP_PPS=y
If you really wanted to enable hardpps, then you _must_ disable NOHZ in
the kernel config and let ntpd know (via flag3) that the kernel PLL is
active. Otherwise,
Achim Gratz via devel writes:
> I have been experimenting with determining the frequency offset via the
> MONOTONIC_RAW clock. At the moment I've implemented that as a Perl
> script although it should eventually go into some sort of pps-raw device
> driver that timestamps the incoming PPS pulses.
33 matches
Mail list logo
