Eric S. Raymond writes:
> It's a clever idea. A posse of Germans apparently headed by one Frank Kardel
> noticed that a lot of clock-radio drivers are structurally very similar:
> repeatedly read a text packet from the device, parse it into a timestamp,
> feed the timestamp to the sync algorothms,
Eric S. Raymond writes:
> Here's how I think it should look:
>
> --
> refclock shm unit 0 refid GPS
> refclock shm unit 1 prefer refid PPS
> --
I think that's sti
Hal Murray writes:
> strom...@nexgo.de said:
>> I think that's still perpetuating a mistake. This whole business of having
>> to specify two servers (or refclocks) for the same thing should go away.
>
> There is a fundamental issue. With a PPS, there really are two sources of
> time. Internally
Eric S. Raymond writes:
> The reason I disagree is I think you're overfocusing on the fact that
> both refclocks are the same physical device and underfocusing on the
> fact that they're two different data channels, possibly with different
> fudges and modes.
No, it's exactly my contention that th
Eric S. Raymond writes:
> Which reminds me: an addition I'm considering is adding "offset" as a
> synonym for time1 or time2, whichever one usually sets an offset for
> time reported from the unit.
The documentation is quite unclear on this and I'm not sure I'd trust
each driver to do exactly the
Eric S. Raymond writes:
> Gary E. Miller :
>> Anyone got a guess what the equivalent RasPi setting to turn off
>> power saving would be?
>
> turbo=1 in /boot/config.txt, I think. See also
No. That used to be "force_turbo=1", but is not needed anymore. You
simply define the maximum (and perhaps m
Gary E. Miller writes:
>> No. That used to be "force_turbo=1", but is not needed anymore.
>
> As of what kernel? I notice RasPi's have all sorts of weird kernel
> versions and patchsets.
I've not kept notes, but the first Raspbian installation from about two
years ago already didn't need it (unt
Gary E. Miller rellim.com> writes:
> > The BCM SoC actually is a media processor with an ARM subsystem and
> > not the other way around as typically found elsewhere. The timestamp
> > counter and all I/O is provided by the VC4.
>
> Got a citation for that?
[MIND THE LINEBREAKS]
https://www.rasp
Gary E. Miller writes:
> Nothing at all about GPIO or timestamping.
>
> Did I miss something?
Maybe the fact that all the GPIO registers and the timestamp counter are
on the VC4 side of the SoC. The Linux kernel just reads those when it
gets interrupted by the VC4, the ARM subsystem doesn't have
Gary E. Miller writes:
> I looked for any GPIO timestamp counter in those docs. I could not find
> it. Got a page number? Or maybe see where the gpio driver reads such a
> thing?
There is no hardware timestamping, the GPIO just raise interrupts. But
there is one single system time counter on t
Hal Murray writes:
> Using microseconds for everything is hard to read for long delays typical of
> network links. In bufferbloat cases, I see delays of several seconds. I've
> seen delays of 10s of seconds. I can't count all those 0s quickly. I think
> milliseconds would be better. (Looks
Dan Drown writes:
> The GPS module I'm using still outputs PPS even when it loses lock.
> That won't be true for every GPS module.
I also have a NavSpark mini attached at the moment and I was surprised
it kept outputting the PPS when losing 3D lock (it stops blinking the
LED). It seems semi-docum
Eric S. Raymond writes:
> I shall now discuss three interlocking reasons this possibility does
> not loom as large in my mind as it does in Hal's.
[…]
> When I think about this, I consider 10ms total deviation from UTC as
> the target for WAN service. Let's say your local clock drifts by 3ms
> per
Eric S. Raymond writes:
> Achim Gratz :
>> Forget about GPS outages. If you want to connect these time servers to
>> the net, they should have some form of sanity checking that's
>> independent from their primary time source and take them off the net as
>> soon as
Hal Murray writes:
> Most CPU chips include a temperature sensor.
The temperature sensor for the CPU is close to useless unless you have
an SoC with the XO integrated. It tells you a lot about the average
load of the CPU, but not much else.
> For Linux PCs, you need the coretemp module loaded.
Hal Murray writes:
> e...@thyrsus.com said:
>> I have a USB thermometer on order, they're cheap. Might I suggest you get
>> one and repeat this experiment, actually plotting your temperature
>> variation?
>
> Most CPU chips include a temperature sensor.
>
> For Linux PCs, you need the coretemp mo
Achim Gratz writes:
> That'd give you the actual crystal
> temperature, which might enable forward temp compensation (there's a
> blog post somewhere from someone who's done that with x86 hardware, I
> can't find that link quickly enough).
This was the article I w
Gary E. Miller writes:
> Most cheaper GPS always output PPS, even when they have no idea
> where they are or what time it is. Garmin documents this, as do others.
Well, the NavSpark mini does not output a PPS until it aquires a 3D
lock, as documented. The configuration program has options to eit
Eric S. Raymond writes:
> Hal:
>
> But maybe we should have a separate thread per refclock to get the
> time stamp. ...
…or move the refclocks out of ntpd altogether and use some shared memory
or mailbox system to have ntpd have a look at the timestamp stream from
each refclock. Then you have t
Dan Drown writes:
> The limit they hit with their hardware was around 370kpps (with a
> single process receive), which is a lot of NTP.
>
> From my own testing with iperf high rate 64 byte UDP packets, max
> rate before 1% receive packet loss:
>
> i3-540 / Intel 82574L nic: ~469kpps
> Athlon(tm) 64
Gary E. Miller writes:
> Poll=2s is still the bast for this hardware, but there is a little
> tradeoff between offset and jitter. Since NTP is about time, not
> frequency, we go with the best time.
You 've made this argument before, but I think it's circular reasoning.
You make the local clock fo
Gary E. Miller writes:
>> You 've made this argument before, but I think it's circular
>> reasoning.
>
> Really? I think the data is very clear, you can optimize for time
> or for frequency.
No, I still think you're misinterpreting it. The only reason you see
that apparent tradeoff is that once
Hal Murray writes:
> ntpq cv xxx gives you lots of info for a refclock. (get the xxx from apeers)
> It doesn't include minpoll/maxpoll, but that could be fixed.
I don't think it's documented anywhere easy to find, but instead of
looking up the ever changing ID you get from apeers, I found that I
Gary E. Miller writes:
> spidey ntpsec # ntpq cv '&1'
> No address associated with hostname
Then your refclock is not the first association.
> How do I find tha sssccociation index?
ntpq -c assoc
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory
Gary E. Miller writes:
> How does that tell me which is 127.127.28.1?
ntpq -c apeer
> And the ntpq -cv '&3' still fails:
ntp -c 'cv &3'
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Dow
Hal Murray writes:
> I'm seeing things like this:
> remote refid st t when poll reach delay offset jitter
> ==
> 0.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.001
> 1.u
Jason Azze writes:
> I suppose gnuplot can't "know" the difference between a real
> interval between points and one where something has broken.
You can tell gnuplot that the data is missing and it will not connect
the end points of the data on either side of the gap. You can either do
that by in
Gary E. Miller writes:
> We already discussed this. The load on a RasPi distorts the timing
> so badly that it shows up on the ntpizv plots. The Heisenberg Uncertainty
> Principle in action: Mmasuring distorts the thing being measured.
The load itself actually doesn't distort the timing. It war
Gary E. Miller writes:
> So, two float conversions per cycle. If C you would do this to
> change a float to a store to make it much faster:
>
> # a is a string of the current time, b is a float of the last time
> # c is a float of the current time
> c = float (a )
> i
Eric S. Raymond writes:
> I think ntpmon might be it. "Look! Real-time status updates! Color!
> Animation!" OK, animation only in the crudest possible sense, but
> human beings undeniably do respond to this sort of thing.
Hmm. What exactly does it buy me over running 'watch -n 5 ntpq …' with
the
Hal Murray writes:
> I assume the default is auto.
>
> How do I find out what that really does?
The usual thing to do is check if stdout goes to a terminal and color
that using escape sequences pulled from terminfo. If the output goes
someplace else or the terminal doesn't support (enough) colors
Gary E. Miller writes:
> Ntpviz now has a plot for frequency vs temp. The results are
> interesting.
…wasn't it you who said just two weeks ago that they wouldn't be?
> Attached is from a Pi3. It plots the Local Frequency Offset vs. the
> Pi CPU temp.
You really need to record the temperature
Gary E. Miller writes:
>> The denominator is a temperature difference, which can't be reported
>> in °C; so that should be ppm/K.
>
> One °C is one °K for ratio purposes. The offset cancels out when youu
> compute the delta.
There isn't any unit °K, it's just K; and as I said, °C must not be used
Gary E. Miller writes:
> Hard to control the power dissipation on a PC serving the internet.
We weren't talking about a PC, or at least I was not. The only subject
I'm discussing is a rasPi and more specifically the 2B, which has
multiple cores to play with.
>> 99% of all
>> PPS timestamps over
Gary E. Miller writes:
> Yeah, I still arrive at tthe same opinion.
You are free to keep it.
>> This data was for 86400 raw PPS
>> timestamps (which you are seemingly not recording), you are talking
>> the loopstats.
>
> Correct. I care about the end result. But when I look attt my raw
> data
Hal Murray writes:
> or you can't see anything if you use tee.
>
> I assume the python default is line buffered when sysout is a terminal but
> not if it's a pipe.
Yes, but running the command in question with
stdbuf -oL …
should make it line-buffered anyway.
Regards,
Achim.
--
+<[Q+ Matrix-
Daniel Franke writes:
> The reference timestamp isn't really used for anything
The server is supposed to return this value unchanged, so one of the BSD
implementations of the ntp client uses this field to send random data in
order to weed out replay and fake packets. Checking for out-of-order
rep
Daniel Franke writes:
> You have a couple things mixed up here.
Thanks for the clarification.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
I've configured to use python3.4m, since that's what I have a matching
python-config installed for. However, all the Python scripts still use
/usr/bin/python (which points to python2.7 on my system) and hilarity
ensues. The waf build or install needs to create the correct shebang
lines when a di
I've switched to the new refclock configuration syntax, but it seems
there is either a bug somewhere in the implementation or some mismatch
to the documentation.
I was trying to set up my NavSpark GPS to use $GPZDA and 115200 baud
like this:
refclock nmea unit 1 refid NavS mode 8 baud 115200 fla
I've tried to configure ntpd to use seccomp on Raspian, but it shows an
error on start:
Nov 26 13:10:59 raspberrypi2 ntpd[18805]: sandbox: seccomp_init succeeded
Nov 26 13:10:59 raspberrypi2 ntpd[18805]: sandbox: seccomp_load() failed:
Invalid argument
It then seems to work anyway, but I'm wond
Configuring ntpd to drop root early makes it fail to open the refclock
devices (which are owned by root). I guess they should be readyble by
group ntp at least on Raspbian, which starts ntpd with that group?
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>
Eric S. Raymond writes:
> Hal Murray :
>> The old ntpq used to accept any unique prefix of a command. The new version
>> doesn't.
>
> I was going to say tab completion is the closest we can come, then I thought
> of a kludgy way to fix this by hacking the precmd method. It might not be
> portabl
Eric S. Raymond writes:
> We've tried to
> write the NTPsec Python this way, but the packet library is still
> under active development on a Python 2 system and that sometimes
> breaks Python 3 compatibility. One of our guys, Matt Selsky, is
> working on catching it up and I expect fixes will land
Eric S. Raymond writes:
> Achim Gratz :
>> Configuring ntpd to drop root early makes it fail to open the refclock
>> devices (which are owned by root). I guess they should be readyble by
>> group ntp at least on Raspbian, which starts ntpd with that group?
>
> Y
Eric S. Raymond writes:
> Achim Gratz :
>> Eric S. Raymond writes:
>> > We've tried to
>> > write the NTPsec Python this way, but the packet library is still
>> > under active development on a Python 2 system and that sometimes
>> > breaks Python
Eric S. Raymond writes:
> I would expect pulling the baud rate into the mode field to work, because
> here's the logic:
>
> /* Old style: get baudrate choice from mode byte bits 4/5/6 */
> rate = (peer->ttl & NMEA_BAUDRATE_MASK) >> NMEA_BAUDRATE_SHIFT;
>
> /* New style: get baudra
Hal Murray writes:
> strom...@nexgo.de said:
>> I've tried to configure ntpd to use seccomp on Raspian, but it shows an
>> error on start:
>
>> Nov 26 13:10:59 raspberrypi2 ntpd[18805]: sandbox: seccomp_init succeeded
>> Nov 26 13:10:59 raspberrypi2 ntpd[18805]: sandbox: seccomp_load() failed:
>> I
Eric S. Raymond writes:
> OK, there are two ways we can handle this.
The third way is building a hash table that maps each possible unique
prefix to the actual full-length command.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf B
Achim Gratz writes:
>> Our philosophy in situations like this is to go for the high-security option
>> even if it needs a little more one-time setup, like a chmod or a udev rule.
>
> I'll try that tomorrow as well. I have these devices set up by udev
> anyway, so I only
Hal Murray writes:
> There is another worm in this area. The PPS stuff for serial ports in Linux
> needs some magic like:
> ldattach 18 /dev/ttyS6
> Does anybody have a udev recipe to set that up?
--8<---cut here---start->8---
KERNEL=="pps0" SYMLINK+="gpspps
Achim Gratz writes:
> Yes, and please provide an option to set that width instead of trying to
> figure out a number that works for everyone. Well, you can do that too,
> but I can guarantee that whatever number you come up with doesn't work
> for at least one person.
Like thi
Eric S. Raymond writes:
> I'm not buying the second clause as a real problem. Nobody does that
> kind of parsing with actual fixed fields as an assumption, not when
> all modern scripting language make parsing by whitespace-separation
> trivial.
If I had a nickel for each time somebody said "Nobod
Achim Gratz writes:
> It doesn't use wide display for the rv and cv commands no matter the
> option.
That turned out to be caused by a hardcoded width:
--- a/ntpq/ntpq
+++ b/ntpq/ntpq
@@ -443,7 +444,7 @@ usage: help [ command ]
lastcount = 0
Eric S. Raymond writes:
> Oh, bletch. I see the problem. I'm going to have to write a real
> parser rather than using a naive split(",") call.
>
> ...or maybe not. Rather klugey fix pushed. Complain if it needs
> futher work.
Current master is mysteriously broken:
pi@raspberrypi2:~/ntpsec $ n
Achim Gratz writes:
> Eric S. Raymond writes:
>> Oh, bletch. I see the problem. I'm going to have to write a real
>> parser rather than using a naive split(",") call.
>>
>> ...or maybe not. Rather klugey fix pushed. Complain if it needs
>> futher
Eric S. Raymond writes:
> ...or maybe not. Rather klugey fix pushed. Complain if it needs
> futher work.
Breaks as follows:
pi@raspberrypi2:~/ntpsec $ ntpq/ntpq -p -c "cv &1" -c "cv &2"
remote refid st t when poll reach delay offset jitter
==
Eric S. Raymond writes:
> Achim Gratz :
>> Current master is mysteriously broken:
>
> Fix pushed. Though I don't undetstand what odd corner case in the
> import rules we tripped over.
That now doesn't work like this:
pi@raspberrypi2:~/ntpsec $ ntpq/ntpq -c "cv
Eric S. Raymond writes:
> Possibly this is a Python-3-specific issue? Not that that doesn't mean
> we should fix it.
I'm currently using /usr/bin/python, which is pointing to
/usr/bin/python2.7, so I don't think that's the reason.
>> Also, it seems that association indices can't be used if you d
Eric S. Raymond writes:
>> That now doesn't work like this:
>
> Fix pushed. Try again?
Almost there… where are the double double quotes coming from? And can
the header rule be truncated to the table width, please?
pi@raspberrypi2:~/ntpsec $ ntpq/ntpq -pc "cv &1" -c "cv &2"
remote
Hal Murray writes:
> I spent a lot of time chasing what I thought was a missing syscall in the
> seccomp list, but that was a wild goose chase.
>
> For me, it currently breaks even without seccomp.
Hmm. Works just fine for me… Did for some reason one of the devices
you use not close correctly w
Achim Gratz writes:
> Eric S. Raymond writes:
>>> That now doesn't work like this:
>>
>> Fix pushed. Try again?
>
> Almost there… where are the double double quotes coming from?
Fixed by:
--- a/pylib/packet.py
+++ b/pylib/packet.py
@@ -1108,7 +1108,6 @@ clas
Achim Gratz writes:
> Although I still think the limiting should be done in ntpq (or any other
> program using utils) rather than there so that one can override the
> termwidth from the top-level caller without second-guessing by util.
The more general way to do that would b
Hal Murray writes:
>> Hmm. Works just fine for me…
>
> I think the problem is that gdb is broken on ARM. Does it work for you?
I avoid the use of debuggers whenever possible, so I can't comment
(that's a habit I got into when maintaining some large-scale numerical
simulation codes and it stuck…)
Eric S. Raymond writes:
> Achim Gratz :
>> Although I still think the limiting should be done in ntpq (or any other
>> program using utils) rather than there so that one can override the
>> termwidth from the top-level caller without second-guessing by util.
>
> Agree
Hal Murray writes:
>> Sounds strange. Any easily followed recipe to demonstrate what you are
>> seeing?
>
> gdb /usr/local/sbin/ntpd
> break main
> run -n -u ntp:ntp
>
> For me, on ARM, that crashes before it gets to the breakpoint.
It's been a _really_ long time I've tried anything like this an
Mark Atwood writes:
> I was on a project years ago that did that (minimal length matching of
> command strings).
>
> Someone on team dug up an amazing little utility that ingested a list of
> strings, and emitted a human-unreadable table-driven maximally efficient C
> function that implemented some
Eric S. Raymond writes:
> I've abolished the command-line options that these make redundant.
Unless I misunderstand what you did, why do you think it redundant that
the initial display should be configurable via command line? Whether
you can change later via keystrokes instead of having to quit a
Eric S. Raymond writes:
> I had it working like that for a while. The problem is that there is no
> way to satisfy all three of the following constraints:
>
> 1. ntpmon options have the same semantics as corresponding ntpq options
> 2. option letters are the same as the corresponding command keys
Am 23.12.2016 um 13:08 schrieb Eric S. Raymond:
Next time you do something like this, including a documentation patch
will get it merged faster.
Thanks. I wasn't expecting you to merge this patch based on the rest of
the discussion and the lack of any review comment on this. If you think
so
Am 23.12.2016 um 04:59 schrieb Hal Murray:
google tells me that's because SELinux is blocking access.
If you switch SELinux into permissive mode (from enforcing) the logs
should tell you exactly which access would fail and for what reason.
From what you've been showing I think the config file
Am 23.12.2016 um 20:59 schrieb Hal Murray:
Thanks. That sounds right, but what do I type to make it happen?
I think the command to use is chcon, although if you want this change to
persist re-labeling of the filesystem (which is regularly done in
postinstall when SELinux is enabled), you als
I've kept to rasPi running through the leap second.
The first was following the PTB servers as a stratum2 and monitoring
both a DCF77 and a GPS (via USB). This one correctly announced the leap
second and kept the time.
The second one was configured as a stratum1 (via GPS w/ PPS) and
monitoring
Achim Gratz writes:
> The second one was configured as a stratum1 (via GPS w/ PPS) and
> monitoring the PTB servers for reference. Since apparently Jessie has
> not been updated with the correct leap second file (it still doesn't
> recognize the leap second as a valid datum), t
Eric S. Raymond writes:
> However, what I *do* take away is that our drastic reduction surgery
> on the rest of the suite apparently has not accidentally damaged the
> PLL nor screwed up its convergence properties. I find that very
> reassuring.
While that was not in fact my point in my previous p
Eric S. Raymond writes:
> Please consider writing a PLL entry for the glossary that includes
> these pointers and also distills some of your field experience.
The NTP situation is "slightly" more complex since it really uses an
FLL/PLL combination, which makes it considerably harder to ascertain
s
Eric S. Raymond writes:
> 1. Performance and algorithm tuning - we need to take a serious swing
> at Gary's slow-convergence problem, in particular.
This objective needs to be defined more properly. At the moment I'm not
all that convinced that this is a real defect considering the guarantees
tha
Hal Murray writes:
> What do you mean by "feedforward"?
Project the changes from the expected drift and temperature onto the NTP
loop variables before the actual loop code tries to remove the residual
error. While the loop is closed, this should make the error variables
more white and hence impro
Eric S. Raymond writes:
> I'm not worried about that for Go, because Google has sunk a lot of investment
> into million-line Go programs (like running YouTube and the Chrome download
> server). Because those are unlikely to go away, so is its funding case. This
> is actually one of the stronger ar
Eric S. Raymond writes:
> But how to define that space is itself not entirely clear. One of the
> more intelligent comments in the (generally high-quality) discussion of
> the "Getting past C" blog post argued that because ntpd is more like a
> network service daemon than an OS kernel, Go is a bet
Eric S. Raymond writes:
> Good idea. I'd do it something like this:
>
> 1. Every time we ship a packet, take timestamps at the beginning and end of
> the
> critical region.
If it is possible to get the actual time the packet left, then that's
the data to get the adjustment value from. I'm not s
Hal Murray writes:
> g...@rellim.com said:
>> Ths plot is NTP drift vs. temp.
>
> No, that's a plot of temp vs time and another plot from a different file of
> drift vs time. If you can capture both at the same time then you can ignore
> the time in the file and plot drift vs temp.
> http://u
Hal Murray writes:
> How well do the languages/systems you are considering support threading?
Concurrency doesn't have to be supported via threads at the language
level, although they'd map to something thread-like in the kernel most
likely.
> What should our code look like in the long term? Wil
Eric S. Raymond writes:
> Ever since reading about occam in the 1980s I'd had a suspicion that CSP
> was the Right Thing - a suspicion which seems to me to have been strongly
> confirmed by my recent experience using Go channels.
Well, having programmed on a Transputer machine farther back in time
I've just updated NTPsec on my rasPi and I get these warnings that I
think are new:
--8<---cut here---start->8---
warning: Action stamps require git version 2.7+.
--8<---cut here---end--->8---
Debian Jessie has git-2.1.4. T
Eric S. Raymond writes:
>> --8<---cut here---start->8---
>> warning: Action stamps require git version 2.7+.
>> --8<---cut here---end--->8---
>
> That's from the new version of autorevision I think it's harmless.
It showed up
Hal Murray writes:
> Making sure our stuff worked on Big Endian gear seemed important enough that
> I got a Mac-mini from eBay.
Another option would be one of the many MIPS based router/WLAN boxes,
which can often be had for even less than a rasPi, but require a bit of
hacking to get new firmware
Hal Murray writes:
> I'm mostly caught up again.
>
> I have a hack that makes it work on NetBSD.
> The problem is that the run time loader/linker doesn't look in /usr/pkg/lib
> where libsodium ends up. I added a link from where it does look:
> ln -s /usr/pkg/lib/libsodium.so.18 /usr/lib/li
Gary E. Miller writes:
> Last week we had a discussion on sys_fuzz and the value of adding
> random noise to some measurements. The code defi2nes sys_fuzz asL
>
> "* The sys_fuzz variable measures the minimum time to read the system
> * clock, regardless of its precision."
>
> Rondomness
Gary E. Miller writes:
> Dr. Mills did not put it there. This was added in 2011 by Dave hart.
> See my previous email that probably crossed by yours in flight.
The way I read things, Dave Hart's patches were to ascertain
monotonicity on top of the already existing fuzzing.
> It proves that sys_f
Eric S. Raymond writes:
> Stiction in this context = "adjacent clock reads could get back the
> same value", is that right? Suddenly a whole bunch of things, like
> the implications of only updating the clock on a scheduler interrupt,
> make sense.
Yes, either the same value or a value that has i
Eric S. Raymond writes:
> Is "unbiased and has a (relatively) white spectrum" equivalent to
> looking like symmetrical digital white noise around actual UTC, if you
> knew what it was?
Yes, if you knew the error exactly, then looking at it as a signal in
its own right. The task of the PLL is to s
An Intel Haswell E3-1225v3 w/ Intel GbE:
[0.00] clocksource: refined-jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 7645519600211568 ns
[0.00] clocksource: hpet: mask: 0x max_cycles: 0x,
max_idle_ns: 133484882848 ns
[0.00] hpet clockevent
Kurt Roeckx writes:
> On Tue, Jan 24, 2017 at 10:38:50PM +0100, Achim Gratz wrote:
>> sys_fuzz (which whitens the quantization noise on the clock reading)
>> doesn't make a difference or you might not. But presumably Dave Mills
>> didn't put it in there just becau
Eric S. Raymond writes:
> It depends on which MAC algorithms we want to support, a question I've opened
> in a recent email. It looks like libsodium's support for hash functions in
> our set is limited to SHA-2, so libsodium can't replace OpenSSL.
SHA1 will go out of OpenSSL sooner than you might
Kurt Roeckx writes:
> So as one of the OpenSSL people, it seems unrealistic to even have
> a compile time option to remove MD5 and SHA-1 at this time. Both
> are needed for TLS 1.0. It seems unrealistic that we can drop
> support for that in the next 5 years. We still support SSLv3, but
> it's disa
The Stratum-1 HOWTO needlessly confuses tickless operation with the
opposite: "An optimization that is convenient to apply at this point is
telling the kernel to run tickless[…]". The standard kernel is running
tickless by default and switches off the scheduling tick when all CPU
become idle. Th
Eric S. Raymond writes:
> I'd take a patch to fix this.
Can do if you tell me where's the source repository.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Achim Gratz writes:
> Eric S. Raymond writes:
>> I'd take a patch to fix this.
>
> Can do if you tell me where's the source repository.
Nevermind, I found it.
>From 71af21049fcc58711c55a815e4028a11a75a4929 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Sun, 29 Jan
Gary E. Miller writes:
> I find that running at the hightest speed, and using ther performance
> governor leads to the best results.
However, if the system is crashing due to it getting too hot or pulling
too much current from a slightly underspeced PSU, then that slight
performance improvement is
1 - 100 of 614 matches
Mail list logo
