Keir,

Here are the results of the testing I've done recently. There are three protocols tested. I'll call them ASYNC for the code as it stood just before your last check-in, MIXED (for ASYNC+SYNC) for the code you recently checked in, and SYNC for the method I proposed in the last mail.

Date Duration Protocol sles, rhat error

11/07 23 hrs 40 min ASYNC -4.96 sec, +4.42 sec -.006%, +.005% 11/08 28 min MIXED -.75 sec, -.67 sec -.045%, -.040% 11/08 2 hrs 21 min SYNC -.80 sec, -.34 sec, -.009%, -.004% 11/08 1 hr 25 min SYNC -.24 sec, -.26 sec, -.005%, -.005% 11/08 15 hrs 39 min MIXED -19. sec,-17.4 sec, -.034%, -.031% 11/09 3 hrs 19 min ASYNC -.13 sec, +1.44 sec, -.001%, +.012%

Each protocol was run a couple of times to gage the repeatability.

Since I had a high error (~.03%) for the ASYNC method a couple of days ago, I ran another ASYNC test. I think there may have been something wrong with the code I used a couple of days ago for ASYNC. It may have been missing the immediate delivery of interrupt after context switch in.

My results indicate that either SYNC or ASYNC give acceptable accuracy, each running consistently around or under .01%. MIXED has a fairly high error of greater than .03%. Probably too close to .05% ntp threshold for comfort. I don't have an overnight run with SYNC. I plan to leave SYNC running over the weekend. If you'd rather I can leave MIXED running instead.

It may be too early to pick the protocol and I can run more overnight tests next week.

I have attached a patch based on what's checked-in now that shows what I tested for SYNC and ASYNC. For MIXED I used the code that is checked-in now. The patch looks more complicated than the change really is as it backs out the MIXED code you put in.

Regards, Dave

Keir Fraser wrote: