Is the pool down? My miner's are all getting connection errors
Argh, pushpool went mad in a new and original way and I was not there to handle the situation... The pool is back up now, I'm really sorry about the downtime. It is a well known fact that pushpool has several issues, but unfortunately at present it is the only general-purpose pool software that supports scrypt as proof-of-work, so the only thing I can do is trying to debug it. |
|
|
|
|
The latest release (12/24) of the miner brings a little speed increase (about 1%) for all architectures, and an additional boost for 64-bit Intel CPUs (you must be using a 64-bit OS).
SAC was able to produce a binary for Mac OS X 10.6/7 (link now available in the first post), but we still don't have a binary for Windows (diki is on an extended vacation). If anybody has some experience with mingw-w64 and wants to give this a try, please let me know.
|
|
|
|
I'm trying to run the optimized miner on Windows 7 64 bit, and it just crashes immediately without any error messages.
I see this in the system (application) event log:
Faulting application name: minerd.exe, version: 0.0.0.0, time stamp: 0x4eef5c94
Faulting module name: pthreadGC2.dll, version: 2.8.0.0, time stamp: 0x4be6d174
Exception code: 0xc0000005
Fault offset: 0x00000000000036a3
Faulting process id: 0x149c
Faulting application start time: 0x01ccc39bb160b781
Faulting application path: C:\Program Files (x86)\Litecoin\new_miner\minerd.exe
Faulting module path: C:\Program Files (x86)\Litecoin\new_miner\pthreadGC2.dll
Report Id: ef0fea24-2f8e-11e1-9e5e-14dae96c0870
So far I have been successfully using the miner-i7.exe release by ArtForz. Any idea why this crashes? I have Soluto installed, so that might be the reason why I'm not seeing any error message ... although I did try to exit it and that didn't help.
Two questions: 1. Are you using the 12/19 or the 12/21 version? 2. Did you specify any parameters when invoking the exeutable? |
|
|
|
is the pool down? [2011-12-26 11:00:41] Binding thread 0 to cpu 0
[2011-12-26 11:00:42] 1 miner threads started, using 'scrypt' algorithm.
[2011-12-26 11:00:46] HTTP request failed: couldn't connect to host
[2011-12-26 11:00:46] json_rpc_call failed, retry after 30 seconds
Yes, technical problems. It's back up now, sorry for the inconvenience. |
|
|
|
Your pool does not pay out every hour. Either fix the problem or change your advertisements.
Automatic payments used to be carried out every hour, but I changed that to twice daily when I added the instant payout option, in order to minimize the number of transactions. When I applied the changes I corrected the description in the feature lists (both on the site and on here) and on the "Payments" page, but I forgot to correct the textual description on the home page. Sorry for that, it's fixed now.  |
|
|
|
thanks, ive seen this thread already but i cant seem to find this file on my ubuntu. libcurl3 and libcurl4 are installed. Do you have libcurl4-gnutls-dev (or something similar) installed? |
|
|
|
hello, i am trying to compile this on ubuntu 32bit but get this error: checking for working alloca.h... yes
checking for alloca... yes
checking for json_loads in -ljansson... no
checking for pthread_create in -lpthread... yes
./configure: line 4973: syntax error near unexpected token `LIBCURL_CHECK_CONFIG'
./configure: line 4973: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) This should solve the problem: https://bitcointalk.org/index.php?topic=4823.msg588208#msg588208 |
|
|
|
i'm interested in a iPhone interface. I love checking my miner stats throughout the day
Alright, link to the mobile interface now available on the "My Account page". You can add an icon for it to your Home screen via Safari. |
|
|
|
Not only with the stock gcc 4.2, I tried to compile with gcc 4.6 from MacPorts, the result is the same.
Maybe it is a problem of as, the GNU-based assembler of Mac OS X.
You are probably right. What version of binutils ('as' is part of binutils) is giving you problems? On Mac OS X 10.6.8: bash-3.2$ as -v Apple Inc version cctools-795~45, GNU assembler version 1.38 I don't know if Apple ships the whole GNU binutils, but apparently they customize it for their need. Hey, that does look old! Current version is 2.22. I had a rapid look at the NEWS file for gas, and it seems that it only supports macros starting from version 2.6. |
|
|
|
Hey, wait, you are on a Mac! I thought you were under Linux, sorry. Unfortunately gcc 4.2 seems to have some problems with macros in assembly code. In order to get it to compile, SockPuppet had to expand all the macros by hand. Unfortunately I cannot just use his version in the main package, because the code becomes very hard to read. But I think you can contact him if you want the modified sources. Not only with the stock gcc 4.2, I tried to compile with gcc 4.6 from MacPorts, the result is the same. Maybe it is a problem of as, the GNU-based assembler of Mac OS X. You are probably right. What version of binutils ('as' is part of binutils) is giving you problems? |
|
|
|
Yes was problem with old configure.am I copied over however now I get.
{code}
I guess this is the first time you try to compile the new miner on that machine, because I didn't change the assembly code in the latest release, and you are getting errors on that. What version of gcc/binutils are you using? I think I saw those errors already on some older versions. The binutils I just installed from MacPorts it made no difference same error. gcc -version
i686-apple-darwin10-gcc-4.2.1: no input files
binutils @2.21_0
Hey, wait, you are on a Mac! I thought you were under Linux, sorry. Unfortunately gcc 4.2 seems to have some problems with macros in assembly code. In order to get it to compile, SockPuppet had to expand all the macros by hand. Unfortunately I cannot just use his version in the main package, because the code becomes very hard to read. But I think you can contact him if you want the modified sources. |
|
|
|
Yes was problem with old configure.am I copied over however now I get.
{code}
I guess this is the first time you try to compile the new miner on that machine, because I didn't change the assembly code in the latest release, and you are getting errors on that. What version of gcc/binutils are you using? I think I saw those errors already on some older versions. |
|
|
|
We finally managed to build a 32-bit binary for Mac OS X 10.4, here it is: http://dl.dropbox.com/u/828037/minerd_for_OSX_10.4.zipMany thanks to SockPuppet, who did all the hard work! Running minerd.exe on Windows with no parameters causes a gpf.
Known bug That should be fixed now. I have also added a couple lines of code to auto-detect the number of cores when the number of threads is not specified. This already worked under Linux, but now it should work under Windows, too. (Thanks to diki for testing and for the new binaries!) Please note that I have changed a few default values in the latest release. The default URL is now http://127.0.0.1:9332/, and the retry parameter has been defaulted to -1, i.e. "retry indefinitely". This release also changes the "PROOF OF WORK RESULT" message to include information about submitted shares and total hash rate. (Thanks to inlikeflynn!) Well tells us the secret so we can build it ourselves... gcc -O3 -pthread -arch x86_64 -o minerd minerd-cpu-miner.o minerd-util.o minerd-scrypt.o -L/opt/local/lib -lcurl -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -lidn -lssl -lcrypto -lssl -lcrypto -lz -lz compat/jansson/libjansson.a -lpthread
Undefined symbols:
"_x64_scrypt_core", referenced from:
_scanhash_scrypt in minerd-scrypt.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [minerd] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
In the above gcc line you miss a couple object files. I didn't change any build-related file in this release, however, so that's a bit strange. Have you tried running a clean clone/autogen/configure/make? |
|
|
|
We finally managed to build a 32-bit binary for Mac OS X 10.4, here it is: http://dl.dropbox.com/u/828037/minerd_for_OSX_10.4.zipMany thanks to SockPuppet, who did all the hard work! Running minerd.exe on Windows with no parameters causes a gpf.
Known bug That should be fixed now. I have also added a couple lines of code to auto-detect the number of cores when the number of threads is not specified. This already worked under Linux, but now it should work under Windows, too. (Thanks to diki for testing and for the new binaries!) Please note that I have changed a few default values in the latest release. The default URL is now http://127.0.0.1:9332/, and the retry parameter has been defaulted to -1, i.e. "retry indefinitely". This release also changes the "PROOF OF WORK RESULT" message to include information about submitted shares and total hash rate. (Thanks to inlikeflynn!) |
|
|
|
I'm talking about algorithm that is used between two SHA256 calculations to make hashing GPU unfriendly. Its name is "Scrypt".
It's supposed to do calculations that can't be done in parralel mode and require a lot of memory. Parameters used for LTC and similar forks (1024, 1 and 1) make us to use only 1 thread and at least 128 Kb of memory to calc 1 hash value. I rewrote the algorithm so I could track a path of every bit. After that I used math methods for simplifying integrated circuits (it's like when u have 1000 NAND or NOR elements and wish to use as less as possible of them, just 300 for example). I failed to build complete Scrypt this way, coz of memory constraint, but I managed to simplify small pieces of it. I'm afraid that with a lot of memory anyone could build complete scheme and pass thousand SALSA steps. This will lead to huge hashrate boost, i.e. 1 Mh/s vs 1 Kh/s with "usual" Scrypt. No need to tell why it's very bad for LTC and the others.
Well, now my question: is there any theory that prove quality of Scrypt?
PS: My modified Scrypt code do less calculations. It gives approx. 20% boost when compared to original code of Tarnsnap project due to sequential memory access. Imagine what will happen if someone get rid of redundant XORs of 16 temporary memory cells in SALSA...
I think it would be interesting to discuss this with the author of scrypt, Colin Percival. There is even a mailing list dedicated to scrypt here: http://www.tarsnap.com/lists.html |
|
|
|
Pooler,
Don't you think that NVidia CUDA can run some new assembly code for Scrypt more fast than a CPU?
I'm asking this because I see that some guys are working on a open source miner for SolidCoin (a.k.a Shitcoin) that run on CUDA...
Best!
Thiago
I might be wrong, but doesn't SolidCoin use a different algorithm? Apart from that, I'm not a GPGPU expert in any way, but I don't think computing Scrypt on a GPU would be efficient, at least not with the hardware that is available at the moment. |
|
|
|
64-bit miner should work 50% faster if u calc 2 hashes at once. To get this bonus u should double ur code in the following maneur:
1st SSE instruction that calc hash #1 (using xmm0-xmm7)
1st SSE instruction that calc hash #2 (using xmm8-xmm15)
2nd SSE instruction that calc hash #1 (using xmm0-xmm7)
2nd SSE instruction that calc hash #2 (using xmm8-xmm15)
...
...
Nth SSE instruction that calc hash #1 (using xmm0-xmm7)
Nth SSE instruction that calc hash #2 (using xmm8-xmm15)
Thank you for the suggestion, I'll try to implement something like that as soon as I find some time. I'm currently trying to fix a couple bugs already present in the old minerd. |
|
|
|
The Pentium D's are running fresh installs of Ubuntu 10.04 64-bit, up to date "aptitude dist-upgrade" and rebooted. The artforz miner was pulled from git yesterday with "git pull https://github.com/ArtForz/cpuminer" as was pooler's "git pull https://github.com/pooler/cpuminer" Both were compiled with CFLAGS="-march=native -O3 -Wall -msse2" I even tried copying over the binaries that were compiled on the sempron and xeon boxes but got the same results. I'm thinking there's either something about the P4D's that makes them bad at scrypt, or I've got a bios or OS setting messed up somewhere. It seems odd that they are 2.8 GHz dual-core chips with each thread doing exactly half it's GHz in khash/s. Maybe there is some instruction that takes two clock cycles which only takes one in newer chips? If I can get some time, I might go try Windows and/or Ubuntu 11.10 on one of them to see if it makes a difference. Yes, I would like to see the performance in 32-bit mode. The Pentium D's were very early 64-bit cpus, and are not as good at SSE as later Core-based models, but I expected them to get some improvement from the new code. |
|
|
|
The calculator gives you the 50% time.
Not really... it gives the expected value, which turns out to be at probability 1-1/e, or ~63%. But other than that you are right, that should only match the average time per block over the long run. |
|
|
|
|
Show Posts
