James Browning via devel writes:
> Could you go through an remove all the mandatory=True instances and
> equivalent from configure. Then would you run build verbosified and
> get the arguments of a compile and maybe a couple links?
--8<---cut here---start->8---
Hal Murray via devel writes:
> Can you run it again with -k? That might find some more.
That doesn't change anything for the configure phase.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
http://S
Hal Murray via devel writes:
> There is a chicken/egg problem here. I'm trying to find out how different it
> is so I can decide if I'm comfortable with that.
>
> For starters, I'm interested in ntpd. As a straw man, I assume we will need
> a
> small(?) library to provide the API slots that ar
Hal Murray via devel writes:
> I've been assuming that it is reasonably straightforward to setup a POSIX
> friendly environment in Windows. Is that wrong?
Whatever you look at will be just slightly different then what you expect.
> Maybe I should have asked a preliminary question. How hard is
Udo van den Heuvel via devel writes:
> Can we please adjust the service files so that also ntp-wait.service
> starts after we have network?
> Currently only ntpd.service has references to network...
This is what I'm using on my two Tumbleweed machines (you may need to
adjust the installaion paths,
Hal Murray via devel writes:
>> That doesn't do pinning, it reduces the source of trust anchors to just a
>> single one.
>
> Thanks. Would you please give me a lesson (or pointer to one) on this area.
https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
> Does pinning wor
Hal Murray via devel writes:
> I think we can implement pinning with the current code.
>
> We need a script to fetch the certificate, follow the chain to see which root
> certificate it is using, find that certificate in the local root cert
> collection, and copy it to a safe place.
That doesn't
Hal Murray via devel writes:
> The close-everything code either has to skip the files it needs or
> reopen them. That requires keeping track of the files it needs which
> isn't something most programmers do. In our case, that was buggy.
This is a general thing you have to do do in a daemon that
Dan Drown via devel writes:
> Time critical code:
>
> 1. packet tx happening right after tx timestamp for server response
Yes, and that really should be handled in the kernel, maybe implemented
via BPF.
> 2. serial NMEA data timestamps
Arguably that should also (ideally) be the responsibility of
Eric S. Raymond via devel writes:
> Talk to me about what you think the effect of very occasional
> stop-the-world pauses of 600 microseconds or less would be on sync
> accuracy. By "very occasionally" let's say once every ten minutes or
> so, that being what I think is a *very* pessimistic estimat
Hal Murray via devel writes:
> I'd like to move the current kernel mode PLL to user space. I think modern
> CPUs are fast enough for that to make sense. I haven't done any
> experimentation.
That doesn't buy you what you seem to think it does.
This in-kernel PLL (at least on Linux) benefits f
Richard Laager via devel writes:
> On 6/29/21 3:41 PM, Eric S. Raymond via devel wrote:
>> Well, first, the historical target for accuracy of WAN time service is
>> more than an order of magnitude higher than 1ms.
>
> My two NTP servers are +- 0.1 ms and +- 0.2 ms as measured by the NTP
> pool moni
Matthew Selsky via devel writes:
> On Tue, Jun 29, 2021 at 04:41:30PM -0400, Eric S. Raymond via devel wrote:
>
>> Well, first, the historical target for accuracy of WAN time service is
>> more than an order of magnitude higher than 1ms. The worst-case jitter
>> that could add would be barely abov
Hal Murray via devel writes:
> e...@thyrsus.com said:
>> I did. There's a blog post about it:
>> https://blog.ntpsec.org/2017/02/22/testframe-the-epic-failure.html
>
> From there:
>> One was what in discussion on the mailing list I later tagged "the code-path
>> split". There are two kinds of NTP
MLewis via devel writes:
> Is it worthwhile improving the current C code to a 'hardened' programming
> standard?
It's always worth trying, but not as easy as it seems. The fun with
standard is that there are so many to chose from.
> Example
> - Joint Strike Fighter standards https://www.stroust
Eric S. Raymond via devel writes:
> My choice for a language to move to would be Go. Possibly one of you
> can argue for a different choice, though if you agree that Go is a
> suitable target I would find that information interesting.
Since the last round of discussion both sides of the argument h
Hal Murray via devel writes:
> Can you say more. Is there any good Intel documentation that says "Xeon v3
> and up"?
Not that I know of, although it's surely buried inside some file
someplace on ARK.
> Or anything that describes which families or chips will/won't do what
> I want?
The trouble
There is a slight chicken/egg problem. You can't test a released version
until it is released.
Yes you can. The push of the commit and the tagging/pushing of the
release tag can easily be separate events.
--
Achim.
(on the road :-)
___
devel ma
Am 04.09.2020 um 18:48 schrieb Gary E. Miller via devel:
Just because you do not use something does not make it dead.
This is what upstream says about it:
https://www.python.org/doc/sunset-python-2/
When distros no longer support Python 2, then it will be dead.
It is already officially dea
Udo van den Heuvel via devel writes:
> refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2
> 0.260 baud 4800
Your time1 value doesn't make any sense. You should use the highest
baud rate you can configure on your device, if you need to stick with
4800 you must restrict the
Udo van den Heuvel via devel writes:
> Ah, thanks, then I find:
>
> NTSc: certificate invalid: 10=>certificate has expired
How about you post the log for the whole key exchange and not always
just a single line and the another one in the next mail? Here's what
that looks like here:
2020-02-23T07
Udo van den Heuvel via devel writes:
> ntpd[2256]: NTSc: NTS-KE req to pi4.rellim.com took 0.370 sec, fail
You'd need the /^NTSc: / lines immediately preceding this to figure out
where it failed. There is no full separation of all the different fail
modes however, for instance a failed certificat
Hal Murray via devel writes:
> NetBSD just released version 9.0. It now generates this warning:
>
> ../../ntpd/ntp_control.c:1476:34: warning: '%s' directive output may be
> truncated writing up to 255 bytes into a region of size between 0 and 255
> [-Wformat-truncation=]
>
> char str[25
Hal Murray via devel writes:
> Suppose you don't trust all those CAs. What can you do?
Then they shouldn't be in your trust root to begin with. It's easy
enough to remove a CA source file from the system cert store and rebuild
it, although what to do is slightly different on each system.
> One
Hal Murray via devel writes:
> It seemed like a simplle/clean edit. I wonder what I missed.
My admonition some time ago that this is more complicated than you
seemed to think? In a strange way I'm relieved it blows up so quickly,
though.
You would really need to set up a testing rig that can sh
Hal Murray via devel writes:
> Anybody running on macOS? Solaris? (Open)SUSE?
My two desktop machines run openSUSE Tumbleweed (rolling distro of the
latest and greatest), so I never have that problem there. SUSE
enterprise Linux is a slightly different story, but not as long in the
tooth
Hal Murray via devel writes:
> Thanks. Interesting that you are the first to notice. It's been there since
> mid September.
It doesn't always happen and then not with all NTS servers. But the
spec is pretty clear that you must not expect a NUL character at the end
of the string.
>> so you can
The ALPN validation was broken and would always return "bad". Why NTS
works anyway I don't know, but the ALPN negotiated protocol is a counted
string (without an added '\0'), so you can't use strcmp to check you've
got the expected protocol. I've also shortened a way too long (probably
entirely
Richard Laager via devel writes:
> The issue persists when removing "nts" from "server" lines (i.e.
> disabling NTS client behavior).
>
> The problem goes away when disabling NTS server behavior.
I don't serve NTS from the two test machines, so that would be an
additional code path to consider.
Richard Laager via devel writes:
> That was the case for me _at startup_, but not after that. (See the
> attached logs.)
I think the culprit is somewhere in the NTS client code.
>>> This would also explain why a server
>>> that has many clients would see many more such errors.
>
> Why's that? Wh
Richard Laager via devel writes:
>> These may not yet have consistent TSC between cores/sockets (or require
>> BIOS tweaks for that).
> /proc/cpu says constant_tsc, but that's it (besides "tsc", of course).
> That is, I do _not_ have nonstop_tsc, so therefore I presume I do not
> have the "invarian
Gary E. Miller via devel writes:
> If the guy that wrote it wanted to work on it under the NTPsec umbrella
> that would be good. A little guidance and the guy that wrote that could
> be very useful to NTPsec.
"The guy that wrote" it has last participated on this list over a year
ago in this very
Richard Laager via devel writes:
> These both have the following CPU (which is older):
> Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
These may not yet have consistent TSC between cores/sockets (or require
BIOS tweaks for that). The other result where you show that
MONOTONIC_RAW reads much slo
Eric S. Raymond via devel writes:
> Not necessarily a fake; the 8N is the normal variant (without
> stationary mode) and less expensive. I suspect it's the same hardware
> with a different firmware load - they price-discriminate because
> they think the customers for stationary mode will pay more.
Eric S. Raymond via devel writes:
> If we don't see any evidence of beat-induced quantization, I'm willing
> to say we drop this code.
Please don't invent gobbledeegok terminology. "Beat-induced
quantization" is completely devoid of meaning. Again, what we're
talking about is dithering and it is
Richard Laager via devel writes:
> Okay, so upon further reflection, the timestamps seem to indicate that I
> need to use the clear/falling edge. This also explains the duplication,
> I think. This is despite the GPS being configured for rising edge. So as
> Hal (I think) said, something is inverti
[Hal, I've asked before, but again: Can you please configure whatever
you use as your mailer to not always break threading when you reply?]
Hal Murray via devel writes:
> The code that reads the clocks works hard to make sure that fuzzing the
> bottom
> bits doesn't make time go backwards. T
Richard Laager via devel writes:
> These aren't actually NEO-M8N. Are you saying that these ATGM336H-5N are
> good enough?
If you want to build up multiple GPS receivers the best deal available
is still this:
http://navspark.mybigcommerce.com/navspark-mini-6pcs-pack/
With the accompanying patch
folkert via devel writes:
>> > Can I concatenate the loopstats-files to get statistics over longer time?
>> > Or
>> > is there some catch?
>>
>> Sure. The first 2 columns are MJD and seconds-in-day.
>
> Oh and I now realise why it (the octave script for the allan devication)
> started to fail;
Hal Murray via devel writes:
> Has anybody played with chroot? apparmor?
openSUSE delivers both ntpd and ntpsec with apparmor profiles. The
standard profile needs a bit of editing if you set up a reference clock
in order for the daemon to get at the device files.
Regards,
Achim.
--
+<[Q+ Mat
Richard Laager via devel writes:
> Each of these names (N.debian.pool.ntp.org) resolves to only 4 IPs.* The
> four of them resolve to (mostly) non-overlapping IPs. In other words, if
> I resolve only one name, I get 4 IPs, but if I resolve all four names, I
> get 15 IPs. If I wait 150 seconds for t
Udo van den Heuvel via devel writes:
> Can anybody mention which libraries in the chroot I should have for
> ntpsec's ntpd?
> ldd /usr/sbin/ntpd
linux-vdso.so.1 (0x7ffd0dafc000)
libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x7fcfd5415000)
libssl.so.1.1 => /usr/l
Richard Laager via devel writes:
> The default for maxclock is 10. This includes the "pool" entries, of
> which the stock Debian configuration has four:
> pool 0.debian.pool.ntp.org iburst
> pool 1.debian.pool.ntp.org iburst
> pool 2.debian.pool.ntp.org iburst
> pool 3.debian.pool.ntp.org iburst
>
Udo van den Heuvel via devel writes:
> We found out that the major number of the pps0 device had changed.
You shouldn't assume fixed device numbers for devices generated
dynamically. Look in /proc/devices instead of hardcoding the major
number. Alternatively, sysfs lets you know the device numbe
Udo van den Heuvel via devel writes:
> I do not understand why NO_HZ is necessary or even usable without
> conflict witgh PPS such as CONFIG_NO_HZ_COMMON.
NO_HZ has been the default configuration for a long time and it doesn't
have anything to do with the PPS API support. The _only_ conflict is
w
Udo van den Heuvel via devel writes:
> On 03-11-2019 13:22, Udo van den Heuvel via devel wrote:
>> Thanks for your thoughts. I will post the results...
>
> # gzip -dc /proc/config.gz |grep NO_HZ
> # CONFIG_NO_HZ_IDLE is not set
> # CONFIG_NO_HZ_FULL is not set
> # CONFIG_NO_HZ is not set
Again, I
Udo van den Heuvel via devel writes:
> On 03-11-2019 12:35, ASSI via devel wrote:
>> 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_ disabl
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. Based on the Allan
deviation plots b
Hal Murray via devel writes:
> What do I type to find out when my certificate expires? We should make a
> script that can be called from cron.
This will return 0 if the certificate doesn't or 1 if the certificate
does expire within the next 90 days:
openssl x509-in /path/to/cert -noout -checken
Fred Wright via devel writes:
>> So we need _XOPEN_SOURCE set (or something that implies it)
>> somewhere upstream to get this prototype on newer glibc versions.
As said elsewhere, glibc and other systems can't be controlled in the
same way, you need to check which system you are oin and act
accor
Richard Laager via devel writes:
> I haven't fact checked you, but what you're saying about the APIs sounds
> reasonable. Is there any chance you could propose a patch to fix this?
> (Or have you already and I missed it?)
There is no single right solution to this, but there are several completely
Gary E. Miller via devel writes:
>> --8<---cut here---start->8---
>> _GNU_SOURCE should not always be defined, but it does need to be
>> defined in certain cases. For example, on glibc < 2.10, you need to
>> define it to get strnlen() and struct ifreq.
>>
>> Fr
Gary E. Miller via devel writes:
>> But this thread is about that exact function.
>
> We'll have to disagree there. I feel it is much more generic to
> the defines that pull in stuff.
THen change the subject or open your own thread, please.
>> > Not at all what I meant. Flexible about what NTPs
Sanjeev Gupta via devel writes:
> Gary, ALPN string checking. The commit mentioned that it would break
> with previous NTPSec versions.
But it doesn't, because the returned protocol was not checked.
Otherwise it would have never worked in the first place.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAV
Gary E. Miller via devel writes:
> I was not talking about strerror_r().
But this thread is about that exact function.
> I was talking about strnXXX()
> and struct ifreq.
If you talk about strnlen, it's not used in ntpsec (current master).
The other strnXXX functions are ANSI C and don't need a
Gary E. Miller via devel writes:
>> In that case, you need to be prepared for changed semantics in several
>> places and I don't think ntpsec is set up to deal with that.
>
> Changed semantics? No. Simple existence of the prototpe is at stake.
Go back to the original thread and/or read the manua
Gary E. Miller via devel writes:
> _GNU_SOURCE should not always be defined, but it does need to be defined
> in certain cases. For example, on glibc < 2.10, you need to define
> it to get strnlen() and struct ifreq.
In that case, you need to be prepared for changed semantics in several
places an
Hal Murray via devel writes:
> waf turns on _GNU_SOURCE
There's your bug. You can't do that if you want to stay portable, thus
you must find another feature test macro for whatever feature you are
looking for.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld
Mark Atwood via devel writes:
> How does everyone feel about next Saturday, Aug 31 2019-07-31?
You've got a time machine? 8-)
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.ht
Mark Atwood via devel writes:
> Any updates or thoughts?
I don't see it solving any real problem. When you assume an attacker of
the strength needed for it to be effective, then he'd surely have more
effective ways to mess with your network. Also, as long as it doesn't
use both DNSSEC and NTS an
Hal Murray via devel writes:
>> I see no changes related to _XOPEN_SOURCE since 2017. Perhaps you're
>> thinking of GPSD, where there was bunch of rework in that area just before
>> the 3.19 release.
>
> Thanks. You are probably right.
>
> Eric: This area just got more complicated. See #614
>
Hal Murray via devel writes:
>> Basically, I wish to highlight that things may *break* with pre 1.2.0
>
> Do we have any hints that anybody else who interoperated with our old code
> depended on our bug?
Pretty much everybody seems to have had the same bug: accepting whatever
the server sent bac
Gary E. Miller via devel writes:
>> Dan's patch removed
>> collapsed the internal list to a single element that is already
>> stripped of its length byte,
>
> Yes. That was intentional.
As a hotpatch (and demonstration oof the issue) it's OK, as a longterm
fix not. All IMHO of course. Btw, I'd
Gary E. Miller via devel writes:
>> That is making things work for now where there's only one single thing
>> to negotiate, but it will break later on. I've posted what I believe
>> is the correct patch quite some time ago.
>
> What would break? How?
The callback is supposed to traverse two list
James Browning via devel writes:
>> I have attached a reformatted variant which should apply to the
>> current git head. Achim, would you could look at it and see if I
>> messed it up somehow.
>
> I hate gmail sometimes...
Not seeing any attachment… anyway, if you want to switch gears from one
pa
Gary E. Miller via devel writes:
> I just pushed Dan Drown's patch for the ALPN. That allows NTPsec to
> interoperate with other NTS implementations.
That is making things work for now where there's only one single thing
to negotiate, but it will break later on. I've posted what I believe is
the
Sanjeev Gupta via devel writes:
> Eric, next request. I have a spare parallel port on the system, could I
> have a software patch so that it can connect to a 10G optical WDM cable?
But that only works if you drill a hole exactly down the center of each
data wire in the parallel cable, you'll also
Gary E. Miller via devel writes:
> Yo Achim!
>
> On Fri, 16 Aug 2019 21:35:56 +0200
> Achim Gratz via devel wrote:
>
>> Gary E. Miller via devel writes:
>> >> The GT8736 is the same, just with the next-generation chipset and
>> >> fully active
>&g
Gary E. Miller via devel writes:
>> The GT8736 is the same, just with the next-generation chipset and
>> fully active
>
> Got a source for those? I can't find one for sale.
I posted the link yesterday.
> Also, the specs do not look better than fair, and their protocol is
> undocumented.
Another
Eric S. Raymond via devel writes:
> I read the Furuno specsheet and that indeed looks like a nice piece
> of equipment. But Furuno lists it as discontinued, though. Can't find it
> for sale on eBay or elsewhere on the web; there are hints it might have
> EOLed in 2014.
The GT8736 is the same, ju
Gary E. Miller via devel writes:
> Note that is does not appear to support TSIP binary, only NMEA?
To quote the relevant part of the product description:
"Supports M12 binary protocol as well as identical footprint to the Motorola
M12M device."
> So physically an Oncore replacement, but not cod
Gary E. Miller via devel writes:
>> the Furuno is still a bit cheaper
>> (by a factor of three, actually; and not counting the antenna).
>
> Got a link to a retail source for this part?
Not sure if it is of any use to you in the U.S., but they do officially
sell to consumer since some years now:
Eric S. Raymond via devel writes:
> The OnCore already is mostly supported. What's missing is that GPSD
> can't do site-survey mode for the M12 timing variant. These are long
> since EOL but still available on e-Bay for cheap, as boards with
> TTL-level outputs; you have to do systems integration
Eric S. Raymond via devel writes:
> Achim Gratz via devel :
>> Eric S. Raymond via devel writes:
>> > * It has 2ms jitter, way worse than a cheap GPS these days.
>>
>> That is actually much better than what most of the cheap GPS deliver
>> when connected over
Eric S. Raymond via devel writes:
> You've forgotten much, then. I remind you of the Type 2 Bancomm, the
> Type 45 Spectracom TSync PCI, and the Type 16 Bancomm GPS/IRIG
> Receiver.
Type 2 was actually the venerable Trak GPS, which was available in a
number of output configurations. NTPd probably
Eric S. Raymond via devel writes:
> 2. Remove support for device classes that pose an unacceptable
> security risk, e.g. by requiring proprietary binary blobs to be
> linked to the kernel.
There never were any drivers that required "proprietary binary blobs" in
(x)ntpd that I can remember. That
Eric S. Raymond via devel writes:
> * It has 2ms jitter, way worse than a cheap GPS these days.
That is actually much better than what most of the cheap GPS deliver
when connected over USB.
> * All the usual signal-propagation and interference problems that
> have caused most other longwave tim
Achim Gratz via devel writes:
> The disagreement probably was about how the server code compares the
> strings. The API description is pretty clear on that the "in" parameter
> is just the char array of "inlen" characters (the counted string is
> already split
Gary E. Miller via devel writes:
> Which is not what the hackathon people thought.
So, you can mind-read now and expect everyone else to do the same? What
was the problem they've had and how didi they say they wanted to solve
it?
> Can you point out where in the API so I can ask the Hackathon pe
Gary E. Miller via devel writes:
> Yes, it is the length. Should it be there or not? Opinions differed
> at the Hackathon.
It should be there in the alpn vector (which in the case of NTS consists
of just one single element), per the API description. The out parameter
should point after the leng
Hal Murray via devel writes:
> Are the specs and implementation for IEEE floating point tight enough so that
> I should get the exact same result if I run a test on a different CPU
> chip?
Formally yes, if you aren't straying into denormals and you keep
yourself to elementary operations that actu
Eric S. Raymond via devel writes:
> I'd love to remove those shims. But AFIK we don't have anyone testing
> on Cygwin. Can you?
Doesn't compile even after removing the shims.
SCons unconditionally looks for winsock2, even after already having
found the correct network headers for POSIX systems.
Eric S. Raymond via devel writes:
> I'd love to remove those shims. But AFIK we don't have anyone testing
> on Cygwin. Can you?
I'll put it on my list. No promises as to when I might get to it.
ProBably only compile and make sure it starts, not actually running with
a GPS connected.
Regards,
A
Gary E. Miller via devel writes:
>> …a platform that you officially do not support but it looks like you
>> may have, in the past. That must have been years, if not decades ago.
>> There's only three instances of Cygwin-specific code in the current
>> gpsd repository. The first one is in SConstru
Eric S. Raymond via devel writes:
> I'm going by the frequency of Cygwin-specific shims I've seen, and had
> to maintain, in GPSD.
…a platform that you officially do not support but it looks like you may
have, in the past. That must have been years, if not decades ago.
There's only three instance
James Browning via devel writes:
> Also, WSL2 which *might* address adjtimex non-inclusion might be rolling
> out now or soon.
Except it'll run in a VM that is more or less completely separate from
the host system. In particular, it never plugs into the NT kernel.
> My 2015 box seems to be *inco
Eric S. Raymond via devel writes:
> It could be re-ported, with sufficient determination. If I were going
> to do it in C I'd use one of the Unix-based cross-compilation
> toolchains rather than native Windows tools or Cygwin - you get much
> better conformance to modern C and POSIX that way, which
Hal Murray via devel writes:
> Has anybody tried building ntpsec on Windows? Cigwin? I'm just
> curious. How close are we?
I don't think Cygwin has the library functions for actually adjusting
time via the NT kernel yet. Not sure how much effort that would be to
emulate. You could always try
Hal Murray via devel writes:
> Consider something like the collection of samples from a PPS. Assume ntpd is
> not running so the system clock is not bouncing around.
>
> There is some noise with each sample. If you collect several samples, you
> can
> average them to get a better number. You
Hal Murray via devel writes:
>> I'm not going to look at that stuff on YouTube… any link to oldfashioned
>> non-multimedia?
>
> Here is a Usenix paper that covers the same ground:
> https://www.usenix.org/system/files/conference/nsdi18/nsdi18-geng.pdf
Ah, OK; the Huygens folks again. That algo
Hal Murray via devel writes:
> One is the use the PTP style time-stamping available on many modern Ethernet
> interfaces. Does anybody know how that works? API? I assume there is a
> counter in the Ethernet hardware. How does that counter get converted into a
> time stamp?
Yes, it's a hardw
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.
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
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
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
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
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
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
1 - 100 of 387 matches
Mail list logo
