From: "Martin Storsjö" <martin@martin.st> To: ffmpeg-devel@ffmpeg.org Cc: michael@niedermayer.cc Subject: [FFmpeg-devel] [PATCH v2 2/2] random_seed: Improve behaviour with small timer increments with high precision timers Date: Thu, 6 Feb 2025 00:18:09 +0200 Message-ID: <20250205221813.4110398-2-martin@martin.st> (raw) In-Reply-To: <20250205221813.4110398-1-martin@martin.st> 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. + buffer[++i & 511] += (cur_repeat + last_repeat) % 3294638521U; + incremented_i = 1; } else { buffer[i & 511] = 1664525*buffer[i & 511] + 1013904223 + (cur_td % 3294638521U); } @@ -110,6 +124,12 @@ static uint32_t get_generic_seed(void) if (last_i && i - last_i > 4 || i - last_i > 64 || TEST && i - last_i > 8) break; } + if (t == last_t) { + cur_repeat++; + } else { + last_repeat = cur_repeat; + cur_repeat = 0; + } last_t = t; last_td = cur_td; if (!init_t) -- 2.43.0 _______________________________________________ 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".
next prev parent reply other threads:[~2025-02-05 22:18 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-02-05 22:18 [FFmpeg-devel] [PATCH v2 1/2] random_seed: Reorder if clauses for gathering entropy Martin Storsjö 2025-02-05 22:18 ` Martin Storsjö [this message] 2025-02-06 0:16 ` [FFmpeg-devel] [PATCH v2 2/2] random_seed: Improve behaviour with small timer increments with high precision timers Michael Niedermayer 2025-02-06 12:38 ` Martin Storsjö 2025-02-06 2:08 ` [FFmpeg-devel] [PATCH v2 1/2] random_seed: Reorder if clauses for gathering entropy Michael Niedermayer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20250205221813.4110398-2-martin@martin.st \ --to=martin@martin.st \ --cc=ffmpeg-devel@ffmpeg.org \ --cc=michael@niedermayer.cc \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git