Date: Sat, 5 Sep 2020 21:16:40 +0200 From: magnum <john.magnum@...hmail.com> To: john-users@...ts.openwall.com Subject: Re: rar-opencl performance On 2020-09-04 10:02, Solar Designer wrote: > On Fri, Sep 04, 2020 at 01:50:02AM +0200, Axymeus wrote: >> Alright, looks like Windows 10 is not properly reporting GPU usage >> when running a PowerShell command... Looking at Afterburner I can see >> that both cRARk and JTR are actually using 100% GPU, but not >> constantly. There's a brief spike and a brief pause, but a much longer >> pause between each spike with JTR. CPU usage is about the same. Here >> is a visual comparison https://i.imgur.com/gIOBKeA.jpg on the left of >> the graph usage cycle of cRARk and on the right usage cycle of JTR. > > OK, so it's possibilities 1 or 2, but not 3. (Of those I listed below.) > >> Unfortunately I won't be able to provide the archive being used. And >> I'm not sure how to produce an equivalent, but I could give it a shot. > > magnum, do you have any advice for Axymeus on what parameters of the > archive to look up and how, and how to replicate those? Axymeus, please post the result of "unrar vt <archive name>". My guess is this is a very large "stored" file. I believe cRARk will process such files fully on GPU if possible, while we will not - as of now. We could definitely implement that, I just never considered it worthwhile because it's so uncommon. Thanks, magnum >> On Fri, Sep 4, 2020 at 1:31 AM Solar Designer <solar@...nwall.com> wrote: >>> >>> On Fri, Sep 04, 2020 at 01:18:56AM +0200, Axymeus wrote: >>>> cRARk goes up to 20K p/s on this archive. >>> >>> This can mean one of several things: >>> >>> 1. cRARk handles the archive smarter, rejecting candidate passwords >>> earlier. We do have early-reject in many cases, but apparently not >>> working as effectively in yours. If this is the case, then it's >>> something magnum (a JtR developer) will want to improve in our >>> rar-opencl format, I guess. You might want to provide to him a copy of >>> the archive - or preferably another "equivalent" archive with a known >>> password and no sensitive content. >>> >>> 2. cRARk handles the archive incorrectly, rejecting candidate passwords >>> early too aggressively, and might produce false negatives (miss the >>> correct password). >>> >>> 3. cRARk implements full archive processing on GPU now - probably not >>> the case. >>> >>> I guess #1 is most likely the case. >>> >>> What GPU utilization do you observe when cRARk is running on this >>> archive? And CPU too? This might give us a hint. >>> >>> Alexander >
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.