interrupt latency

In article <kvz9i.14639$%T3.10443@bignews8.bellsouth.net>, Michael N. 
Moran says...
> Robert Adsett wrote:
> > In article <1180936642.272357.147260@q69g2000hsb.googlegroups.com>,  
> > says...
> >> If your system does not have to process other (higher level)
> >> interrupts or has areas in the code where interrupts are disabled,
> >> then the time between 2 calls to timestamp() will be constant, as long
> >> as you have a timer interrupt that restart itself (as indicated by
> >> others as well).
> > 
> > Not necessarily.  Many systems, maybe even most, have varying 
> > instruction execution times depending on the instruction, what memory it 
> > is executing from and what memory is being accessed.  That's without 
> > considering instructions tha automatically disable interrupts for the 
> > next instruction or two. 
> 
> Just as a note. These latency effects are known as jitter.
> The frequency of the the timer interrupt remains constant,
> but the time between interrupts vary. 

Assuming as another poster reminded me that you don't reload the timer 
in the interrupt.  Then you get a drift added to the jitter.

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

On 2007-06-06 23:11:47, Robert Adsett wrote:

>>> Not necessarily.  Many systems, maybe even most, have varying
>>> instruction execution times depending on the instruction, what memory
>>> it is executing from and what memory is being accessed.  That's
>>> without considering instructions tha automatically disable interrupts
>>> for the next instruction or two. 
>> 
>> Just as a note. These latency effects are known as jitter. The
>> frequency of the the timer interrupt remains constant, but the time
>> between interrupts vary. 
> 
> Assuming as another poster reminded me that you don't reload the timer
> in the interrupt.  Then you get a drift added to the jitter. 

You may or you may not. There are techniques that make it possible in many
cases to reload a timer without causing drift (add or subtract to the
current timer value).

Gerhard

"Gerhard Fiedler" <gelists@gmail.com> wrote in message 
news:1f6z3zi5yco0w.dlg@gelists.gmail.com...
> On 2007-06-06 23:11:47, Robert Adsett wrote:
>
>>>> Not necessarily.  Many systems, maybe even most, have varying
>>>> instruction execution times depending on the instruction, what memory
>>>> it is executing from and what memory is being accessed.  That's
>>>> without considering instructions tha automatically disable interrupts
>>>> for the next instruction or two.
>>>
>>> Just as a note. These latency effects are known as jitter. The
>>> frequency of the the timer interrupt remains constant, but the time
>>> between interrupts vary.
>>
>> Assuming as another poster reminded me that you don't reload the timer
>> in the interrupt.  Then you get a drift added to the jitter.
>
> You may or you may not. There are techniques that make it possible in many
> cases to reload a timer without causing drift (add or subtract to the
> current timer value).

Doesn't this require the timer to be able to perform the add/subtract or the 
CPU to perform read-add-write with predictable timing?

-- 
Peter 

On 2007-06-07 11:13:13, Peter Dickerson wrote:

>>> Assuming as another poster reminded me that you don't reload the timer
>>> in the interrupt.  Then you get a drift added to the jitter.
>>
>> You may or you may not. There are techniques that make it possible in many
>> cases to reload a timer without causing drift (add or subtract to the
>> current timer value).
> 
> Doesn't this require the timer to be able to perform the add/subtract or the 
> CPU to perform read-add-write with predictable timing?

Yes. The read-add/sub-write sequence often does have a predictable timing
or can be made to have it (with interrupts disabled -- which often will be
the case in this scenario).

Gerhard

In article <ZnU9i.7141$lz3.1307@newsfe5-win.ntli.net>, Peter Dickerson 
says...
> "Gerhard Fiedler" <gelists@gmail.com> wrote in message 
> news:1f6z3zi5yco0w.dlg@gelists.gmail.com...
> > On 2007-06-06 23:11:47, Robert Adsett wrote:
> >
> >>>> Not necessarily.  Many systems, maybe even most, have varying
> >>>> instruction execution times depending on the instruction, what memory
> >>>> it is executing from and what memory is being accessed.  That's
> >>>> without considering instructions tha automatically disable interrupts
> >>>> for the next instruction or two.
> >>>
> >>> Just as a note. These latency effects are known as jitter. The
> >>> frequency of the the timer interrupt remains constant, but the time
> >>> between interrupts vary.
> >>
> >> Assuming as another poster reminded me that you don't reload the timer
> >> in the interrupt.  Then you get a drift added to the jitter.
> >
> > You may or you may not. There are techniques that make it possible in many
> > cases to reload a timer without causing drift (add or subtract to the
> > current timer value).
> 
> Doesn't this require the timer to be able to perform the add/subtract or the 
> CPU to perform read-add-write with predictable timing?

And a timer that continues running after a match.  I was thinking of the 
other case but Gerhard raises a good point.

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com