On Sunday, July 6, 2025 10:27:17 AM Pacific Daylight Time Hal Murray wrote:
> Interesting. Thanks.
>
> > Currently it adds 16 bytes per line logged.
>
> I think 16 is a bit too much.
>
> > The code is pretty simple and I think it should be portable.
> > + fprintf(term_fil
Interesting. Thanks.
> Currently it adds 16 bytes per line logged.
I think 16 is a bit too much.
> The code is pretty simple and I think it should be portable.
> + fprintf(term_file, "%s[%d.%ld]: ", prog, pid,
> (long int)pthread_self());
The Linux man page says that
On Saturday, July 5, 2025 10:40:16 PM Pacific Daylight Time Hal Murray via
devel wrote:
> I'd like msyslog to indicate which thread is doing the logging.
>
> The main thread in ntpd currently creates up to 3 threads.
> One for DNS, and a NTS thread for each of IPv4 and IPv6.
> The DNS thread ge
Yo Hal!
On Sat, 05 Jul 2025 22:40:16 -0700
Hal Murray via devel wrote:
> I'd like msyslog to indicate which thread is doing the logging.
Nice idea.
> Anybody thought about this area? Any good ideas?
None from me, but I like your idea.
RGDS
GARY
--
Hal Murray via devel writes:
>> HPET is a travel out to ACPI system registers mapped into memory, this should
>> never be never cached.
>
> Yes. But there is still the cache for code and data.
The thing is that even when you consider all these things it is highly
unlikely to get the same value tw
Udo van den Heuvel via devel writes:
>> Was the switch to using HPET recent?
>
> hpet must have been the default until it wasn't or at least tsc stopped
> being stable.
HPET hasn't been the default since at least a decade. It only gets used
if TSC is unstable (generally on older hardware in conju
Hal Murray via devel writes:
>> No, that description only holds for what are called "coarse" clocks.
>
> Do you understand this area?
Not in detail, just in a general way.
> I think the term I've been missing is "dither".
Yes.
> I don't understand that area well enough to explain it to anybody.
> No, that description only holds for what are called "coarse" clocks.
Do you understand this area?
I think the term I've been missing is "dither". I don't understand that area
well enough to explain it to anybody. Interesting timing. I was at a talk a
few weeks ago that covered dithering.
> Also the PLL goes up and offsets rise. (just like before)
Another way to maybe learn something.
Can you grab a copy of
http://users.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz.py
It's a hack to measure line frequency using the PPS capture logic. The idea
is to turn that inside out and use
> HPET is a travel out to ACPI system registers mapped into memory, this should
> never be never cached.
Yes. But there is still the cache for code and data.
This sort of code is amazingly delicate. Minor changes can make interesting
changes in the results.
For example:
for (i = 0; i < B
Hal Murray via devel writes:
> devel@ntpsec.org said:
>> That's a fantastically wierd distribution. Here's what my old single core
>> Athlon64 does:
>
> Your sample is what I would expect from a system that isn't doing much. If
> there is other activity going on, the clean bell curve gets sprea
devel@ntpsec.org said:
> That's a fantastically wierd distribution. Here's what my old single core
> Athlon64 does:
Your sample is what I would expect from a system that isn't doing much. If
there is other activity going on, the clean bell curve gets spread out due to
cache reloads and such
Udo van den Heuvel via devel writes:
> hpet:
That's a fantastically wierd distribution. Here's what my old single
core Athlon64 does:
--8<---cut here---start->8---
ntpsec/attic> ./clocks
res avg min dups CLOCK
1 1498 977CLO
On 14-04-19 14:01, Hal Murray wrote:
> backwards runs forever. ^C when you get bored.
No output after running `backwards` for over 30 minutes.
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
On 14-04-19 14:01, Hal Murray wrote:
> I just pushed some tweaks. Would you please try attic/clock and
hpet:
# ./a.out
res avg min dups CLOCK
1 1666 419CLOCK_REALTIME
400 5 444-1 CLOCK_REALTIME_COARSE
1 1657 419CLOCK
On 14-04-19 14:01, Hal Murray wrote:
>
> udo...@xs4all.nl said:
>> ntpsec 1.1.3's ntpd from
>> ftp://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz
>> gives me after startup:
>
>> Apr 13 15:53:50 bla ntpd[12382]: CLOCK: ts_prev 1555163630 s + 594156272 ns,
>> ts_min 1555163630 s + 594155713 ns
udo...@xs4all.nl said:
> ntpsec 1.1.3's ntpd from ftp://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz
> gives me after startup:
> Apr 13 15:53:50 bla ntpd[12382]: CLOCK: ts_prev 1555163630 s + 594156272 ns,
> ts_min 1555163630 s + 594155713 ns
...
Thanks.
So now we know it wasn't a recent
On 13-04-19 18:28, Achim Gratz via devel wrote:
>> !?
>> What /was/ the problem in that case?
>
> The same that you still see: the system clock gets stopped and two
> consecutive reads of the clock read the same (or maybe time even goes
> backwards when looked at with higher resolution).
Timetrav
Udo van den Heuvel via devel writes:
> On 13-04-19 15:29, Achim Gratz via devel wrote:
>> Udo van den Heuvel via devel writes:
>>> Fedora 29, kernel.org 4.19.30. (my compile)
>>
>> Is this a "tickless" kernel perhaps? If so, try "nohz=off" on the
>> kernel command line in the boot manager and see
On 13-04-19 14:02, Hal Murray wrote:
> Plese give it a quick try to see if ntpsec is the problem. How about just
> trying the 1.1.3 release?
ntpsec 1.1.3's ntpd from
ftp://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz gives me after
startup:
Apr 13 15:53:50 bla ntpd[12382]: CLOCK: ts_prev 155
On 13-04-19 15:29, Achim Gratz via devel wrote:
> Udo van den Heuvel via devel writes:
>> Fedora 29, kernel.org 4.19.30. (my compile)
>
> Is this a "tickless" kernel perhaps? If so, try "nohz=off" on the
> kernel command line in the boot manager and see if that helps.
# grep HZ .config|grep -v ^
Udo van den Heuvel via devel writes:
> Fedora 29, kernel.org 4.19.30. (my compile)
Is this a "tickless" kernel perhaps? If so, try "nohz=off" on the
kernel command line in the boot manager and see if that helps.
> AMD Ryzen 5 2400G with Radeon Vega Graphics
While Raven Ridge should fully work w
> I know about bisect but it is quite a task.
HPET works for me.
So far, you have the only test case.
Plese give it a quick try to see if ntpsec is the problem. How about just
trying the 1.1.3 release?
--
These are my opinions. I hate spam.
___
On 13-04-19 12:21, Hal Murray wrote:
>> I never ever saw these before.
>
> Something changed. All we have to do is figure out what/when.
>
> Was the switch to using HPET recent?
hpet must have been the default until it wasn't or at least tsc stopped
being stable.
> Did you do a recent git pull
> clocksource is fixed at hpet since the previous situations where clock sync
> was weird/gone/etc.
> I never ever saw these before.
Something changed. All we have to do is figure out what/when.
Was the switch to using HPET recent?
Did you do a recent git pull? Do you know how to drive git
On 13-04-19 10:09, Hal Murray via devel wrote:
> Here is a typical batch of the confusing CLOCK printout:
>
> Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts_prev 1555072655 s +
> 712154322 ns, ts_min 1555072655 s + 712153764 ns
> Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts 1555072655 s + 7121
Hal Murray via devel writes:
> The general idea is that if your system clock goes tick, tick, tick, in great
> big steps, you want to fill in the bottom bits with randomness. The code
> does
> that by assuming that the tick size is the time it takes to read the clock -
> difference in times be
Here is a typical batch of the confusing CLOCK printout:
Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts_prev 1555072655 s +
712154322 ns, ts_min 1555072655 s + 712153764 ns
Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts 1555072655 s + 712154322 ns
Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: sys
Udo van den Heuvel via devel writes:
> On another box:
[please add the log as an attachment or tell your MUA not to break the lines]
> Apr 12 14:32:16 box.local ntpd[2109]: CLOCK: ts_prev 1555072336 s + 595028760
> ns, ts_min 1555072336 s + 595027293 ns
> Apr 12 14:32:16 box.local ntpd[2109]: CL
On 13-04-19 01:27, Hal Murray wrote:
> I haven't had time to look carefully at the CLOCK problems. What sort of
> hardware is that running on?
Fedora 29 on x86_64 with Garmin gps18x on rs232.
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.n
Gary said:
>> Somebody on 2600:1700:6731:6c0:f2de:f1ff:fe20:1bbe is sending you
>> packets that don't make sense. Same for 68.75.8.147.
> Those two hit my hackathon server as well. But the connection is a normal
> NTPv4 exchange on UDP.
Depends on what you mean by "normal". How much did you
Yo Hal!
On Fri, 12 Apr 2019 16:27:18 -0700
Hal Murray via devel wrote:
> Somebody on 2600:1700:6731:6c0:f2de:f1ff:fe20:1bbe is sending you
> packets that don't make sense. Same for 68.75.8.147.
Those two hit my hackathon server as well. But the connection is a
normal NTPv4 exchange on UDP.
R
The "JUNK" stuff is for debugging NTS. The most important part is the length
at the end. It's rate limited so there shouldn't be any serious problems with
clutter in the log file - just minor potential confusion like this.
Somebody on 2600:1700:6731:6c0:f2de:f1ff:fe20:1bbe is sending you pac
Gary said:
> I would imagine that every anal retentive sysadmin, like myself, would like
> to know when the leap second file changed. Maybe not so verbose.
"Verbose" has two dimensions - the number of messages and the length of an
individual message.
The thing that attracted my attention was
Yo Hal!
On Wed, 09 Jan 2019 10:44:08 -0800
Hal Murray via devel wrote:
> There is an optional flag to leapsec_load_file() that
> enables/disables logging of the hash validity (and maybe other
> things).
> Anybody know why we want this? Anybody object if I remove it?
I would imagine that every
I often use DEBUG_MRA_FOO, and then use judgement and taste as to leave it
in or not.
I use "is it worth writing the documentation for it" as part of deciding to
leave it in or not, and also "am I absolutely sure I have characterized and
fixed this bug such that I'm sure it's fixed, and will not r
36 matches
Mail list logo
