also it has definitely something to do with network connectivity, all container crashes were around the same time and in every log there is some info about stratum recv line failed multiple times before the overflow happens
also the overflow is not proxy related, one miner was configured to not use it but my rock solid university network, so the recvline seems to come from nicehash stratum servers having problems (?)
Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 140. (Read 444040 times)
August 31, 2016, 04:44:07 PM
August 31, 2016, 04:38:10 PM
@joblo
despite setting the stack size to 1gig (is this enough?) the miner crashed again on two lxc containers, seems to indeed be lxc related somehow as till now no crash has been observed on bare metal ubuntu
will workaround this by just restarting the miner if he dies
also it seems to only affect cryptonight (not lyra2re) so it might be a similar problem to the one you encountered during development
cheers
despite setting the stack size to 1gig (is this enough?) the miner crashed again on two lxc containers, seems to indeed be lxc related somehow as till now no crash has been observed on bare metal ubuntu
will workaround this by just restarting the miner if he dies
also it seems to only affect cryptonight (not lyra2re) so it might be a similar problem to the one you encountered during development
cheers
That's curious. My previous stack overflow problem was with cryptonight on Windows. Never had problems with Linux. I removed a very
large buffer from the stack so it should be a reasonable size now. 1 GB should be more than enough.
Try reducing the number of miner threads, see if that changes anything.
August 31, 2016, 03:53:06 PM
@joblo
despite setting the stack size to 1gig (is this enough?) the miner crashed again on two lxc containers, seems to indeed be lxc related somehow as till now no crash has been observed on bare metal ubuntu
will workaround this by just restarting the miner if he dies
also it seems to only affect cryptonight (not lyra2re) so it might be a similar problem to the one you encountered during development
cheers
despite setting the stack size to 1gig (is this enough?) the miner crashed again on two lxc containers, seems to indeed be lxc related somehow as till now no crash has been observed on bare metal ubuntu
will workaround this by just restarting the miner if he dies
also it seems to only affect cryptonight (not lyra2re) so it might be a similar problem to the one you encountered during development
cheers
August 31, 2016, 10:31:44 AM
The following change will be made to the share result output in the next release. There is a small change from
the initial proposal.
[2016-08-31 10:21:44] Accepted 10/10 (100%), 5026 H, 215.37 H/s
[2016-08-31 10:21:44] Rejected 10/11 (99.9%), 5026 H, 215.37 H/s
the initial proposal.
[2016-08-31 10:21:44] Accepted 10/10 (100%), 5026 H, 215.37 H/s
[2016-08-31 10:21:44] Rejected 10/11 (99.9%), 5026 H, 215.37 H/s
August 31, 2016, 09:29:47 AM
@joblo do you mind compiling the windows bin for sse2 target too?
cheers
cheers
Ooops. Thanks for pointing that out.
New bins available wirth core2 build:
All download links updated, source not affected.
the link is actually the source code
thanks for supporting sse2!
cheers
Corrected: https://drive.google.com/file/d/0B0lVSGQYLJIZdjFES2M4SDJRQkU/view?usp=sharing
August 31, 2016, 09:13:18 AM
No windows binary ? The link just lead to the source code tar.bz file.
August 31, 2016, 09:09:36 AM
August 31, 2016, 09:06:29 AM
@joblo do you mind compiling the windows bin for sse2 target too?
cheers
cheers
Ooops. Thanks for pointing that out.
New bins available wirth core2 build:
corrected: https://drive.google.com/file/d/0B0lVSGQYLJIZdjFES2M4SDJRQkU/view?usp=sharing
All download links updated, source not affected.
August 31, 2016, 03:47:24 AM
@joblo do you mind compiling the windows bin for sse2 target too?
cheers
cheers
August 31, 2016, 02:14:17 AM
Hi,
I can confirm that it works with CryptoNight algorithm on Intel Westmere (tested with -t 2):
I can confirm that it works with CryptoNight algorithm on Intel Westmere (tested with -t 2):
Code:
********** cpuminer-opt 3.4.5 ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI and AVX extensions.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
Forked from TPruvot's cpuminer-multi with credits
to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
Wolf0, Jeff Garzik and Optiminer.
CPU: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
CPU features: SSE2 AES
SW built on Aug 30 2016 with GCC 4.8.3
SW features: SSE2 AES
Algo features: SSE2 AES AVX
Start mining with SSE2 AES
[2016-08-31 08:06:58] Starting Stratum on stratum+tcp://cryptonight.eu.nicehash.com:3355
[2016-08-31 08:06:58] 2 miner threads started, using 'cryptonight' algorithm.
[2016-08-31 08:06:58] Stratum difficulty set to 10000
[2016-08-31 08:06:59] CPU #0: 1 H, 64.10 H/s
[2016-08-31 08:06:59] CPU #1: 1 H, 64.10 H/s
[2016-08-31 08:07:08] CPU #1: 364 H, 38.31 H/s
[2016-08-31 08:07:08] CPU #0: 355 H, 37.12 H/s
[2016-08-31 08:07:41] CPU #1: 1243 H, 37.91 H/s
[2016-08-31 08:07:41] CPU #0: 1243 H, 37.92 H/s
[2016-08-31 08:07:51] CPU #1: 385 H, 37.39 H/s
[2016-08-31 08:07:51] accepted: 1/1 (100%), 1628 H, 75.32 H/s yes!
[2016-08-31 08:08:19] CPU #1: 920 H, 36.61 H/s
[2016-08-31 08:08:19] accepted: 2/2 (100%), 2163 H, 74.53 H/s yes!
[2016-08-31 08:08:32] CPU #0: 1907 H, 37.05 H/s
[2016-08-31 08:08:32] CPU #1: 533 H, 38.61 H/s
[2016-08-31 08:09:33] CPU #0: 2225 H, 36.73 H/s
[2016-08-31 08:09:34] CPU #1: 2318 H, 37.90 H/s
[2016-08-31 08:10:18] Stratum difficulty set to 5000
[2016-08-31 08:10:20] CPU #0: 1800 H, 38.09 H/s
[2016-08-31 08:10:20] CPU #1: 1730 H, 37.08 H/s
[2016-08-31 08:10:38] CPU #0: 652 H, 36.95 H/s
[2016-08-31 08:10:38] accepted: 3/3 (100%), 2382 H, 74.03 H/s yes!
[2016-08-31 08:11:09] CPU #0: 1128 H, 36.35 H/s
[2016-08-31 08:11:09] CPU #1: 1865 H, 38.31 H/s
August 30, 2016, 07:25:22 PM
cpuminer-opt 3.4.5 is released.
Source: https://drive.google.com/file/d/0B0lVSGQYLJIZVXJ2T0R4QjBWZXM/view?usp=sharing
Windows bins:https://drive.google.com/file/d/0B0lVSGQYLJIZNjlJZEppS2I0YzQ/view?usp=sharing
New Windows bins updated with core2 build.
https://drive.google.com/file/d/0B0lVSGQYLJIZdjFES2M4SDJRQkU/view?usp=sharing
It fixes the stale share rejects mining cryptonight at Nicehash, thanks to NiceHashSupport.
Also fixed, hopefully, is support for Westmere CPUs that have AES but not AVX. cpuminer-opt
should now compile on Westmere CPUs and mine with AES optimizations. A Westmere
Windows binary is also provided. It was compiled using "-maes -msse4.1" options
which should be compatible with Westmere's capabilities, As I am unable to test on actual
Westmere HW I would appreciate any feedback to confirm it now works as intended.
Source: https://drive.google.com/file/d/0B0lVSGQYLJIZVXJ2T0R4QjBWZXM/view?usp=sharing
Windows bins:
New Windows bins updated with core2 build.
https://drive.google.com/file/d/0B0lVSGQYLJIZdjFES2M4SDJRQkU/view?usp=sharing
It fixes the stale share rejects mining cryptonight at Nicehash, thanks to NiceHashSupport.
Also fixed, hopefully, is support for Westmere CPUs that have AES but not AVX. cpuminer-opt
should now compile on Westmere CPUs and mine with AES optimizations. A Westmere
Windows binary is also provided. It was compiled using "-maes -msse4.1" options
which should be compatible with Westmere's capabilities, As I am unable to test on actual
Westmere HW I would appreciate any feedback to confirm it now works as intended.
August 30, 2016, 04:17:08 PM
I have progress to report for westmere CPU users.
With the help of NiceHashSupport (yet again, many thanks) I have been able to simulate a westmere
compile and have reproduced the compile error reported by users. I have also fixed it. Hodl now runs
AES in westmere. I have yet to test the other AES optimized algos but if it goes well it will be released
with the nicehash cryptonight fix.
With the help of NiceHashSupport (yet again, many thanks) I have been able to simulate a westmere
compile and have reproduced the compile error reported by users. I have also fixed it. Hodl now runs
AES in westmere. I have yet to test the other AES optimized algos but if it goes well it will be released
with the nicehash cryptonight fix.
August 30, 2016, 03:43:24 PM
great to hear, i also noticed they included your miner into their 1.7.0.0 pre release bin package
August 30, 2016, 02:57:36 PM
After a lot of hard work by me and NiceHashSuppport the stale share rejects problem with cryptonight
is in fact a bug in the miner. It was failing to detect new work causing the submission of stale shares.
NiceHashSupport has coded a fix and we are both testing it with good results so far, ie no rejects.
If everything goes well a new release should be avalable within the next day.
is in fact a bug in the miner. It was failing to detect new work causing the submission of stale shares.
NiceHashSupport has coded a fix and we are both testing it with good results so far, ie no rejects.
If everything goes well a new release should be avalable within the next day.
August 30, 2016, 02:27:25 PM
Is this the Cryptonite (M7) XCN support or some other cryptonite? Sorry for that question of a newbe
No, different spelling.
cpuminer-opt does cryptonight algo which is used my monero coin (XMR). cryptonight is also sometimes
called cryptonote.
cryptonite is different,you should look here for it
https://bitcointalksearch.org/topic/annxcn-cryptonite-1st-mini-blockchain-coin-m7-pow-no-premine-713538
August 30, 2016, 02:15:44 PM
Is this the Cryptonite (M7) XCN support or some other cryptonite? Sorry for that question of a newbe
No, different spelling.
cpuminer-opt does cryptonight algo which is used my monero coin (XMR). cryptonight is also sometimes
called cryptonote.
August 30, 2016, 12:38:39 PM
Is this the Cryptonite (M7) XCN support or some other cryptonite? Sorry for that question of a newbe
August 30, 2016, 11:53:29 AM
its a lxc container actually, this is far more bound to limitations as it uses the same kernel and is no full virtualized system
will test with bare metal systems to verify
im using a socks5 proxy on all my machines affected, maybe this part of the code is not well tested, time will tell as i do my various tests
yes, compiled the same way on every system (build.sh)
cheers
will test with bare metal systems to verify
im using a socks5 proxy on all my machines affected, maybe this part of the code is not well tested, time will tell as i do my various tests
yes, compiled the same way on every system (build.sh)
cheers
I think I recall seeing a similar crash due to a stack overflow. Cryptonight was storing a large data structure on the stack and, although
it worked on Linux, it crashed on Windows. I made a change to cryptonight to reduce stack usage and it fixed it.
Can you increase the stack on your LXC?
i doubt one can increase the stack on lxc level, stack is usually increased in code or compile options, or am i wrong?
edit: seems its also settable by bash, will try after i confirmed its on lxc only
thanks for the hint
There might be a configure option to set stack size in cpuminer but I couldn't find it when troubleshooting the cryptonight stack overflow.
But then I found the real problem and it became moot.
The current setting (or the default) for cpuminer is good enough on other systems. If it doesn't work on lxc it's likely because lxc has a lower stack limit.
Maybe there is a setting in lxc to increase it.
Thre bash setting would only affect the shell, not other processes.
actually it does for this session, eg all programs started by this shell
"ulimit provides control over the resources available to the shell and to processes started by it, on systems that allow such control."
unfortunately i dont have any way to reproduce the buffer overflow except just waiting so it will take a while, will post results
August 30, 2016, 11:43:40 AM
its a lxc container actually, this is far more bound to limitations as it uses the same kernel and is no full virtualized system
will test with bare metal systems to verify
im using a socks5 proxy on all my machines affected, maybe this part of the code is not well tested, time will tell as i do my various tests
yes, compiled the same way on every system (build.sh)
cheers
will test with bare metal systems to verify
im using a socks5 proxy on all my machines affected, maybe this part of the code is not well tested, time will tell as i do my various tests
yes, compiled the same way on every system (build.sh)
cheers
I think I recall seeing a similar crash due to a stack overflow. Cryptonight was storing a large data structure on the stack and, although
it worked on Linux, it crashed on Windows. I made a change to cryptonight to reduce stack usage and it fixed it.
Can you increase the stack on your LXC?
i doubt one can increase the stack on lxc level, stack is usually increased in code or compile options, or am i wrong?
edit: seems its also settable by bash, will try after i confirmed its on lxc only
thanks for the hint
There might be a configure option to set stack size in cpuminer but I couldn't find it when troubleshooting the cryptonight stack overflow.
But then I found the real problem and it became moot.
The current setting (or the default) for cpuminer is good enough on other systems. If it doesn't work on lxc it's likely because lxc has a lower stack limit.
Maybe there is a setting in lxc to increase it.
Thre bash setting would only affect the shell, not other processes.
August 30, 2016, 11:19:55 AM
its a lxc container actually, this is far more bound to limitations as it uses the same kernel and is no full virtualized system
will test with bare metal systems to verify
im using a socks5 proxy on all my machines affected, maybe this part of the code is not well tested, time will tell as i do my various tests
yes, compiled the same way on every system (build.sh)
cheers
will test with bare metal systems to verify
im using a socks5 proxy on all my machines affected, maybe this part of the code is not well tested, time will tell as i do my various tests
yes, compiled the same way on every system (build.sh)
cheers
I think I recall seeing a similar crash due to a stack overflow. Cryptonight was storing a large data structure on the stack and, although
it worked on Linux, it crashed on Windows. I made a change to cryptonight to reduce stack usage and it fixed it.
Can you increase the stack on your LXC?
i doubt one can increase the stack on lxc level, stack is usually increased in code or compile options, or am i wrong?
edit: seems its also settable by bash, will try after i confirmed its on lxc only
thanks for the hint
Jump to: