From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 416894BFAD for ; Thu, 6 Feb 2025 00:16:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0236868B9D3; Thu, 6 Feb 2025 02:16:47 +0200 (EET) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 444A168B887 for ; Thu, 6 Feb 2025 02:16:40 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 968A4442CF for ; Thu, 6 Feb 2025 00:16:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1738800999; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DJ+goREtJTcfw9CnjBvQsUyJptyL8Ffv8YaUZ21aNj4=; b=Ds2eC56dLU+tayydHf0UEyY0qY8dxa0gJVLFO2B+m3El+GIf1shS5NIMEkviIlwfWMoChV R7jIZSCWPUp87Crg+QDr6tWfK8cWFDh6E+jIQ1X7URpU4XNSAV9xNt166nl+bAzNirM8lf pSRmg0czMEP6KCW2oQJEOvK1USGdyqjtDjVxBIvxfpbYla4DV/2K+MYoCS48p4DlTVUAdh eSAb8hjdt+bFJ8sx7v3K/z7fXYCJdVXYak7yCtGJxXII4VGqzCwP3gMqzVpyW/Wd1HaWKZ O+XeH4dvgV2ncCuse63bM8pVqRLBujoQmwSOSE/PDQIx59wfCIphro4MS3Yykg== Date: Thu, 6 Feb 2025 01:16:38 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250206001638.GI4991@pb2> References: <20250205221813.4110398-1-martin@martin.st> <20250205221813.4110398-2-martin@martin.st> MIME-Version: 1.0 In-Reply-To: <20250205221813.4110398-2-martin@martin.st> X-GND-State: clean X-GND-Score: -70 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvgeekkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnegfrhhlucfvnfffucdlfedtmdenucfjughrpeffhffvuffkfhggtggujgesghdtreertddtudenucfhrhhomhepofhitghhrggvlhcupfhivgguvghrmhgrhigvrhcuoehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgeqnecuggftrfgrthhtvghrnhepudetvdfhudeuudegudefgfehhfevvdfggfffkefhvdfgvdetffdtjeekheetfeehnecukfhppeeguddrieeirdeijedruddufeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeguddrieeirdeijedruddufedphhgvlhhopehlohgtrghlhhhoshhtpdhmrghilhhfrhhomhepmhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtpdhnsggprhgtphhtthhopedupdhrtghpthhtohepfhhfmhhpvghgqdguvghvvghlsehffhhmphgvghdrohhrgh X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH v2 2/2] random_seed: Improve behaviour with small timer increments with high precision timers X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============6721761349756365245==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6721761349756365245== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lS7poo3iUqKvvJ2Q" Content-Disposition: inline --lS7poo3iUqKvvJ2Q Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Martin On Thu, Feb 06, 2025 at 12:18:09AM +0200, Martin Storsj=F6 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. >=20 > Due to the "last_t + 2*last_td + (CLOCKS_PER_SEC > 1000) >=3D 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). >=20 > 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. >=20 > 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. >=20 > 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(+) >=20 > 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] =3D { 0 }; > unsigned char digest[20]; > uint64_t last_i =3D i; > + int last_repeat =3D 0, cur_repeat =3D 0; > =20 > av_assert0(sizeof(tmp) >=3D av_sha_size); > =20 > @@ -101,8 +102,21 @@ static uint32_t get_generic_seed(void) > int incremented_i =3D 0; > int cur_td =3D 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 resol= ution > + // is high (CLOCKS_PER_SEC > 1000), require that the timer > + // incremented by more than 1. If the timer resolution is lo= w, > + // it is enough that the timer incremented at all. > buffer[++i & 511] +=3D cur_td % 3294638521U; > incremented_i =3D 1; > + } else if (t !=3D last_t && cur_repeat > 0 && last_repeat > 0 && > + cur_repeat !=3D last_repeat) { > + // If the timer resolution is high, and we get the same timer > + // value multiple times, use variances in the number of repe= ats > + // 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 [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives.= =20 -- Abba Eban --lS7poo3iUqKvvJ2Q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZ6P/YwAKCRBhHseHBAsP q9W7AKCRUkx4WA7pUyAHfd60KAjtSjwxSACfZZmN/C4MEa5P0Ox9sdErZm2iFAc= =Yd7J -----END PGP SIGNATURE----- --lS7poo3iUqKvvJ2Q-- --===============6721761349756365245== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============6721761349756365245==--