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.
42 matches
Mail list logo
