> Sorry about that, with your clarification I see what you were trying
> to explain now. The code initializes the target time like this:
>
> thread->throttle_trigger = INSTR_TIME_GET_MICROSEC(start);
>
> And then each time a transaction fires, it advances the reference time
> forward based on the expected rate:
>
> thread->throttle_trigger += wait;
>
> It does *not* reset thread->throttle_trigger based on when the
> previous transaction ended / when the next transaction started. If
> the goal is 10us transaction times, it beats a steady drum saying the
> transactions should come at 10us, 20us, 30us (on average--there's some
> randomness in the goals). It does not pay any attention to when the
> previous transactions finished.
>
> That means that if an early transaction takes an extra 1000us, every
> transaction after that will also show as 1000us late--even if all of
> them take 10us. You expect that those later transactions will show 0
> lag, since they took the right duration. For that to happen,
> thread->throttle_trigger would need to be re-initialized with the
> current time at the end of each completed transaction.
Yes, that's exactly what I understand from the code.
> The lag computation was not the interesting part of this feature to
> me. As I said before, I considered it more of a debugging level thing
> than a number people would analyze as much as you did. I understand
> why you don't like it though. If the reference time was moved forward
> to match the transaction end each time, I think that would give the
> lag definition you're looking for. That's fine to me too, if Fabien
> doesn't have a good reason to reject the idea. We would need to make
> sure that doesn't break some part of the design too.
I would like to hear from Fabien about the issue too.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp