Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <f561a50b3337193fc9d375d8286e4b2e@smtp.hushmail.com>
Date: Wed, 3 Oct 2012 02:37:24 +0200
From: magnum <john.magnum@...hmail.com>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: Response during OpenCL sessions

Solar,

Now that we start to get split kernels with much shorter durations, I wonder if/how we could react to some events between the kernel calls without a lot of work. I thought it could be as simple as this pseudo code "patch":


void crypt_all(int count)
{
  	enqueue(Transfer);
  	enqueue(RarInitKernel);
  	for (i=0; i<HASH_LOOPS; i++)
  	{
  		enqueue(RarLoopKernel);
+ 		if (event_pending)
+ 			process_event();
  	}
  	enqueue(RarFinalKernel);


I tried the above, using a process_event() similar to the one in cracker.c but somehow it only works during self-test (one that preceeds a crack, not a benchmark), not during actual crack. Should I call something else first? Can it not be done this way? I thought signals and timers would work fine just with this.

If we could just get a status line swiftly after a keypress (or signal), the perception that JtR hangs will go away almost completely.

BTW, just committed: The RAR OpenCL kernel is finally split into quicker subkernels. Wasn't easy and it's still a bit slow (though it got a little boost with this new code). It even has a special limit for HD7970 at 200 ms now :)

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.