[Twisted-Python] Accurate delays in callLater

[Norm Petterson]

Jp Calderone wrote:

> On Thu, 23 Jun 2005 12:34:41 -0700, Ian Duggan <ian at ianduggan.net> wrote:
>
>>
>> On Thursday 23 June 2005 11:27, Norm Petterson wrote:
>>
>>> If the slippage were unacceptable, I'd try raising process priority
>>> before anything else...
>>
>> Another idea is to do the bookkeeping yourself.
>
> I'd be interested to hear more details about cases where LoopingCall 
> does allow slippage.  As far as I know, there is no room for 
> improvement here: the only thing that could cause it to slip is if the 
> system clock were not maintaining time correctly, and in that case I 
> believe you are pretty much screwed on anything time related (okay, 
> maybe not, I guess you could have an NTP implementation and schedule 
> things against that, rather than the system clock...)
>
In my case, for instance, 86400 repeated 1 second TimerService calls 
might take a few minutes more than precisely 24 hours (which is 
acceptable, so I haven't checked further). I am guessing that something 
outside of Twisted, running at a higher process priority  occasionally 
ties up the machine long enough to miss at least one scheduled cycle, 
possibly even more than one. AFAICT LoopingCall doesn't make any attempt 
to compensate for entirely missed (i.e., catastrophically missed) 
cycles, only for the minor slippage that might otherwise lead to 
gradually missed ones. Right?

Not a Twisted issue; hence recommending bumping process priority.