vcl woes

[atom]

When I tried the v1.17 vcl it worked without special vclHashcat binaries. But it looks like I didnt test enough, since many people report its not working. So as epixoip already said, I will add it back in the next version. Someone should inform Amnon btw

[magnum]

For me, oclHashcat runs fine for about 4h and then bugs out with "ERROR: clEnqueueNDRangeKernel() -6". It can then be resumed for another 4h (this time frame seems to be fairly constant). Is that the problem others have had?

[epixoip]

It means your broker ran out of memory. The only person I know who has had this problem ended up having a misconfigured network, where he tried to multi-home each node but he put the second NICs on a separate subnet that was routable back to the primary subnet, so the broker was having to handle multiple replies from each host for each kernel execution. So make sure your VCL traffic is on an isolated network.

[forumhero]

can't seem to get the broker to run properly on a compute node. but that's ok, the vm alternative seems to be working good enough.

[forumhero]

OK, so today I tried it with Ubuntu 12.04, Cat 12.8 and VCL 1.17. Now it works. I just have two minor issues:

1. Testing with crypt-md5, speed is very low unless I use a large figure for -n. Is this expected? Connection is gigabit copper. I tried bumping --gpu-loops (or whatever it's called) instead but that did not do it. With a max -n (which is possibly auto-tuned down, right?) I seem to get about same speed per GPU as when running locally.

2. Key-press does not work! Anyone else seen that? Eg. if I press 's' for status, the s gets echoed but nothing else happens. If I abort with ctrl-c I do get a status report showing everything did run as it should, so the session/restore feature made my day :-)

Pretty impressing stuff anyway.

I'm experiencing the same. hopefully it gets worked out on next release

[magnum]

It means your broker ran out of memory. The only person I know who has had this problem ended up having a misconfigured network, where he tried to multi-home each node but he put the second NICs on a separate subnet that was routable back to the primary subnet, so the broker was having to handle multiple replies from each host for each kernel execution. So make sure your VCL traffic is on an isolated network.

Thanks. It is a memory leak (in the oclHashcat process) for sure, but I see no problem with the network setup and I also do not see anything bad using tcpdump.

For now I gave an "ulimit -v $((1024*1024*16))" and run it in a bash "until...do" loop. It bails out and resumes every 45 minutes :-)

[epixoip]

yeah, rurapenthe thought it was a memory leak, too. bitched about how the oclHashcat process was leaking like a sieve. turns out, it was his misconfigured network the whole time.

so if you're seeing what appears to be a memory leak, it's definitely not a memory leak. you have something else going on.

[magnum]

if you're seeing what appears to be a memory leak, it's definitely not a memory leak. you have something else going on.

That doesn't make sense, it is definitely a memory leak. But sure, it's likely caused by something else. I never meant to imply it's a bug in oclHashcat, only that the growing memory use is seen in the oclHashcat process in top. I can't see anything wrong with the network - is there anything special I should look for? All hosts are on same L2 segment and same L3 subnet. /etc/vcl/nodes contains IP addresses (not host names). ARP table looks fine, tcpdump looks fine to my eye. No IP aliases or other interfaces are in use.

Is there even any point in investigating this until Atom releases a vclHashcat again?

[atom]

Is there even any point in investigating this until Atom releases a vclHashcat again?

Sorry I didnot follow the thread since it was about VCL mostly. I will release a VCL specific hashcat binary in the next version again, yes. Anything else i need to know?

[epixoip]

That doesn't make sense, it is definitely a memory leak. But sure, it's likely caused by something else. I never meant to imply it's a bug in oclHashcat, only that the growing memory use is seen in the oclHashcat process in top.

A memory leak is not simply steadily-increasing memory utilization -- it is a specific bug condition in which memory allocated is never freed. It is a bug caused by a programming error.

Regarding your configuration: are you using multiple network interfaces on each system in an attempt to multi-home them?