Date: Thu, 25 May 2017 23:23:16 +0200 From: magnum <john.magnum@...hmail.com> To: john-users@...ts.openwall.com Subject: Re: CL_OUT_OF_RESOURCES error with --format=dmg-opencl On 2017-05-25 16:49, B B wrote: > I have been experiencing some errors on startup, and also a decrease in p/s. Also I can no longer specify GWS on the command line as this causes an error also. Without declaring GWS I seem to have to wait out or make multiple attempts before the process proceeds without error. I presume you are now using a version newer than May 15 (or more specifically commit ff70033e or newer)? Did you re-configure and "make clean" prior to building? Just so we don't spend time chasing ghosts. > Here are the errors: > > OpenCL CL_OUT_OF_RESOURCES error in common-opencl.c:1515 - WaitForEvents failed—this happens with or without specifying GWS > > OpenCL CL_OUT_OF_RESOURCES error in common-opencl.c:1820 - Error creating command queue— seems to happen randomly > > I tried using GWS to get back the performance I had before the changes, which decreased by almost a third from 728 to 500. > > The specifying of a GWS number worked well previously. > I figured that you would like to know about these errors regardless. Strange, it works for me (weak laptop GPU) with or without specifying LWS and/or GWS. What if you specify both, eg. "LWS=64 GWS=4096 ./john ...", are you still getting an error? You really shouldn't. The real WTF here is the old bad single-call kernel, with a duration 50 times longer than what is kosher. I have plans to rewrite this format to use our newer split kernel. Maybe I'll have time to do so next week or so. > Thanks for your work! > Let me know if this should be/have been posted to GitHub > > > Bill Opening a new issue with the info above is probably a jolly good idea so I get a reminder of this problem. Thanks, magnum > -- >> On May 10, 2017, at 3:23 PM, magnum <john.magnum@...hmail.com> wrote: >> >> On 2017-05-11 00:11, B B wrote: >>> On May 10, 2017, at 1:32 PM, magnum <john.magnum@...hmail.com <mailto:john.magnum@...hmail.com>> wrote: >>>> A part of the problem is likely that your hash has a lot higher number of iterations than what is auto-tuned for and you get bitten by the kernel duration watchdog. We should definitely auto-tune for actual loaded hashes, not test vectors - but that's not implemented yet for this format. >>>> >>>> Try running for a while with really low GWS just to see if it evades the error: >>>> >>>> GWS=1024 ./john —inc=custom —format=dmg-opencl hashfile —mask=?w?d??d?dknownword >>>> >>>> If 1024 doesn't work, halve it until it does. >>>> If 1024 works fine, try doubling it until best speed with no error (or until no speedup from doubling). Note that it's fine to stop a session with some GWS and resume it with some other, ie. >>>> >>>> GWS=64 ./john —inc=custom —format=dmg-opencl hashfile —mask=?w?d??d?dknownword >>>> ... >>>> <job stopped> >>>> ... >>>> GWS=128 ./john -restore >>> >>> Success! >>> >>> I tried GWS=1024, then went to 4096. At 4096 my p/s increased 5 fold up to 715p/s from 128p/s. >>> >>> Thats very impressive >>> >>> For the heck of it, since we were declaring only GWS instead of LWS and GWS, I tried GWS=8192 and replicated the error. I suppose I could pump it up a little more or try half again but will probably leave it at 4096 and watch for your eventual updates in GitHub for this particular issue. My latest ETA has moved from late June to 9 days out. >>> My desktop IS very slow now. So I may incrementally lower the single kernel invocation as stated in the README, however the performance increase is quite nice, thank you. >>> >>> 10 years of data might be worth a second video card ;) >>> >>> Thanks magnum >> Cool, I'm glad it was that easy. Watch https://github.com/magnumripper/JohnTheRipper/issues/2538 for updates. >> >> magnum >> > >
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.