Hi Martin
On Thu, Feb 06, 2025 at 12:18:09AM +0200, Martin Storsjö wrote:
> On a Zen 5, on Ubuntu 24.04 (with CLOCKS_PER_SEC 1000000), the
> value of clock() in this loop increments by 0 most of the time,
> and when it does increment, it usually increments by 1 compared
> to the previous round.
>
> Due to the "last_t + 2*last_td + (CLOCKS_PER_SEC > 1000) >= t"
> expression, we only manage to take one step forward in this loop
> (incrementing i) if clock() increments by 2, while it incremented
> by 0 in the previous iteration (last_td).
>
> This is similar to the change done in
> c4152fc42e480c41efb7f761b1bbe5f0bc43d5bc, to speed it up on
> systems with very small CLOCKS_PER_SEC. However in this case,
> CLOCKS_PER_SEC is still very large, but the machine is fast enough
> to hit every clock increment repeatedly.
>
> For this case, use the number of repetitions of each timer value
> as entropy source; require a change in the number of repetitions
> in order to proceed to the next buffer index.
>
> This helps the fate-random-seed test to actually terminate within
> a reasonable time on such a system (where it previously could hang,
> running for many minutes).
> ---
> libavutil/random_seed.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c
> index ca084b40da..adb7b1f717 100644
> --- a/libavutil/random_seed.c
> +++ b/libavutil/random_seed.c
> @@ -83,6 +83,7 @@ static uint32_t get_generic_seed(void)
> static uint32_t buffer[512] = { 0 };
> unsigned char digest[20];
> uint64_t last_i = i;
> + int last_repeat = 0, cur_repeat = 0;
>
> av_assert0(sizeof(tmp) >= av_sha_size);
>
> @@ -101,8 +102,21 @@ static uint32_t get_generic_seed(void)
> int incremented_i = 0;
> int cur_td = t - last_t;
> if (last_t + 2*last_td + (CLOCKS_PER_SEC > 1000) < t) {
> + // If the timer incremented by more than 2*last_td at once,
> + // we may e.g. have had a context switch. If the timer resolution
> + // is high (CLOCKS_PER_SEC > 1000), require that the timer
> + // incremented by more than 1. If the timer resolution is low,
> + // it is enough that the timer incremented at all.
> buffer[++i & 511] += cur_td % 3294638521U;
> incremented_i = 1;
> + } else if (t != last_t && cur_repeat > 0 && last_repeat > 0 &&
> + cur_repeat != last_repeat) {
> + // If the timer resolution is high, and we get the same timer
> + // value multiple times, use variances in the number of repeats
> + // of each timer value as entropy. If the number of repeats
> changed,
> + // proceed to the next index.Does it still work if you check against the last 2 ? or does this become too slow ? What iam thinking of is this 7,8,7,8,8,7,8,7,8,8,7,8,7,8,8,7,8,7,8,8,... and a 9 or 6 or further distant would trigger it I assume both the CPU clock and the wall time are quite precisse so if we just compare them the entropy could be low even with 2 alternating values thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
