2.1.3 Linux - Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz - 5.7 KHs
2.1.2 Windows - Intel(R) Pentium(R) Dual CPU T6400 @ 2.00GHz - 6.0 KHs
2.1.2 Windows - AMD C-50 Dual @ 1.00GHz - 1.36 KHs
2.1.3 Linux - AMD Athlon @ 700MHz - 0.4 KHs
Topic: An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only) - page 61. (Read 1958475 times)
February 13, 2012, 05:27:20 PM
February 13, 2012, 01:37:23 PM
Alright folks, time for a version bump.
Version 2.1.3
The source code is, as always, available at GitHub.No binaries yet, sorry, I couldn't find diki on IRC. Windows binaries here.
Brief note on the -s/--scantime option
I have seen people suggest various values for this option in order to reduce stales when mining in pools.
The funny thing is that, to my knowledge, all Litecoin pools have long polling permanently enabled (which is good), and when long polling is enabled the scantime parameter is completely ignored.
For this reason, the use of this parameter only makes sense when you are mining solo.
Version 2.1.3
- Support for extensions "midstate" (reduces network bandwidth usage) and "submitold" (used by p2pool).
- Smart handling of long polling failures: switch to short scantime if long polling fails.
- It is now possible to specify username and password in the URL, like this: --url http://username:password@host:port/.
- Added a --version option, and (finally) cleaned up the output of the --help option.
- The miner will now complain about non-option arguments, instead of simply ignoring them.
- Minor bug fixes.
The source code is, as always, available at GitHub.
Brief note on the -s/--scantime option
I have seen people suggest various values for this option in order to reduce stales when mining in pools.
The funny thing is that, to my knowledge, all Litecoin pools have long polling permanently enabled (which is good), and when long polling is enabled the scantime parameter is completely ignored.
For this reason, the use of this parameter only makes sense when you are mining solo.
February 12, 2012, 01:35:06 PM
Phenom ii x4 955 @ 3.6GHz
February 12, 2012, 09:31:42 AM
Wow!
My prevous minerd did 1.8Kh/s per core. This new one does 3.9Kh/s per core!
Thanks
P.S. Core2duo SU7300
My prevous minerd did 1.8Kh/s per core. This new one does 3.9Kh/s per core!
Thanks
P.S. Core2duo SU7300
February 04, 2012, 07:38:47 AM
looks like you are good to go. all you need to do know is collect your coins!
February 03, 2012, 02:18:11 AM
I am using win 7, 64 bit & i downloaded 2.1.2 from first page & i created a bat file with this code
minerd.exe -t 3 -o http://litecoinpool.org:9332/ -O xxxxx:xxxx
I am getting 15-16 khash/s on Intel core2 Quad Q8400, clock 2.6GHz, threads/core 3
Is that enough or i need further add anything?
minerd.exe -t 3 -o http://litecoinpool.org:9332/ -O xxxxx:xxxx
I am getting 15-16 khash/s on Intel core2 Quad Q8400, clock 2.6GHz, threads/core 3
Is that enough or i need further add anything?
February 02, 2012, 06:38:34 PM
Binaries of version 2.1.2 for Mac OS X are now available.
https://github.com/pooler/cpuminer/downloads
https://github.com/pooler/cpuminer/downloads
February 02, 2012, 04:10:42 AM
(Just looked into this "LiteCoin" thing today) Followed the instructions on pool-x for my i7-2600k, got 8.8 khash total for 4 cores.
Just replaced the default files with your ones, now getting 10.5 khash, PER CORE, for a total of 42.0 khash
Wow
Just replaced the default files with your ones, now getting 10.5 khash, PER CORE, for a total of 42.0 khash
Wow
February 02, 2012, 02:18:48 AM
Very happy in the update of this ... i was able to increase my overall hashrate by 3 fold
January 26, 2012, 10:40:38 AM
Version 2.1.2
Source code and Windows/OS X binaries: https://github.com/pooler/cpuminer
hangover: this version should build correctly with binutils 2.15. Let me know if the assembler still complains.
- Do not submit work that is known to be stale (gaining some more time for hashing).
- Allow miner threads to ask for new work if the current one is at least 45 seconds old and long polling is enabled. This should avoid having all miners asking for work at the same time.
- Refresh work when long polling times out, in order to avoid working on stale work.
- Modify x86-64 code to make it compatible with older versions of binutils.
Source code and Windows/OS X binaries: https://github.com/pooler/cpuminer
hangover: this version should build correctly with binutils 2.15. Let me know if the assembler still complains.
January 25, 2012, 01:42:38 PM
Yes, you're right - base FreeBSD version is too old:
Thank you, will search for workaround.
Code:
$ ld --version
GNU ld version 2.15 [FreeBSD] 2004-05-23
Copyright 2002 Free Software Foundation, Inc.
Thank you, will search for workaround.
January 25, 2012, 07:43:01 AM
Unfortunately, new version doesn't compile under FreeBSD 8.2-RELEASE-p2 amd64 with following error:
{code}
{code}
My guess is that your version of binutils is too old. Try issuing "ld --version".
In the next release I will try to avoid this problem by changing a few instructions.
January 25, 2012, 12:30:58 AM
Unfortunately, new version doesn't compile under FreeBSD 8.2-RELEASE-p2 amd64 with following error:
Code:
# gmake
gmake all-recursive
gmake[1]: Entering directory `/usr/home/qwe/cpuminer'
Making all in compat
gmake[2]: Entering directory `/usr/home/qwe/cpuminer/compat'
Making all in jansson
gmake[3]: Entering directory `/usr/home/qwe/cpuminer/compat/jansson'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/usr/home/qwe/cpuminer/compat/jansson'
gmake[3]: Entering directory `/usr/home/qwe/cpuminer/compat'
gmake[3]: Nothing to be done for `all-am'.
gmake[3]: Leaving directory `/usr/home/qwe/cpuminer/compat'
gmake[2]: Leaving directory `/usr/home/qwe/cpuminer/compat'
gmake[2]: Entering directory `/usr/home/qwe/cpuminer'
gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -I./compat/jansson -I/usr/local/include -g -O2 -MT minerd-scrypt-x64.o -MD -MP -MF .deps/minerd-scrypt-x64.Tpo -c -o minerd-scrypt-x64.o `test -f 'scrypt-x64.S' || echo './'`scrypt-x64.S
scrypt-x64.S: Assembler messages:
scrypt-x64.S:1700: Error: `(%ebp,%ebp,2)' is not a valid 64 bit base/index expression
scrypt-x64.S:1704: Error: `(%ebx,%ebx,2)' is not a valid 64 bit base/index expression
scrypt-x64.S:1709: Error: `(%r8d,%r8d,2)' is not a valid 64 bit base/index expression
gmake[2]: *** [minerd-scrypt-x64.o] Error 1
gmake[2]: Leaving directory `/usr/home/qwe/cpuminer'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/qwe/cpuminer'
gmake: *** [all] Error 2
January 21, 2012, 04:03:02 AM
Finally, the most important change. I have tried to drastically increase the getwork efficiency of the miner, so that it spends less time waiting for new work. Indirectly, this should also make the miner faster, even if the speed increase will not be reflected in the reported hashrate, that only takes hashing time into consideration.
Very good idea! Would be great if ur miner reported the "real" hashrate as well. So miners would see how hashrate depends on their network/computer settings and could tweak settings.
January 20, 2012, 09:24:31 PM
- Now the miner automatically sets its priority to idle on Windows.
Wonderful.
January 20, 2012, 09:13:04 PM
If you are watching the GitHub repo, you may have noticed that I have released a few new versions of the miner.
Here are the most interesting minor changes:
Finally, the most important change. I have tried to drastically increase the getwork efficiency of the miner, so that it spends less time waiting for new work. Indirectly, this should also make the miner faster, even if the speed increase will not be reflected in the reported hashrate, that only takes hashing time into consideration. These are the changes that make the efficiency increase possible:
The latest sources and a couple new binaries for Windows are available at the usual location:
https://github.com/pooler/cpuminer
Here are the most interesting minor changes:
- First off, I have finally started changing the version number, which is now 2.1.1. I have also updated the NEWS file to reflect the main changes introduced since jgarzik's last release.
- No new performance optimizations since the January 11 version. Nonetheless, the reported hashrate could be slightly higher or lower (depending on your CPU, CFLAGS and compiler version) because of some minor changes I made to the C wrapper of the hashing function. For some reason, it seems to be slightly faster on K10's. I am talking of fluctuations of the order of +/- 0.5%, so nothing one should worry about.
- Now the miner automatically sets its priority to idle on Windows.
- I have fixed the short options -u and -p, that didn't work, and I have added short versions of --url and --userpass, following the naming convention used by cgminer (-o and -O).
Finally, the most important change. I have tried to drastically increase the getwork efficiency of the miner, so that it spends less time waiting for new work. Indirectly, this should also make the miner faster, even if the speed increase will not be reflected in the reported hashrate, that only takes hashing time into consideration. These are the changes that make the efficiency increase possible:
- The miner no more discards the work returned by long polling.
- If long polling is available, do not ask for new work until the current work is at least 60 seconds old.
- Since the nonce space is quite vast, we don't need different work for each thread. All threads can use the work returned by just one getwork requests.
The latest sources and a couple new binaries for Windows are available at the usual location:
https://github.com/pooler/cpuminer
January 18, 2012, 04:27:35 PM
Small update here, using the latest version posted ..
A stock FX4100 achieves nearly 5kh/s/core
A stock FX4100 achieves nearly 5kh/s/core
January 17, 2012, 01:53:22 AM
Nice, I finally tried this, got a fresh install, and everything worked - I probably did mix some DLLs before.
Got a 300% increase in performance - it might be worth it to mine again.
Is there a mining profitability calculator for LTC? I'm too lazy to do the math.
Some website with a textbox where I can input like 35k hashes/sec and get a result in LTC/day.
Got a 300% increase in performance - it might be worth it to mine again.
Is there a mining profitability calculator for LTC? I'm too lazy to do the math.
Some website with a textbox where I can input like 35k hashes/sec and get a result in LTC/day.
http://allchains.info/calc.html
http://www.litecoinpool.org/calc
Sweet, so at current difficulty I should be netting about 30 coins a day.
Historically I always felt like I solved less blocks than I should have. Will keep an eye on this.
January 16, 2012, 07:23:23 PM
Nice, I finally tried this, got a fresh install, and everything worked - I probably did mix some DLLs before.
Got a 300% increase in performance - it might be worth it to mine again.
Is there a mining profitability calculator for LTC? I'm too lazy to do the math.
Some website with a textbox where I can input like 35k hashes/sec and get a result in LTC/day.
Got a 300% increase in performance - it might be worth it to mine again.
Is there a mining profitability calculator for LTC? I'm too lazy to do the math.
Some website with a textbox where I can input like 35k hashes/sec and get a result in LTC/day.
http://allchains.info/calc.html
http://www.litecoinpool.org/calc
January 16, 2012, 06:13:20 PM
Nice, I finally tried this, got a fresh install, and everything worked - I probably did mix some DLLs before.
Got a 300% increase in performance - it might be worth it to mine again.
Is there a mining profitability calculator for LTC? I'm too lazy to do the math.
Some website with a textbox where I can input like 35k hashes/sec and get a result in LTC/day.
Got a 300% increase in performance - it might be worth it to mine again.
Is there a mining profitability calculator for LTC? I'm too lazy to do the math.
Some website with a textbox where I can input like 35k hashes/sec and get a result in LTC/day.
Jump to: