hashtopolis / server

Hashtopolis - distributed password cracking with Hashcat
GNU General Public License v3.0
1.45k stars 222 forks source link

[FEATURE] support to enable partial benchmarking #818

Open rixvet opened 2 years ago

rixvet commented 2 years ago

In multi GPU systems it can take quite a while to initialize all GPU's. So benchmaking tasks with frameworks like hashtopolis can take quite a chunk of time.

I would propose benchmark with only one or two active device(s) (option -d 1 in hashcat) and just multiply that amount to reflect the correct number of GPUs. With this we hopefully win time with benchmarking and benchmarks of one device reflect enough to be multiplied over the correct amount of devices in the system.

s3inlc commented 2 years ago

I understand the motivation of this idea. Though, how should this be handled when there is a heterogeneous system with different types of GPUs? The issue here is that the agents first would have to query hashcat to list all devices available on the system and then somehow has to decide which GPUs are the same and which are not. Even if the GPUs sometimes are the same, they might be named slightly different and/or depending on the installed driver(s), some GPUs are listed multiple times (as aliases). This makes an automatic handling of all these cases not that simple.

I know that benchmark caching is still a feature on the list, which should already reduce the benchmarking overhead significantly (especially when the agents are switching tasks back and forth). I think this has much more potential to reduce some benchmarking time in general.

Additionally, keep in mind that the initializing sometimes is not the slowest part, but the building of the kernel. If the GPUs are identical, this is done for the first GPU and therefore taking a bit longer and afterwards the cached binary kernel is used to initialize all the remaining ones, where the process is faster then.