[Haskell-cafe] Thread priority?
Don Stewart
dons at galois.com
Mon Apr 27 14:15:30 EDT 2009
semanticphilosopher:
> Count me in too
>
> I've got a library that endeavours to deliver 'rate-equivalence' - i.e
> there may be some jitter in when the events should have occurred but
> their long term rate of progress is stable.
>
> Testing has shown that I can get events to occur at the right time
> within 1ms (99%+ of the time, with 50%+ of the events < 0.5ms) - choose
> your O/S carefully though. And this is without resorting to marking the
> threads as real time with the kernel. If it matters you can tune the
> scheduling to further reduce the timer scheduling latency (at the cost of
> more CPU) and increase the fidelity of event timing another order of
> magnitude or more.
>
> As for 'garbage collection ruins my real time properties' argument -
> I've been pragmatic about this, you can configure the scheduler to go
> and perform a GC if it knows that it is going to sleep for a while (yes,
> this doesn't resolve the issues of external events arriving in that time
> but read on) but not perform that too often. Turning off GHCs timers (to
> stop it garbage collecting after it has actually been idle for a while)
> and having code that doesn't create vast amounts of garbage means that a
> GC takes <0.1ms.
>
> Now if I could see within Haskell the amount of heap that has been
> recently mutated and some other GC statistics when it was running I
> could even decide to schedule that more effectively.
>
> We use this to create synthetic network traffic sources and other
> timing/performance related activities in the wide area context - it
> serves our needs.
>
This is very interesting. Do you have any further documentation / notes
on controlling jitteriness?
-- Don
More information about the Haskell-Cafe
mailing list