[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <59b7f6ed573115b2c3e0e61a16e05696@smtp.hushmail.com>
Date: Fri, 30 Aug 2013 10:12:59 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Sayantan Weekly Report #11
On 30 Aug, 2013, at 4:43 , Sayantan Datta <std2048@...il.com> wrote:
> On Fri, Aug 30, 2013 at 3:21 AM, magnum <john.magnum@...hmail.com> wrote:
>> Here's a theory: Since mask mode currently picks 26*26 == 676 as multiplier in this case, I have no choice other than to lower GWS all the way to 16384 (ending up in a KPC of 11075584) to keep kernel duration short enough to avoid triggering watchdogs and rebooting the whole thing. I presume the "low" GWS is the reason for the poor performance. Maybe it would be way better with a multipler of 26 and a GWS of 524288... in *this* case.
>>
>> Maybe the kernel can be improved (reducing need for high GWS) but regardless of that, this means auto-tuning will be trickier: You need to figure out not only the GWS but the best *combination* of GWS and GPU-side mask that completes in less than 200ms.
>
> You can set db->max_int_keys=26 in reset. This will limit multiplier to 26. Yes, device tuning can be a bit tricky. Also, it is not possible to tune mask settings in runtime with the current version. I'm hoping to fix the issue in this week.
Thanks, I now tried using 26 but my theory doesn't hold. I can't find a GWS+mask combination that is faster than 57M.
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.
