In very uneven cases you could simply reduce the extrapolation target to avoid overshoot e.g. aim for 80ms instead of 98ms. It's only taking the average frequency in very-high-frequency cases, to lighten the workload as appropriate. In low-frequency cases, you don't need any extrapolation at all.
On 3 September 2010 16:35, Martin Sustrik <[email protected]> wrote: > On 09/03/2010 05:09 PM, Naveen Chawla wrote: > >> So for example, if the timeout is 100ms. >> It starts by very briefly presuming that there's no loop, so it starts >> calling it on "every" poll call. If a loop has been detected (i.e. 4+ >> poll calls at regular intervals), it uses the time between calls (e.g. >> 10 nanoseconds) to defer the next gettimeofday call to e.g. 98ms (i.e. >> it doesn't call gettimeofday until the next 98,000,000th repetition) >> and then it uses the time elapsed since that last gettimeofday call >> (recorded 98,000,000 repetitions ago) to give us an updated loop >> speed, and how many repetitions until the next gettimeofday should be >> called again (e.g. to aim now for 99.99999ms, don't call gettimeofday >> until the 1,999,999th repetition ), and so on. > > Ah. Extrapolation. That would break the timeout functionality for the flows > that are unevenly distributed on the time axis. > > Martin > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
