I'm running Hashtopolis agents with this command to crack a small number (5-10) of mode 22000 hashes with rockyou + dive.rule, using --slow-candidates to keep the hash rate high:
I have Hashtopolis configured for 45 min chunks. True to the setting, once the GPU starts cracking, the chunk takes ~45 min.
However, there is a ~60 min period before that, when 1 CPU core is maxed out and hashcat reports 0.00 H/s. I understand this is the consequence of using --slow-candidates (i.e. generating the candidates on the host), but it results in significant "downtime" with the GPU idle.
What's the best way to maximize GPU uptime in such a scenario?
Would it be crazy to run 2 concurrent hashcat instances (one with a mask attack and another with --slow-candidates)? I know concurrent hashcat instances is usually silly, but I'm thinking it might actually increase average hash rate here.
Code:
-S -w4 -a0 #HL# rockyou.txt.gz -r dive.ruleI have Hashtopolis configured for 45 min chunks. True to the setting, once the GPU starts cracking, the chunk takes ~45 min.
However, there is a ~60 min period before that, when 1 CPU core is maxed out and hashcat reports 0.00 H/s. I understand this is the consequence of using --slow-candidates (i.e. generating the candidates on the host), but it results in significant "downtime" with the GPU idle.
What's the best way to maximize GPU uptime in such a scenario?
Would it be crazy to run 2 concurrent hashcat instances (one with a mask attack and another with --slow-candidates)? I know concurrent hashcat instances is usually silly, but I'm thinking it might actually increase average hash rate here.