Just throwing ideas in there...

are you using multiple threads in the application?

are you using parralelism?

Your query seems to basically use this equation... endtime from las query - start time from first query.

I think a better equation would be sum(endtime - starttime). That eliminates an errand query in there before or after the real work to sku with those results.

That being said it still doesn't explain the ±15 fold different between the numbers, and if anything just widdens the gap

One thing that could help explain why this happening is if the server is running at 100% for the whole time of the process and assuming the server uses all 8 availble processors and that each query only uses 1 processor, you just increased your available processing time by 8.... but not 15 obviously. This means that if you have 8 queries running in exactly 1 second each, then could all be processed in 1 second REAL TIME but adding up to 8 seconds total.

One thing I first noticed back in sql 2000 (not sure if it still applies in 2005/08) is that I often had queries that run for very little time (0ms) but every once in a while like 4 or 5 runs, the server showed 13ms. I'm assuming here that there's a rounding error in there or just a weird way to calculate things.

Even if a 3 ms error is small over each query... when compounded over 68 millions queries that makes for almost 57 hours in time.

Can you check the average run time of each query? If I assume 68 M queries over 5 hours, that's only 250 nanoseconds AVERAGE. I think this could explain a great deal in your situation.

Also I may suggest that you try maybe a real ETL process here if possible... do a single, even if parrallel load into a single [set of] table and then do your thing with that data. You should be able to bring that processing time down to a couple minutes or at worse 1 hour.