Re: [FFmpeg-devel] [PATCH v2 2/2] random_seed: Improve behaviour with small timer increments with high precision timers

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3394 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".