[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGSLPCbg3sL5MBHnjmjz_68RGxiAYCR33N1cJZDk+Hz4g4hvWw@mail.gmail.com>
Date: Sat, 3 May 2025 00:14:49 +0530
From: Pentester LAB <pentesterlab3@...il.com>
To: john-users@...ts.openwall.com
Subject: Inadequate GPU VRAM Utilization in John the Ripper (OpenCL) – Optimization Inquiry
Dear John the Ripper Development Team,
I am conducting performance evaluations of GPU-accelerated password
cracking using John the Ripper (JtR) with OpenCL support. While testing,
I’ve observed that JtR does not effectively utilize GPU VRAM when run
without `--fork`, despite using OpenCL formats and correct device
selection. In contrast, Hashcat fully engages GPU VRAM under similar
workloads.
Observed GPU VRAM Usage (JtR - normal run, no `--fork`):
nvidia-smi --query-gpu=memory.used,memory.total --format=csv
memory.used [MiB], memory.total [MiB]
1498 MiB, 24564 MiB
This low usage persists during actual cracking. Meanwhile, Hashcat commonly
uses 10–15 GB of VRAM for equivalent jobs. I have confirmed that --fork
improves CPU thread scaling, but my testing is focused on single-instance
runs without `--fork`, where JtR fails to engage GPU memory meaningfully.
Request for Clarification:
1. Is GPU VRAM underutilization expected in non-forked JtR runs using
OpenCL?
2. Are there flags or configuration options to force or encourage higher
GPU memory usage, similar to how Hashcat allocates workload?
3. Can VRAM utilization be tuned via kernel batch sizes or custom OpenCL
tweaks?
4. Is there a recommended approach to achieving full GPU engagement during
cracking, outside of --fork?
Thank you for your time and support.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
