On Thu, 2005-08-25 at 02:45 +0200, Roman Zippel wrote:
> Hi,
>
> On Wed, 24 Aug 2005, john stultz wrote:
>
> > Ok, well, I'm still at a loss for understanding how this avoids my
> > concern about time inconsistencies.
>
> Let's take a simple example to demonstrate the difference between system
On Wed, 2005-08-24 at 18:44 -0700, George Anzinger wrote:
> > Ok, so your forcing gettimeofday to be interval aware, so its applying
> > different fixed NTP adjustments to different chunks of the current
> > interval. The issue of course is if you're using fixed adjustments, is
> > that you have to
john stultz wrote:
On Wed, 2005-08-24 at 16:46 -0700, George Anzinger wrote:
john stultz wrote:
On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
Roman Zippel wrote:
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
I'm assuming gettimeofday()/clock_gettime() looks something lik
Hi,
On Wed, 24 Aug 2005, john stultz wrote:
> Ok, well, I'm still at a loss for understanding how this avoids my
> concern about time inconsistencies.
Let's take a simple example to demonstrate the difference between system
time and reference time.
NTP tells us to update the reference time by 1
On Wed, 2005-08-24 at 16:46 -0700, George Anzinger wrote:
> john stultz wrote:
> > On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
> >
> >>Roman Zippel wrote:
> >>
> >>>Hi,
> >>>
> >>>On Tue, 23 Aug 2005, john stultz wrote:
> >>>
> >>>
> >>>
> I'm assuming gettimeofday()/clock_gettim
john stultz wrote:
On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
Roman Zippel wrote:
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
I'm assuming gettimeofday()/clock_gettime() looks something like:
xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift
Where did you get th
On Wed, 2005-08-24 at 21:49 +0200, Roman Zippel wrote:
> On Wed, 24 Aug 2005, john stultz wrote:
>
> > from your example:
> > > // at init: system_update = update_cycles * mult;
> > > system_time += system_update;
> >
> > and:
> > > error = system_time - (xtime.tv_nsec << sh
On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
> Roman Zippel wrote:
> > Hi,
> >
> > On Tue, 23 Aug 2005, john stultz wrote:
> >
> >
> >>I'm assuming gettimeofday()/clock_gettime() looks something like:
> >> xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift
> >
> >
> > Wher
Hi,
On Wed, 24 Aug 2005, john stultz wrote:
> from your example:
> > // at init: system_update = update_cycles * mult;
> > system_time += system_update;
>
> and:
> > error = system_time - (xtime.tv_nsec << shift);
>
> This doesn't seem to make sense with the above.
On Wed, 2005-08-24 at 20:48 +0200, Roman Zippel wrote:
> Hi,
>
> On Wed, 24 Aug 2005, john stultz wrote:
>
> > Ok, so then to clarify the above (as you mention gettimeofday uses
> > system_time), would your gettimeofday look something like:
> >
> > gettiemofday():
> > return (system_time + (
Hi,
On Wed, 24 Aug 2005, john stultz wrote:
> Ok, so then to clarify the above (as you mention gettimeofday uses
> system_time), would your gettimeofday look something like:
>
> gettiemofday():
> return (system_time + (cycle_offset * mult) + error)>> shift
>
> ?
No.
reference_ti
On Wed, 2005-08-24 at 01:54 +0200, Roman Zippel wrote:
> Hi,
>
> On Tue, 23 Aug 2005, john stultz wrote:
>
> > I'm assuming gettimeofday()/clock_gettime() looks something like:
> >xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift
>
> Where did you get the ntp_adj from? It's not in my
Hi,
On Wed, 24 Aug 2005, Ulrich Windl wrote:
> I'm having a problem with your wording: NTP _does_ control the "system time"
> (system clock), because it's the only clock it can use. The "reference time"
> is
> usually remote or elsewhere (multiple sources). Local NTP does not control
> the
>
On 24 Aug 2005 at 1:54, Roman Zippel wrote:
[...]
> error) >> shift". The difference between system time and reference
> time is really important. gettimeofday() returns the system time, NTP
> controls the reference time and these two are synchronized regularly.
[...]
Roman,
I'm having a probl
Roman Zippel wrote:
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
I'm assuming gettimeofday()/clock_gettime() looks something like:
xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift
Where did you get the ntp_adj from? It's not in my example.
gettimeofday() was in the previous mail:
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
> I'm assuming gettimeofday()/clock_gettime() looks something like:
>xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift
Where did you get the ntp_adj from? It's not in my example.
gettimeofday() was in the previous mail: "xtime + (cycle_offse
On Tue, 2005-08-23 at 23:34 +0200, Roman Zippel wrote:
> Hi,
>
> On Tue, 23 Aug 2005, john stultz wrote:
>
> > In the case above, you're accumulating in fixed cycle intervals. This
> > does avoid having to do the mult/shift combo each interrupt, however
> > since you do not accumulate the entire
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
> In the case above, you're accumulating in fixed cycle intervals. This
> does avoid having to do the mult/shift combo each interrupt, however
> since you do not accumulate the entire interval, and there is some
> sub-tick remainder in cycle_offset. We
On Tue, 2005-08-23 at 13:30 +0200, Roman Zippel wrote:
> On Mon, 22 Aug 2005, john stultz wrote:
>
> > The reason why we calculate the interval_length in the continuous
> > timesource case is because we are not assuming anything about the
> > frequency that the timekeeping_periodic_hook() is calle
On Tue, 2005-08-23 at 13:30 +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 22 Aug 2005, john stultz wrote:
>
> > The reason why we calculate the interval_length in the continuous
> > timesource case is because we are not assuming anything about the
> > frequency that the timekeeping_periodic_hook()
Hi,
On Mon, 22 Aug 2005, john stultz wrote:
> The reason why we calculate the interval_length in the continuous
> timesource case is because we are not assuming anything about the
> frequency that the timekeeping_periodic_hook() is called.
The problem with your patch is that it doesn't allow mak
On Mon, 2005-08-22 at 01:19 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 19 Aug 2005, john stultz wrote:
>
> > timekeeping_perioidic_hook():
> >
> > /* get ntp adjusted interval length*/
> > interval_length = get_timesource_interval(ppm)
>
> Here starts the problem, this requires more e
Hi,
On Fri, 19 Aug 2005, john stultz wrote:
> timekeeping_perioidic_hook():
>
> /* get ntp adjusted interval length*/
> interval_length = get_timesource_interval(ppm)
Here starts the problem, this requires more expensive math than necessary,
as every time you first have to scale th
On Fri, 2005-08-19 at 02:27 +0200, Roman Zippel wrote:
> On Tue, 16 Aug 2005, john stultz wrote:
> > Maybe to focus this productively, I'll try to step back and outline the
> > goals at a high level and you can address those.
> >
> > My Assumptions:
> > 1. adjtimex() sets/gets NTP state values
>
Hi,
On Tue, 16 Aug 2005, john stultz wrote:
> If they are private clock variables, why are they in the generic
> timer.c? Everyone is using it in exactly the same way, no? Why do you
> oppose having the adjustment and phase values behind an ntp_function()
> interface?
These values belong to the
Roman Zippel wrote:
~
The thing that worries me about this function is that it does every
thing in usec. We are using nsec in xtime now and I wonder if it would
not be more accurate to do the math in nsecs. Even tick size
(tick_nsec) does not translate well to usec, it currently being 9998
On Wed, 17 Aug 2005, Ulrich Windl wrote:
> whatever the implementation is, at some point there must exist an interface
> go get
> and set "normal time", free of any jumps and jitter. That "frontend time"
> will be
> used a a base of correction. Basically that means time should be as monotonic
On 16 Aug 2005 at 18:17, john stultz wrote:
[...]
> Maybe to focus this productively, I'll try to step back and outline the
> goals at a high level and you can address those.
>
> My Assumptions:
> 1. adjtimex() sets/gets NTP state values
One of the greatest mistakes in the past which still affe
On 16 Aug 2005 at 11:25, Christoph Lameter wrote:
> You mentioned that the NTP code has some issues with time interpolation
> at the KS. This is due to the NTP layer not being aware of actual time
> differences between timer interrupts that the interpolator knows about. If
> the NTP layer would
On Wed, 2005-08-17 at 02:28 +0200, Roman Zippel wrote:
> Let's look at the example patch below. I played a little with some code
> and this just demonstrates an accurate conversion of the tick/freq values
> into the internal values in ns resolution. It does a little more work
> ahead, but the i
Hi,
On Mon, 15 Aug 2005, john stultz wrote:
> > Please provide the right abstractions, e.g. leave the gettimeofday
> > implementation to the timesource and use some helper (template) functions
> > to do the actual work. Basically as long as you have a cycle_t in the
> > common code something i
On Tue, 16 Aug 2005, john stultz wrote:
> That is why I'm suggesting time_interpolator users to move to my code
> (when they're ready, of course :).
Both are basically timesources. That is why I would suggest you upgrade
the interpolators to timesources. Doing that would enable a gradual
transi
On Tue, 2005-08-16 at 17:14 -0700, Christoph Lameter wrote:
> On Tue, 16 Aug 2005, john stultz wrote:
>
> > This is basically what I do in my patch. I directly apply the NTP
> > adjustment to the timesource interval, and periodically increment the
> > NTP state machine by the timesource interval w
On Tue, 16 Aug 2005, john stultz wrote:
> This is basically what I do in my patch. I directly apply the NTP
> adjustment to the timesource interval, and periodically increment the
> NTP state machine by the timesource interval when we accumulate it.
Is there some way to tell the NTP code how much
On Tue, 2005-08-16 at 11:25 -0700, Christoph Lameter wrote:
> You mentioned that the NTP code has some issues with time interpolation
> at the KS. This is due to the NTP layer not being aware of actual time
> differences between timer interrupts that the interpolator knows about.
My understandin
On Mon, 15 Aug 2005, john stultz wrote:
> Sorry. It was subtle, but after thinking more about your arguments, I've
> stepped back from my earlier goals of replacing the timekeeping code for
> all arches and instead I've decided to just focus on allowing
> architectures that would duplicate code us
On Tue, 2005-08-16 at 00:14 +0200, Roman Zippel wrote:
> On Wed, 10 Aug 2005, john stultz wrote:
>
> > Here's the next rev in my rework of the current timekeeping subsystem.
> > No major changes, only some cleanups and further splitting the larger
> > patches into smaller ones.
> >
> > The go
Hi,
On Wed, 10 Aug 2005, john stultz wrote:
> Here's the next rev in my rework of the current timekeeping subsystem.
> No major changes, only some cleanups and further splitting the larger
> patches into smaller ones.
>
> The goal of this patch set is to provide a simplified and streamline
On 10 Aug 2005 at 22:32, Lee Revell wrote:
> On Wed, 2005-08-10 at 19:13 -0700, john stultz wrote:
> > All,
> > Here's the next rev in my rework of the current timekeeping subsystem.
> > No major changes, only some cleanups and further splitting the larger
> > patches into smaller ones.
>
> L
On Wed, 2005-08-10 at 19:39 -0700, john stultz wrote:
> Ah, I've got a patch on my laptop that takes that down to ~2% or less.
> I didn't include it in this patch set but I'll work to get it
> integrated before the next release. Sorry about that.
>
> If you have any suggestions for further perform
On Wed, 2005-08-10 at 22:32 -0400, Lee Revell wrote:
> On Wed, 2005-08-10 at 19:13 -0700, john stultz wrote:
> > All,
> > Here's the next rev in my rework of the current timekeeping subsystem.
> > No major changes, only some cleanups and further splitting the larger
> > patches into smaller one
On Wed, 2005-08-10 at 19:13 -0700, john stultz wrote:
> All,
> Here's the next rev in my rework of the current timekeeping subsystem.
> No major changes, only some cleanups and further splitting the larger
> patches into smaller ones.
Last I heard this made gettimeofday() 20% slower on x86.
All,
Here's the next rev in my rework of the current timekeeping subsystem.
No major changes, only some cleanups and further splitting the larger
patches into smaller ones.
The goal of this patch set is to provide a simplified and streamlined
common timekeeping infrastructure that architec
43 matches
Mail list logo
