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
> On Jan 24, 2017, at 4:59 PM, Gary E. Miller wrote:
>
>
> Some of these older systems, like G5 Macintosh, may be a good test.
>
> Prolly should test in some VM's too.
>
I have a Mac mini G4 & 2 x Power Mac G5’s I’m willing to install any OS on for
someone to use for testing or buildbot'ing
On Wed, Jan 25, 2017 at 01:14:50PM -0500, Eric S. Raymond wrote:
> Kurt Roeckx :
> > All my real amd64 boxes show:
> > [0.540511] Switched to clocksource hpet
> > [3.327348] Switched to clocksource tsc
> >
> > But my armel shows:
> > [5.722800] Switching to clocksource orion_clocksourc
Yo Kurt!
On Wed, 25 Jan 2017 18:25:09 +0100
Kurt Roeckx wrote:
> All my real amd64 boxes show:
> [0.540511] Switched to clocksource hpet
> [3.327348] Switched to clocksource tsc
Ditto for mine,
My RasPI Ar
[0.689988] clocksource: Switched to clocksource timer
My RasPi 2 and 3:
[
On Wed, Jan 25, 2017 at 02:12:05AM -0800, Hal Murray wrote:
> I think kernels went through 3 stages:
>
> Old old kernels were very coarse. They bumped the clock on an interrupt.
> End of story.
>
> Old kernels use the TSC (or equivalent) to interpolate between interrupts.
> (A comment from M
>> A KVM guest shows:
>> [0.392136] Switched to clocksource kvm-clock
> Sorry, I don't know how to interpret this.
That's telling you how the system is keeping time.
The clock inside the Linux kernel has a plug in API. During startup, it
scans a list of possibilities and picks the best one
Achim Gratz :
> 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.
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
Achim Gratz :
> > Therefore I *deduce* that the PLL correction (the one NTP does, not
> > the in-kernel one Hal tells us is associated with PPS) requires a
> > monotonically increasing clock. It's the simplest explanation for the
> > way libntp/systime.c works, and it explains *everything* that ha
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
Kurt Roeckx :
> All my real amd64 boxes show:
> [0.540511] Switched to clocksource hpet
> [3.327348] Switched to clocksource tsc
>
> But my armel shows:
> [5.722800] Switching to clocksource orion_clocksource
>
> A KVM guest shows:
> [0.392136] Switched to clocksource kvm-clock
S
Hal Murray :
> > All ARM processors back to the ARM6 (1992) have one as well. A little web
> > searching finds clear indications of cycle counters on the UltraSparc (SPARC
> > V9), Alpha, MIPS, PowerPC, IA64 and PA-RISC.
>
> On ARM, you can't read it from user land unless a mode bit is set.
That'
e...@thyrsus.com said:
>> Mark/Eric: Can you guarantee that we will never run on
>> a system with a crappy clock? In this context, crappy means
>> one that takes big steps.
> OK, now that I think I understand this issue I'm going to say "Yes, we can
> assume this".
> All x86 machines back to th
e...@thyrsus.com said:
> *blink* I think I just achieved enlightenment. Gary, Hal, please review
> the following carefully to ensure that I haven't updated my beliefs wrongly.
If there is any discussion, it's just nit-picking. Some of it might be
interesting, but you have the big picture cor
Yo Fred!
On Tue, 24 Jan 2017 18:48:43 -0800 (PST)
Fred Wright wrote:
> > > If one is dithering, the amount of dither should be based on the
> > > clock's actual resolution, *not* the time required to read it.
> > > In a sampled system, one would add dither equal to the
> > > quantization interva
On Tue, 24 Jan 2017, Gary E. Miller wrote:
> On Tue, 24 Jan 2017 15:22:20 -0800 (PST)
> Fred Wright wrote:
> > If one is dithering, the amount of dither should be based on the
> > clock's actual resolution, *not* the time required to read it. In a
> > sampled system, one would add dither equal
Yo Eric!
On Tue, 24 Jan 2017 20:35:23 -0500
"Eric S. Raymond" wrote:
> > The NTP case is roughly stiction. Remember the age of this code.
> > It was working long before CPUs had instructions to read a cycle
> > counter. Back then, the system clock was updated on the scheduler
> > interrupt. T
Hal Murray :
>
> g...@rellim.com said:
> > Makes no sense to me. Adding randomness helps when you have hysteresis,
> > stiction, friction, lash and some other things, but none of those apply to
> > NTP.
>
> The NTP case is roughly stiction. Remember the age of this code. It was
> working long
Yo Fred!
On Tue, 24 Jan 2017 15:22:20 -0800 (PST)
Fred Wright wrote:
> On Tue, 24 Jan 2017, Gary E. Miller wrote:
>
> > 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 m
On Tue, 24 Jan 2017, Gary E. Miller wrote:
> 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 preci
Yo Hal!
On Tue, 24 Jan 2017 13:46:59 -0800
Hal Murray wrote:
> g...@rellim.com said:
> > Makes no sense to me. Adding randomness helps when you have
> > hysteresis, stiction, friction, lash and some other things, but
> > none of those apply to NTP.
>
> The NTP case is roughly stiction. Reme
g...@rellim.com said:
> Makes no sense to me. Adding randomness helps when you have hysteresis,
> stiction, friction, lash and some other things, but none of those apply to
> NTP.
The NTP case is roughly stiction. Remember the age of this code. It was
working long before CPUs had instructions
22 matches
Mail list logo
