Open roycewilliams opened 1 year ago
Interesting, it adds some complication to keeps those idea's in sync and maybe always resync at start up and every day or something like that. Or add a sync command to the protocol.
The agent information is at least updated on every new start of the agent (not sure right now, if it even updates sometimes in between). So on these occasions, the data which is sent could be extended by some more details from the GPUs.
Also we probably should discuss if we still read out the device information with lspci
or at least in case Hashcat is used, this information should be replaced by taking from ./hashcat -II
which would also give a more exact list of which devices can be used (as lspci sometimes lists more than what could be used, e.g. if drivers are not correctly installed).
Indeed we should not rely on hashcat, but maybe look in how hashcat determines the ID's and use that information and not something cracker depended.
When managing a large decentralized collaboration, one of the most common client problems is the need to force a specific GPU by ID - to avoid an iGPU, a hot card, etc.. It would be very useful for these IDs to be available on the server side, so that extra parameters can be implemented on the client's behalf. Today, the server operator must coordinate with each client operator to get the output of
hashcat -I
or similar to track down the correct device ID(s).Device IDs can sometimes be inferred from graph order, but this is not fully consistent / reliable. Also, the graph only appears once successful processing has started - but sometimes the only way to get it started is to specify devices. :D
The right way to manage both this and #899 might be with use of
hashcat -II
(which includes both OS and devices)