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 341AB4C8E7 for ; Sun, 9 Feb 2025 22:29:03 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6E43568BCCC; Mon, 10 Feb 2025 00:28:59 +0200 (EET) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 38C2668B206 for ; Mon, 10 Feb 2025 00:28:52 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 682BF43315 for ; Sun, 9 Feb 2025 22:28:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1739140131; 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=/qxcz1gdh2fqNUAv8UpgmmSDc5AA9ov0mmC9d0POnPA=; b=NCw4uIYiEjkjzCOCMQYKEwm6jUjm9tI2JtUQ8l4W71D/rVGRRGXB640lzYs/dZhI2SOPUr xHjDbM1OUA9JeOn8oRAS5TPETRISZH36F4FHfh6TK8LUAvDsdg8tKuA8XhX64hU/6Y3Ml/ pqjvbOB7h8uC8OeWTKQJCm1NU9J+FDaF7u/pUkkwZjW1tH7U4II9eCxm8Jzm9u5gMbSlnp nTAwAbZ+4wOZ1/pTNoIlB1tRi2e+J8C5cNUwqoDW9vb/Bpi+nu8cVaNb1a+kytZ8hTlGs7 2z2QVQNO83GSgWvd84pJ4ASNCLqV3wKVC7pmb+nqHxGN7mLyh0duL03maQTS/w== Date: Sun, 9 Feb 2025 23:28:50 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250209222850.GB4991@pb2> References: <20250205221813.4110398-1-martin@martin.st> <20250205221813.4110398-2-martin@martin.st> <20250206001638.GI4991@pb2> <20250206160443.GT4991@pb2> <317e9c7e-bc5-81dc-f036-9b1426a95b1@martin.st> MIME-Version: 1.0 In-Reply-To: <317e9c7e-bc5-81dc-f036-9b1426a95b1@martin.st> X-GND-State: clean X-GND-Score: -70 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdefieefiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnegfrhhlucfvnfffucdlfedtmdenucfjughrpeffhffvuffkfhggtggujgesghdtreertddtudenucfhrhhomhepofhitghhrggvlhcupfhivgguvghrmhgrhigvrhcuoehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgeqnecuggftrfgrthhtvghrnhepudetvdfhudeuudegudefgfehhfevvdfggfffkefhvdfgvdetffdtjeekheetfeehnecukfhppeeguddrieeirdeijedruddufeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeguddrieeirdeijedruddufedphhgvlhhopehlohgtrghlhhhoshhtpdhmrghilhhfrhhomhepmhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtpdhnsggprhgtphhtthhopedupdhrtghpthhtohepfhhfmhhpvghgqdguvghvvghlsehffhhmphgvghdrohhrgh 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="===============6384421194408926239==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6384421194408926239== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sIj/gDhrFmuQ/aUf" Content-Disposition: inline --sIj/gDhrFmuQ/aUf Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Martin On Fri, Feb 07, 2025 at 12:04:53AM +0200, Martin Storsj=F6 wrote: > On Thu, 6 Feb 2025, Michael Niedermayer wrote: >=20 > > On Thu, Feb 06, 2025 at 02:38:48PM +0200, Martin Storsj=F6 wrote: > > > On Thu, 6 Feb 2025, Michael Niedermayer wrote: > > >=20 > > > > > + // If the timer resolution is high, and we get the s= ame 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. > > > >=20 > > > > Does it still work if you check against the last 2 ? > > > > or does this become too slow ? > > > > What iam thinking of is this > > > >=20 > > > > 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 > > > >=20 > > > > 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 > > >=20 > > > Yes, that still works for making it terminate in a reasonable amount = of > > > time. I updated the patch to keep track of 3 numbers of repeats, and = we > > > consider that we got valid entropy once the new number of repeats is > > > different from the last two. > > >=20 > > > So in the sequence above, e.g. for 7,8,7,8,8,7, at the point of the l= ast > > > one, we have old repeats 8 and 8, and the new repeat count 7, which i= n that > > > context looks unique. > >=20 > > I was thinking that in 7,8,8 that 7 and 8 be the 2 least recent used > > values not 8,8 >=20 > Sure, that's probably doable too. >=20 > > that is, something like: > >=20 > > if (old2 =3D=3D new) { > > FFSWAP(old,old2); >=20 > I don't see why we'd need to check this if clause at all, it seems to me > that it's enough to have the "if (old !=3D new)" case. > If we have old2 =3D=3D new, > we'd just end up with old2 =3D old, and old =3D (previous old2 value) any= way. It was intended to be a least recent used check with 2 entries If we have a clock running and sample that in precise intervalls lets say the clock runs at 1.9hz and we sample at 10hz we would get clock: 0 0 0 0 0 0 1 1 1 1 1 2 2 2 2 2 3 3 3 3 3 3 = 4 4 4 4 4 5 5 5 5 5 6 6 6 6 6 7 7 7 7 7 7 8 8 8 8 = 8 9 9 difference: 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 = 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 = 0 1 0 Above adds no entropy after the initial entropy, this can be read forever it will not improve randomness here we have runs of repeated clock reads of 5,4,4,5,4,4,4,5,4 again we can read this as long as we want there is no entropy gained so after a 5,4,4,4 if a 5 happens thats not breaking the pattern and should not be counted as new entropy (if possible) thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. --sIj/gDhrFmuQ/aUf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZ6ksHgAKCRBhHseHBAsP qxUFAJ0dpU0EC/c4tJsZlqIrSWY7lueR0ACcDEV0vXsdXEzP9ck5A8tZOg1MMrM= =KdIu -----END PGP SIGNATURE----- --sIj/gDhrFmuQ/aUf-- --===============6384421194408926239== 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". --===============6384421194408926239==--