Posts: 17
Threads: 4
Joined: May 2010
06-18-2010, 01:16 PM
Code:
Threads...: 1
Speed.GPU1: 0/s (running)
Speed.GPU*: 0/s
Recovered.: 38/341185 Digests, 23/275278 Salts
Progress..: 0/98948190 (0.00%)
Running...: 3 mins, 42 secs
Estimated.: 0 secs
Hmm, strange - incorrect speed-display again ?!?
Posts: 5,185
Threads: 230
Joined: Apr 2010
it is still on position 0/98948190, wait until it increases. then it should show a value.
Posts: 17
Threads: 4
Joined: May 2010
So what`s the difference from the previous version ?
Recovered.:
38
Progress..:
0/98948190
Posts: 5,185
Threads: 230
Joined: Apr 2010
made speed display more user-friendly with dynamic suffixes means M/s, k/s or just /s depending on the speed value. old version shows M/s only which means on very low speed it would show 0M/s even it it is 10/s. in your case it is just slower than 1/s.
Posts: 17
Threads: 4
Joined: May 2010
(06-18-2010, 02:44 PM)atom Wrote: in your case it is just slower than 1/s.
This can`t be true !
Code:
Threads...: 1
Speed.GPU1: 0/s (running)
Speed.GPU*: 0/s
Recovered.: 843/341185 Digests, 567/275278 Salts
Progress..: 131072/344011 (38.10%)
Running...: 50 mins, 4 secs
Estimated.: 0 secs
50 mins x 60 sec = 3000 sec
131072/3000 = ~43 p/s
Posts: 5,185
Threads: 230
Joined: Apr 2010
Quote:This can`t be true !
uhm, moment! you changed the attack. initial post showed:
Progress..: 0/
98948190 (0.00%)
now its is:
Progress..: 131072/
344011 (38.10%)
Quote:Code:
Threads...: 1
Speed.GPU1: 0/s (running)
Speed.GPU*: 0/s
Recovered.: 843/341185 Digests, 567/275278 Salts
Progress..: 131072/344011 (38.10%)
Running...: 50 mins, 4 secs
Estimated.: 0 secs
50 mins x 60 sec = 3000 sec
131072/3000 = ~43 p/s
so this is a completly new problem. it is because you have a to little number of combinations in your attack (344011) which is done in blocks (forced by opencl) with a size of 131072 (see progress) but you have 275278 salts. so if you devide 131072 with 275278 it is < 1. since this is a integer operation the result is 0. so you can call this a problem but it will only happen if the number of salts is bigger than the number of blocks.
Posts: 17
Threads: 4
Joined: May 2010
06-18-2010, 05:05 PM
(This post was last modified: 06-18-2010, 05:06 PM by vector.)
If you think that this is normal - OK, you know better, I just want to help ...
Anyway the multihash Vbulletin attack with oclHashcat doesn`t seem really useful for the moment,at least for me. The HashCat is faster with dual core CPU than oclHashcat and OC GTX9800+ ...
Here the reslt with the same hash and word lists:
Code:
Index.....: 1/1 (segment), 344549 (words), 3131493 (bytes)
Recovered.: 1761/341183 hashes, 1165/275276 salts
Speed/sec.: 13.75M plains, 50 words
Progress..: 37144/344549 (10.78%)
Running...: 00:00:12:21
Estimated.: 00:01:42:28
50p/s vs 43p/s ...
Posts: 5,185
Threads: 230
Joined: Apr 2010
Quote:If you think that this is normal - OK, you know better, I just want to help ...
yes, please continue doing that! critic is very welcome here. just in case you understood me wrong.
Quote:Anyway the multihash Vbulletin attack with oclHashcat doesn`t seem really useful for the moment,at least for me. The HashCat is faster with dual core CPU than oclHashcat and OC GTX9800+ ...
Here the reslt with the same hash and word lists:
50p/s vs 43p/s ...
yeah well, this is however related to the to small number combinations (344549). i am sure the program printed a line like this: WARNING: words in wordlist_left < XXX
take a look into docs/performance.txt on how to avoid it.
if you use a bigger workload it is ways faster than cpu. on my hd4850 i have about 28k on 10k salted hashes. which is about 280M/s.
little hand-formula: if you want to know your speed, just try a single vb hash and then divide it by the number of unique salts (not hashes). i am sure it is much faster than cpu, much faster than 43p/s.
Posts: 5,185
Threads: 230
Joined: Apr 2010
fixed with oclHashcat v0.25 :-)