Comment 1 for bug 597054

This is probably something to do with the way that we implement the periodic scan threads using timers (by "gain" I assume the scan periods are slightly too long, not too short). We do subtract the time it takes to process all the records from the timer delay, but the result still has to be quantized and I'm pretty sure that the pthread_cond_timedwait() that this eventually calls on Linux only has to guarantee to delay for that minimum time interval and is likely to wait for longer than requested. It looks like we do *not* adjust for the overhead associated with calculating the delay though, so it should be possible to be more accurate by enhancing the periodicTask() routine in dbScan.c by measuring that overhead as well.