From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 1C1A94B7AD for ; Fri, 22 Aug 2025 14:51:26 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id CBD2B68E6BA; Fri, 22 Aug 2025 17:51:22 +0300 (EEST) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 1E7236801B4 for ; Fri, 22 Aug 2025 17:51:17 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 4C2104441B for ; Fri, 22 Aug 2025 14:51:16 +0000 (UTC) Date: Fri, 22 Aug 2025 16:51:15 +0200 To: FFmpeg development discussions and patches Message-ID: <20250822145115.GP29660@pb2> References: <20250819232652.GB29660@pb2> <5ee0b9e5-935c-4264-a6db-a66cfcf7ae3a@rothenpieler.org> <20250820192502.GC29660@pb2> <62ebc207-8d94-4bb1-a394-9b5aad3f6eb4@rothenpieler.org> <20250821213342.GL29660@pb2> <1b744f83-b5f0-429a-925d-3981461cea0d@rothenpieler.org> MIME-Version: 1.0 In-Reply-To: <1b744f83-b5f0-429a-925d-3981461cea0d@rothenpieler.org> X-GND-State: clean X-GND-Score: -70 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduieegtdegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdeftddmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttdelnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpeefudfhjedtgfekgfegfeetvefgfefhkedtkeefleejueefvdehgffhvdekvefhieenucfkphepgedurdeiiedrieehrddujeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieehrddujeeipdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] CI 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: , From: Michael Niedermayer via ffmpeg-devel Reply-To: FFmpeg development discussions and patches Cc: Michael Niedermayer Content-Type: multipart/mixed; boundary="===============1450004375632366753==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1450004375632366753== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qEvrLoJ8Aj2v4fN/" Content-Disposition: inline --qEvrLoJ8Aj2v4fN/ Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2025 at 02:13:14PM +0200, Timo Rothenpieler via ffmpeg-deve= l wrote: > On 22/08/2025 07:00, Kieran Kunhya via ffmpeg-devel wrote: > > On Thu, 21 Aug 2025, 11:33 Michael Niedermayer via ffmpeg-devel, < > > ffmpeg-devel@ffmpeg.org> wrote: > >=20 > > > Hi > > >=20 > > > On Thu, Aug 21, 2025 at 12:31:46AM +0200, Timo Rothenpieler via > > > ffmpeg-devel wrote: > > > > On 8/20/2025 9:25 PM, Michael Niedermayer via ffmpeg-devel wrote: > > > > > Hi > > > > >=20 > > > > > On Wed, Aug 20, 2025 at 05:56:27PM +0200, Timo Rothenpieler via > > > ffmpeg-devel wrote: > > > > > > On 8/20/2025 1:26 AM, Michael Niedermayer via ffmpeg-devel wrot= e: > > > > > > > Hi > > > > > > >=20 > > > > > > > It seems the forgejo CI takes about > > > > > > > 13min to do fate on aarch64 and x86-64 and build on win64 > > > > > > >=20 > > > > > > > Locally i run > > > > > > > fate + install on x86-64 > > > > > > > build on x86-32, mingw64, arm32, mips, ppc, x86-64 + s= hared > > > libs > > > > > > > testprogs alltools examples build on x86-64, x86-32 an= d arm32 > > > > > > > in 2min 44sec > > > > > > >=20 > > > > > > > can we improve the speed vs amount of tests ratio ? > > > > > > > (its not a problem ATM, i did in fact not even notice as i ne= ver > > > waited on it) > > > > > > >=20 > > > > > > > Iam just seeing the difference in time and i think there is > > > potential for > > > > > > > optimization here > > > > > > >=20 > > > > > > > I dont think my box here is really special, just a > > > > > > > AMD Ryzen 9 3950X 16-Core + Samsung SSD 970 PRO > > > > > >=20 > > > > > > Well, the test runners are 4 cores and 8GB of RAM. So that'll b= e the > > > primary > > > > > > difference in speed. > > > > > > I think they're performing pretty good for being just that. > > > > > >=20 > > > > > > We could of course throw money at the problem and turn them int= o 16 > > > core > > > > > > machines. That would up the hosting cost of the runners from > > > currently > > > > > > 3*7.5=A4 a month to 3*30=A4 a month. Just for the runners. > > > > > >=20 > > > > > > imo the current CI turnaround times are fine. 15-20 minutes per= job > > > is fine, > > > > > > as long as they can all run in parallel. > > > > >=20 > > > > > Option 1: 15-20 min CI turnaround, 270 =A4 per year > > > > > Option 2: 4-5? min CI turnaround, 1080 =A4 per year > > > > >=20 > > > > > we have over 150k $ it seems > > > > >=20 > > > > > Good use of capital can also lead to more donations > > > > >=20 > > > > > I think the main question is, "would we benefit from the faster > > > trunaround"? > > > > > or not ? > > > >=20 > > > > You have to keep in mind, 4 Core 8GB is also the swarm of runners w= e get > > > for > > > > free from Microsoft via GitHub. > > > >=20 > > > > So the choice is actually "Be able to process 20+ jobs in parallel = that > > > take > > > > 15-20 minutes each" vs. "Be able to process 3 or so at a time (roug= hly > > > one > > > > PR/push) in 5 minutes". > > > > So realistically, unless we also pay for an actual swarm of runners > > > > ourselves(which would cost 10k or more a year while being idle 95% = of the > > > > time) the total turnaround time including wait for a free runner is > > > probably > > > > still better with more of the smaller runners than less of the big = ones. > > > >=20 > > > > It'd also make it a lot more pressing to think about every single C= I job > > > we > > > > add, vs. having a bit of leeway due to the over-abundance of runner= s. > > >=20 > > > for 1-2k$ you can buy a box that runs fate once and build on 6 times = in > > > under 3minutes. > > >=20 > > > if one is not enough buy 3, use the extra capcity for fuzzing or rent= out > > > to other projects > > >=20 > > > I must be stupid, because to me this looks cheaper, its also one time > > > expense > > > these boxes can be used for 10 years > > >=20 > > > also no need to be reliable expensive servers, if you have 3. > > >=20 > > > thx > > >=20 > >=20 > > In the end you're paying for hosting, 24/7 electricity and not having to > > worry about it. >=20 > Yeah, in the end someone has to put these 3 servers somewhere, monitor th= em > for hardware failures, and pay for their electricity. > Which isn't exactly cheap for 3 servers either. >=20 > > I agree with both viewpoints. For "mission critical" stuff like CI we > > should host at a proper hosting company. >=20 > There's also the option of renting a dedicated server from Hetzner or some > other company, and put a bunch of runners on there. > Hetzner rents you an 8 core Zen4 Ryzen with 64GB of RAM for ~55=A4 a mont= h. >=20 > But compared to the current virtual servers we rent from Hetzner, that's a > pretty poor "performance per money" ratio, given we get one server with 4 > cores and 8GB of RAM, which is plenty for our needs, for 7.5=A4 a month. > So we can rent up to 7 of those, while still paying less than for one > dedicated server. > And dedicated servers are again more effort, because you do need to manua= lly > monitor them for any hardware faults, and then coordinate the replacement > with Hetzner, and they do eventually die of old age. >=20 > There's also the option of writing some tool that automatically scales > runners up/down at some cloud provider that bills minutely/secondly (Hetz= ner > bills Servers per Hour, making this a lot less interesting). > That would require some serious cost calculation. But I feel like we have > plenty of CI downtime to make it worthwhile. >=20 > But then again, GitHub/MS gives us 20 parallel runners for free, and we c= an > freely pick if they're running on x86_64 or aarch64, Linux, Windows or ev= en > OSX. > As long as they do that, we only need to host a baseline of runners > ourselves, and can scale out into that whenever there's a peak in usage. I guess next time i upgrade my box, i might just keep the old one running i= n a corner. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott --qEvrLoJ8Aj2v4fN/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCaKiD2QAKCRBhHseHBAsP q63nAJ90vIkajQgtUM//wWFeKCTSNiciiQCgmeW+gPge5ticGUCJxEJAnnH0ljA= =1qfZ -----END PGP SIGNATURE----- --qEvrLoJ8Aj2v4fN/-- --===============1450004375632366753== 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". --===============1450004375632366753==--