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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
