Please help: 2 of the 4 290X are way too slow when performing dictionary attack
#1
I will make it as short as possible although there are many background details:

I have 4 R9 290X in total.
2 x "Asus Direct CU2 R9 290X OC" are directly connected on a MSI Z87 MB and 2 x "Sapphire ATI R9 290X" are connected via USB 1x to 16x USB risers on the same MB.

The 2 Asus, MB and Hard Disks power up via a 1100W PSU and the 2 Sapphire via a 850W PSU.

When trying pure brute force with oclhashcat (MD5: -m 0 for example), all 4 cards show/have more or less the same capabilities in terms of computing power.
On the other hand, whenever I try to do a dictionary attack (see attached where -m 1600 (Apache MD5 APR) is used), the Sapphire cards always drop at approximately to 1/3 of the Asus computing power.

I have tried numerous things to no avail. Results are always the same.
Any help will be greatly appreciated.


Note: on the attached photo GPU #1 and #2 are obviously the Asus and #2 and #3 are the Sapphire.



   
#2
pretty simple, you're not giving the gpus enough work to do.
#3
Please excuse my ignorance but isn't oclhashcat supposed to split the work to the 4 GPUs?
The dictionary attacks I have tried so far always include rules so my guess is that that's enough of intensive work to do!
Furthermore, doesn't the fact that the 2 identical GPUs work at their full capacity (vs the other ones which are of the same brand and connected via the USB risers) ring any suspicious bells?
#4
yes, oclHashcat will split the work amongst the gpus in a way that will achieve the most acceleration for the specific attack you are running. however, it has to actually have enough work to do that, else you will not get full acceleration. and it's not about intensive work, it's about the quantity of work, how the attack is structured, and the speed of the hashing algorithm.

however, you haven't really provided enough information for us to give you a definite answer. your screenshot doesn't tell us anything helpful. it would be much better if you copy/pasted (not screenshot) your command and the output of hashcat in its entirety.

no, that doesn't ring any suspicious bells. if you're getting full acceleration on brute force, then your setup is fine. the problem therefore likely exists in the execution.
#5
ok, understood.
I will provide all the info you need as soon as the current work is done.
#6
http://hashcat.net/forum/thread-2543.html

Read essential performance note.
#7
while it certainly is a good idea to sort your wordlists by length, md5apr is not one of the algorithms affected by the drop in performance nor is he using a VLIW card.
#8
could the slowing be due to the fact he is using USB and the USB is a bottle neck?
#9
USB risers don't actually use USB, they're still PCI-e. running off of a x1 slot will increase host->device transfer times, but not by that much.
#10
(07-23-2014, 04:27 AM)epixoip Wrote: USB risers don't actually use USB, they're still PCI-e. running off of a x1 slot will increase host->device transfer times, but not by that much.

well in video game sense it can seriously nerf performance. Also host transfer times is not necessary the phrase to use.

Does this just load files to vram and crunch them then transfer? or is it constantly streaming like video games?

If it loads a batch then crunches it and the loading of a batch is on and off and not constant then that isn't the issue. FYI 1x is slower than USB 3.0. 1x doesn't off much bandwidth when you are dealing with cutting edge CPUs.

Also not increase a lot is false....16x the difference is a lot.