-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inaccurate Device Listing, Hash Rate and Time Prediction #11
Comments
Did you use the prebuilt binaries or build it yourself? |
So I have been experiencing the same problem word for word as the original poster using my Radeon HD5830 using both Windows 7 Ultimate 64bit and Ubuntu 12.10 64bit (mostly Ubuntu but windows to troubleshoot to no avail). To find an 8 character prefix it tells me about 13 minutes at 670MH/s but it just runs indefinitely so far... Last night I tried to run the command "mono scallion.exe -d 0 .......abcdefghi" and it predicted 7:20:00 however when I came back it was running for 9:54:00 so I ended it as it seemed it would go on infinitely. Outputs: Here is the output of mono scallion.exe -l /scallion-master$ mono scallion/bin/Debug/scallion.exe -l Id:1 Name:Intel(R) Core(TM)2 Duo CPU E7200 @ 2.53GHz Here is the output of mono scallion.exe -n -d 1 4444 which performed faster but theoretically should be slower: /scallion-master$ mono scallion/bin/Debug/scallion.exe -n -d 1 4444 Ding!! Delicions scallions for you!! Exponent: 50185735 -----BEGIN RSA PRIVATE KEY----- init: 300ms / 1 (300ms, 3.33/s) 6.81 million hashes per second Here is the output of mono scallion.exe -n -d 0 4444 which performs slower but theoretically should be faster: /scallion-master$ mono scallion/bin/Debug/scallion.exe -n -d 0 4444 CPU checking hash: 2sbwn5kvfqtsicog 103.09 million hashes per second So after many days of trying to install scallion and get it to run without errors, alas a few of us appear to still be getting stuck. Any help from the community is appreciated and I have enjoyed learning from all of you - Thank you! David |
I've been having trouble getting Scallion to compile the kernel on my Thanks, On Thu, Jul 18, 2013 at 3:44 PM, davidtopeer [email protected]:
Eric Swanson |
Unfortunately, I won't be able to work on this tonight. My second dev Sorry for the false hope, and I'll get back to you all after the weekend. On 06/29/2013 02:52 PM, intelselk wrote:
Eric Swanson |
Thanks for looking into this with us. I will give it another go here mid week and see if I can't tweak something to get it working better. (totally novice when it comes to this stuff but its worth a go) |
Thanks for scallion. Using the prebuild on Windows 7 64bit, I did eventually get a result, but saw symptoms similar to OP and David, but with a slight difference. Checking for an 8 char prefix, let's call it 'xxxxxxxx', scallion would cpu check matching 7 char prefixes. At first I was seeing a newline for each iteration, with the odd CPU check interjected. for example:
At iteration 18286 it switched to updating the line in place (iteration, hashcount, speed, runtime), and only starting a new line for a CPU check:
There were 38 CPU checks from iteration 19889 (above) to 115574 (below) inclusive, until finally:
For completeness:
I will also try with -n and report back. Edit: Lower hash rate with -n (and didn't output a line per iteration this time, just per CPU check):
|
Maybe I was just unlucky the first time. For a second run (without -n): Runtime:04:11:05 Predicted:03:46:47, so pretty close. Only newlined when CPU checking (so don't know what that was the first time). It's still CPU checking 7 char matches, but in some ways it's actually encouraging to see it making progress! |
Hmm I still seem to be stuck > 24 hours for anything more than 6 characters, running at 600Mh/s or greater. |
I just got access to a Ubuntu box with a Radeon HD 5450 (low end card). I was unable to replicate the issue. I am going to install windows and see if I can replicate. Anyway, this is just an update to let ya know the issue is being worked on. I take it you both have the newest drivers? |
I have this problem also, on windows 8 and linux with catalyst 13. Seems like the gpu is hashing incorrectly. I see the same issue with oclvanitygen. |
I am having a similar issue. I've got a machine running a 4770k with onboard GPU as well as 2x7950's. Hashing seems to work great (albeit slower) on the onboard nvidia gpu but when hashing to the ATI's I am unable to get the ati's to produce results in line with expectations. Noticed 2 variables:
OnBoard: PCI-e: Using pre-compiled Scallion-v1.0. I can post the scallion output if youd like. Lachesis/Eric- If there's any value to having access to a box with higher-end hardware for testing purposes, I can give you access to a box with your choice of windows/debian some time in the next week. I would just need to find a box that i can drop the cards into for you to play with. As a matter of curiosity, is there any method by which this hashing algorithm could be applied to a BFL asic? I've got a jalapeno that was delivered as part of a "thank you" from one of my customers and I have limited interest in running it as a BTC miner but would like to use it on other projects. It seems like offering a "service" that would hash .onion domains would be something nice for the community. That being said, I have no idea if the 2 alg's are similar at all so I may be totally off base with this. Edit: tested with latest beta driver (13.250.18.0) and seems to have the same issue as before. |
I've fixed it! At least on my configuration, which is a Radeon HD5770 on Ubuntu 13.10 using amd-catalyst-13.11-beta6-linux-x86.x86_64.run. I had to downgrade to the 2.7 SDK. Also, I kept having bugs with fglrx, but I got that squared away too. I got the fix from samr7/vanitygen#19. Steps:
$ sudo update-grub
Please let me know if this fixes your problems. |
I am using latests Amd drivers 13.35 beta with SDK 2.9 and I have this 'hash doesn't match problem' too. I will give a try if the 2.7 solves the problem. |
Since @AreYouLoco didn't follow up, It looks like 13.35 beta with SDK 2.7 is the winning combination, at least on Saucy. Thanks for the great tool! |
Since @wywin is making wrong conclusions:D I tried with SKD 2.7 and the error remains. Even tried different versions of scallion. Latests git, version 0.9 and 1.2. Still same problem but version 0.9 is just making output with wrong addresses. So the problem is not related to version. I think that it is driver related. I will check with some older driver version and put result. P.S. |
It is also happening with the built-in OS X OpenCL on Mavericks. |
Im +1 with @alexandrvicente |
I get it on Windows too with v2 |
@vlad259 Do you get it with version 1.2 ( https://github.com/lachesis/scallion/raw/binaries/scallion-v1.2.zip )? Trying to figure out if its a regression in v2? |
Hi, yeah same deal with 1.2. Thanks for taking a look at it. |
@vlad259 Unfortunately I think its a driver bug :( Read lachesis last comment above. Try downgrading or upgrading drivers. If you just need a short address you can do it on the CPU. I am currently traveling and very far from my windows dev box (OpenCL does not work over remote desktop). If you find a working combination please post it here to help others. |
Richard Klafter:
Richard Klafter:
Then maybe generating a diff file with the current driver will save a Please give me some time to do that because I have a-lat-a other stuff Cheers. |
Program runs as expected, had success at finding 4 character prefix. However it takes much longer than expected. No success at finding 5 character address after 2+ hours on a HD6850 running at 590MH/s. Windows 8.
Update
Inaccurate Device Listing, Hash Rate and Time Prediction
System: Windows 8, Intel E7400 @ 2.8GHz, HD6858 ASUS.
Result:
From This point, I assume device 0 is the GPU and 1 is my CPU.
If I run:
Result:
If I run
Result:
When I run a seven digit prefix with -d 0, the hash speed boost up to 580MH/s. However, the program would run for hours with no result.
When running a seven digit prefix with -d 1, the program returns with a results with average of 14 minutes.
The text was updated successfully, but these errors were encountered: