[Twisted-Python] Accurate delays in callLater

[George Sakkis]

Thank you everyone who wrote back,

>From the replies I gather that preemptive scheduling would do the trick.
If it's not provided out-of-the-box in Twisted, is there a way it can be
simulated ? Here's a little more context:
- There are two processes involved, one for a single server and the other
for a small number (2-22, in my case 5) of clients. Twisted controls the
client side. Each client:
    - communicates asynchronously with the server through UDP. Clients
don't talk to each other directly.
    - expects two (actually more but two are the important) types of
messages, say 'feel' and 'see'.
    - when 'feel' is received, it schedules a call with a delay of 50-90
ms. It also updates itself, a computationally light procedure (at least
for now).
    - when 'see' is received, it updates itself accordingly; this *is* cpu
intensive and most time is spent at an extension's module code (by the
way, it would be very helpful if I could optimize the extension but I
don't know how to profile it; any help here would be great).

Normally 'feel' messages arrive every 100ms and 'see' every 150ms. That's
more or less what I observe when the processing of 'see' is turned off.
When it is on however, messages are received with bursts, e.g. 7 'feel'
messages within 200ms instead of 2. This is surprising because if I
believe the profiler, 'see' is usually processed in 25 to 55ms, so a delay
of 60ms should be long enough. Is it going to help if the processing of
'see' is dispatched in a separate thread ?

George


> Hello all,
>
> I'm using twisted for a realtime simulation and I'm calling
> reactor.callLater() for scheduling actions to be performed after a fixed
> short delay (~60msec). However, if there is a cpu-intensive procedure
> running in the meantime, the timer for the scheduled call may expire much
> later, an order of magnitude or more if the procedure takes too much time.
> Is this to be expected in general ? If not, does this may have to with the
> delay being too short or the cpu-intensive procedure being mainly run in
> an extension module ? Finally, is there a way to force the required delay
> (with a tolerance of a few msec) ?
>
> Thanks for any insight,
>
> George
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>