Problem using -l option with double nvidia cards

[phrst]

I'm having a strange speed problem when using the -l option. I have two nvidia gtx260 cards. Setting the limit some numbers causes one of the card to run much slower than normal. To illustrate:

Code:

./oclHashcat64.bin -l  30000 hashes.txt  ?l?l?l?l  ?l?l?l?l?l

Threads...: 2, running
Speed.GPU1: 557.11M/s
Speed.GPU2: 131.38M/s
Speed.GPU*: 688.49M/s

See the speed on GPU2?

Here is what it looks like without the -l option:

Code:

./oclHashcat64.bin hashes.txt  ?l?l?l?l  ?l?l?l?l?l

Threads...: 2, running
Speed.GPU1: 557.08M/s
Speed.GPU2: 547.86M/s
Speed.GPU*: 1104.95M/s

I can replicate this every time, but it seems to be random which GPU runs slow. Half of the time it's GPU1 and half the time GPU2.

But when fiddling with the values, I see that some values are better than others. -l 32768 causes the slow GPU to run at 250M/s and with -l 65536 I get full speed.

I haven't seen anything about the -l option being optimized for certain values. Is this the case, and in that case how do I determine what values to use?

[atom]

the -l parameter is only needed if you want to split the workload to work on gpus of multiple computers. otherwise you do not need to set it. the optimum value depends on the number of computers, the number of cards, the number of SPs of each card per computer, the number of all combinations, the left and the right mask, the -n parameter and the -s parameter. it also depends on if you are on ATI or on NV, because the number of threads are diffrent. but if the value is big enough it is not so important. but generally values that are power of two are good. but if they are to small some gpu power is just wasted.

[phrst]

Here are my thoughts on this subject.

From what I gather the -l value works like this:
If I set -l 1000, it does not mean that it will test 1000 strings. Rather it will test 1000*(combinations in the right mask) strings. So
-l 1000 ?l?l?l?l ?l?l
will search 1000*25*25 strings before stopping.
I haven't found this documented anywhere, but from playing with the commands this is what it looks like.

This means that the more combinations you have in the right mask, the less granularity the -l option gives you. With a right mask of ?l?l?l?l?l, you can only set the limit to multiples of 9765625.

In the docs you recommend using a left mask of length 4. But going by this heuristic, the longer the string I want to bruteforce the longer the right mask will be. But this also increases the smallest size of the limit we can set (particularly since any -l value of less than 65536 seems to reduce my total speed by at least 25%).

For the things I'm working on I need to partition the search spaces. But the above problems make the -s and -l options pretty useless for me. So I think I will try to partitioning the search spaces manually through the masks, this:
?l?l?l?l ?l?l?la
?l?l?l?l ?l?l?lb
...
?l?l?l?l ?l?l?lz
and so on. Since this seems to have lower impact on performance.

[atom]

Here are my thoughts on this subject.

From what I gather the -l value works like this:
If I set -l 1000, it does not mean that it will test 1000 strings. Rather it will test 1000*(combinations in the right mask) strings. So
-l 1000 ?l?l?l?l ?l?l
will search 1000*25*25 strings before stopping.
I haven't found this documented anywhere, but from playing with the commands this is what it looks like.

This means that the more combinations you have in the right mask, the less granularity the -l option gives you. With a right mask of ?l?l?l?l?l, you can only set the limit to multiples of 9765625.

that is correct, both! making -s more precise is listed in my todo.txt. maybe this is possible for -l, too.

In the docs you recommend using a left mask of length 4. But going by this heuristic, the longer the string I want to bruteforce the longer the right mask will be. But this also increases the smallest size of the limit we can set (particularly since any -l value of less than 65536 seems to reduce my total speed by at least 25%).

For the things I'm working on I need to partition the search spaces. But the above problems make the -s and -l options pretty useless for me. So I think I will try to partitioning the search spaces manually through the masks, this:
?l?l?l?l ?l?l?la
?l?l?l?l ?l?l?lb
...
?l?l?l?l ?l?l?lz
and so on. Since this seems to have lower impact on performance.

oh no, this is just a recommendation for best performance. it is not a requirement. you can of course set a mask to the length 5, 6 or 7. best left side lengths are 4, 8 and 12. setting it to 8 sometimes is better than 4. but dont make right side to small. btw, nice workaround, should work.