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 A3DFB4C9E8 for ; Mon, 10 Feb 2025 13:55:08 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 10B9B68B8C9; Mon, 10 Feb 2025 15:55:05 +0200 (EET) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2F5F068B6FB for ; Mon, 10 Feb 2025 15:54:58 +0200 (EET) Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-5450cf3ef63so903795e87.1 for ; Mon, 10 Feb 2025 05:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=martin-st.20230601.gappssmtp.com; s=20230601; t=1739195697; x=1739800497; darn=ffmpeg.org; h=mime-version:references:message-id:in-reply-to:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=LCf6AxcdY1WPU4/9Z7zb9l4qlJCoOR+LZillnp45iXI=; b=ATjFcd2oKIQGJg2z77RU2ObDav9vSGUALvOvuUXvbanSMBnEPIPlykwAO04RHXeUVN ZcVkEGjavWAPS5cOk2YclXWyKpodKereynTiyoRGodOKtW1yBngsa+e367ZMTufHZ/2m H32YkrysBJKoOhorWHOsHg8D8/9lk3ZUHWPoIREWHjL3VXKwO+UwuzcRhpgf3MXLxIfc kTakBs4eecAAfHbLMM59/pwp8acL6hutmWO64rW/jo+SNYn326nP2xkVL/NKTQBVjyYP wovPNieqswgxD7ms6qON8vkBxG01aOhFqsG7U1hRG146WDyEgOxmj8tM3ucg96HfKU5t voKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739195697; x=1739800497; h=mime-version:references:message-id:in-reply-to:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LCf6AxcdY1WPU4/9Z7zb9l4qlJCoOR+LZillnp45iXI=; b=oQNhkWXwCASX7DikxwFQvMOSn32bCAF/ns44usQUPHIBeqQAgVMUGhkMjLUjZ8Lm/5 wmt3Tpwbm56X3vpenQbMHRNaeowcEGa/uJk/u5ZfAOnXA+pDhq56TsMDRX5CxDWJAKlg 1CS2TBftfK+I72fUyvK1fAn79UHcjOZu8V1rLo700HDHgyw7kVVyMrOFzBA/NjAvAHfk xzyPq4k37o12YQDyhWrS/A6stDKFM5HJpx1SRdc+AbF4qkK1dP+C0tTFX5uYAWnf0mmy ayX348Mojr4eZ3432pVox3utqoIcnhsimR7VGDF3GYtkSxFQRPHAEUiyyNEub8wFtMx9 asWA== X-Gm-Message-State: AOJu0Yx+6G9/PVNx0+yQZWacF4mL6g6P1Z+1jop3h7JhqV6EGeACwtZE Qubfgf2yzzetLnXU61UnexZz9hOT3VNVAYgjfPmKHlnj4yrxWoJPctL3GUO4jVs/vTOX7IZLcSW p4w== X-Gm-Gg: ASbGncuS1U7LXRe5ZM35ULZKnYjlhh1PFNXK0Pm4kfwog2u32P4pjSmpBnMqYIyOGWL i6OLIM8W8RrDgzOYEoy8FZ1ZuAlvOF3jNJHxOaaJDGN4+Gl0JkuA3BGZ+zpHOp3+aamDlc/5D7V FYIWZtAVweelsoS97lGWzSyVfWMiPAUwRVAN3XckC4XkX2czMv9DEQTZ20NWtw07OMjaAQr16kl 3s8MAGOhMpYyLOS8Pwejq7ZyTCFiz32HfYUY1+v0QdU0ZrZrbagVQfAxOoIDuLiA3uiSpfzgcay QhSfbhJ4crZWl2e+iNK5ScpezLg/DElUY0TAqofSMvxXjgkpgu4vQ2mX4CC6MYGsepmyhsoaQSb FI/gzX0Lz+Gk= X-Google-Smtp-Source: AGHT+IGm8+KcBVmXt7u3CO3VjG9ywe5xqDbS71cfWQZfdeP/7nxShXX2JMuI3X0TkqFk6O4gep2X6w== X-Received: by 2002:a05:6512:3ca8:b0:545:61b:c84b with SMTP id 2adb3069b0e04-545061bc89bmr2980009e87.32.1739195696845; Mon, 10 Feb 2025 05:54:56 -0800 (PST) Received: from tunnel335574-pt.tunnel.tserv24.sto1.ipv6.he.net (tunnel335574-pt.tunnel.tserv24.sto1.ipv6.he.net. [2001:470:27:11::2]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-545081c5ac7sm555197e87.248.2025.02.10.05.54.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Feb 2025 05:54:56 -0800 (PST) Date: Mon, 10 Feb 2025 15:54:51 +0200 (EET) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: <20250209222850.GB4991@pb2> Message-ID: <2ddaa6c8-711e-e23c-8d3b-673d2042bf79@martin.st> 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> <20250209222850.GB4991@pb2> MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Sun, 9 Feb 2025, Michael Niedermayer wrote: > Hi Martin > > On Fri, Feb 07, 2025 at 12:04:53AM +0200, Martin Storsj=F6 wrote: >> On Thu, 6 Feb 2025, Michael Niedermayer wrote: >> >>> On Thu, Feb 06, 2025 at 02:38:48PM +0200, Martin Storsj=F6 wrote: >>>> On Thu, 6 Feb 2025, Michael Niedermayer wrote: >>>> >>>>>> + // 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 rep= eats 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 d= istant would trigger it >>>>> >>>>> I assume both the CPU clock and the wall time are quite precisse so i= f we >>>>> just compare them the entropy could be low even with 2 alternating va= lues >>>> >>>> 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. >>>> >>>> So in the sequence above, e.g. for 7,8,7,8,8,7, at the point of the la= st >>>> one, we have old repeats 8 and 8, and the new repeat count 7, which in= that >>>> context looks unique. >>> >>> I was thinking that in 7,8,8 that 7 and 8 be the 2 least recent used >>> values not 8,8 >> >> Sure, that's probably doable too. >> >>> that is, something like: >>> >>> if (old2 =3D=3D new) { >>> FFSWAP(old,old2); >> >> 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) an= yway. > > 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 shou= ld > not be counted as new entropy (if possible) Yes, I get that intent. It's just that your suggested pseudocode seems unnecessarily complex, or = I'm missing something: if (old2 =3D=3D new) { FFSWAP(old,old2); } else if (old !=3D new) { old2 =3D old; old =3D new; } If we have the sequence "5, 4, 4, 4, 4", followed by another "5", we have = old2 =3D=3D 5, old =3D=3D 4, new =3D=3D 5. Then we get the same end result = (old2 =3D=3D 4, = old =3D=3D 5) both if we execute the code you suggest above, and if we just = execute this: if (old !=3D new) { old2 =3D old; old =3D new; } Or is there something I'm missing? I don't see the need for the FFSWAP = case. As long as we check (new !=3D old && new !=3D old2) we should pick up actua= l = deviation from the steady state but not the variance between two values. // Martin _______________________________________________ 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".