JayneL
Member
Offline
Activity: 104
Merit: 10
|
|
August 10, 2017, 03:43:10 PM |
|
just copy ur download bn.h from the openssl site i link then paste to \usr\local\include\openssl then just run in the terminal ./build.sh and poof works like a charm its way better than palgin now i finally manage to do the openssl bn.h trick hahaha now building ccminer...
Can you please share how you did it Thanks.
|
|
|
|
Bibi187
Full Member
Offline
Activity: 420
Merit: 106
https://steemit.com/@bibi187
|
|
August 10, 2017, 03:43:34 PM |
|
sure mate here it is http://www.linuxfromscratch.org/blfs/view/7.4/postlfs/openssl.htmlHello mate, do you mind sharing which website you have downloaded and copied that file (bn.h) in detail (if possible with steps, may help other users too). Thanks One Page back...I sorted the issue by downloading openssl 1.0.1 from their website and copying the "bn.h" after install to \usr\local\include\openssl It then builds without issue. Hope it helps Thanks both of you, I've managed to build it too, if any one interested happy to share step by step detail How much do u get with this new release on nvOC ? 1070 -i 25 / OC : 120 / MC : -500 / PL : 150 : / TL : 70 ( Autotemp ON, watchdog OFF ) 30.5mh/s I actually mining on https://pool.mn/sigt/ ( 0.99% fee ) more detailled stats vs no sense stats on suprnova pool ... On my 8x GPU rig, one of my card us lower them all the other one by 2mh/s, any idea where that come from ? Last question, i setup OC: 120 / MC: -500 on all GPU, but i dont get same stats for the nvclock ... Why ? Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:0]): nvclock=2025, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:1]): nvclock=2025, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:2]): nvclock=1885, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:3]): nvclock=1885, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:4]): nvclock=1999, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:5]): nvclock=1911, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:6]): nvclock=2037, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:7]): nvclock=1936, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 As u can see, that only happen on nvclock the memclock is strictly ident
|
|
|
|
damNmad
Full Member
Offline
Activity: 378
Merit: 104
nvOC forever
|
|
August 10, 2017, 04:02:12 PM |
|
sure mate here it is http://www.linuxfromscratch.org/blfs/view/7.4/postlfs/openssl.htmlHello mate, do you mind sharing which website you have downloaded and copied that file (bn.h) in detail (if possible with steps, may help other users too). Thanks One Page back...I sorted the issue by downloading openssl 1.0.1 from their website and copying the "bn.h" after install to \usr\local\include\openssl It then builds without issue. Hope it helps Thanks both of you, I've managed to build it too, if any one interested happy to share step by step detail How much do u get with this new release on nvOC ? 1070 -i 25 / OC : 120 / MC : -500 / PL : 150 : / TL : 70 ( Autotemp ON, watchdog OFF ) 30.5mh/s I actually mining on https://pool.mn/sigt/ ( 0.99% fee ) more detailled stats vs no sense stats on suprnova pool ... On my 8x GPU rig, one of my card us lower them all the other one by 2mh/s, any idea where that come from ? Last question, i setup OC: 120 / MC: -500 on all GPU, but i dont get same stats for the nvclock ... Why ? Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:0]): nvclock=2025, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:1]): nvclock=2025, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:2]): nvclock=1885, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:3]): nvclock=1885, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:4]): nvclock=1999, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:5]): nvclock=1911, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:6]): nvclock=2037, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:7]): nvclock=1936, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 As u can see, that only happen on nvclock the memclock is strictly ident TBH, I'm not sure about 1070. You can follow this post to get more accurate info. https://bitcointalk.org/index.php?topic=2070862.180but I can clearly see that there is 2-3 MH increase per card (reports from other users too) with recent update. you can increase your cc a little (i pushed it till 150-170 on my 1060) and reduce mc even bit more, PL I will always test till 70% or with my 1060 even less depending on card. Well, it varies card to card, because not every card is same (even you bought same model), also memory may differ between cards (from my analysis Samsung > Hynix > Micron). Hope it helps...
|
|
|
|
Bibi187
Full Member
Offline
Activity: 420
Merit: 106
https://steemit.com/@bibi187
|
|
August 10, 2017, 04:16:56 PM |
|
sure mate here it is http://www.linuxfromscratch.org/blfs/view/7.4/postlfs/openssl.htmlHello mate, do you mind sharing which website you have downloaded and copied that file (bn.h) in detail (if possible with steps, may help other users too). Thanks One Page back...I sorted the issue by downloading openssl 1.0.1 from their website and copying the "bn.h" after install to \usr\local\include\openssl It then builds without issue. Hope it helps Thanks both of you, I've managed to build it too, if any one interested happy to share step by step detail How much do u get with this new release on nvOC ? 1070 -i 25 / OC : 120 / MC : -500 / PL : 150 : / TL : 70 ( Autotemp ON, watchdog OFF ) 30.5mh/s I actually mining on https://pool.mn/sigt/ ( 0.99% fee ) more detailled stats vs no sense stats on suprnova pool ... On my 8x GPU rig, one of my card us lower them all the other one by 2mh/s, any idea where that come from ? Last question, i setup OC: 120 / MC: -500 on all GPU, but i dont get same stats for the nvclock ... Why ? Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:0]): nvclock=2025, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:1]): nvclock=2025, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:2]): nvclock=1885, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:3]): nvclock=1885, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:4]): nvclock=1999, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:5]): nvclock=1911, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:6]): nvclock=2037, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 Attribute 'GPUCurrentClockFreqsString' (m1-desktop:0[gpu:7]): nvclock=1936, nvclockmin=215, nvclockmax=2100, nvclockeditable=1, memclock=3553, memclockmin=3552, memclockmax=3552, memclockeditable=1, memTransferRate=7106, memTransferRatemin=7104, memTransferRatemax=7104, memTransferRateeditable=1 As u can see, that only happen on nvclock the memclock is strictly ident TBH, I'm not sure about 1070. You can follow this post to get more accurate info. https://bitcointalk.org/index.php?topic=2070862.180but I can clearly see that there is 2-3 MH increase per card (reports from other users too) with recent update. you can increase your cc a little (i pushed it till 150-170 on my 1060) and reduce mc even bit more, PL I will always test till 70% or with my 1060 even less depending on card. Well, it varies card to card, because not every card is same (even you bought same model), also memory may differ between cards (from my analysis Samsung > Hynix > Micron). Hope it helps... Nvclock is the freq rate from GPU not memory so we dont care about memory builder i decrease the usage of them The variance from nvclock, i assume is from the power variation
|
|
|
|
BigHashMiner
Member
Offline
Activity: 106
Merit: 10
|
|
August 10, 2017, 07:39:43 PM |
|
doesnt any wifi adapter work? i use a wifi adapter on nvoc and it worked fine
|
|
|
|
fogcity
Newbie
Offline
Activity: 11
Merit: 0
|
|
August 10, 2017, 08:28:08 PM |
|
Hey all --- I notice Claymore version 9.8 is available now. Has anyone tried it to see if it runs any better/faster than version 9.7 A few folks on bitcointalk.org have indicated a Hash increase of 3-5%, but of course, that doesn't necessarily mean 3-5% increase in shares found... Thanks in advance!
|
|
|
|
SwaY
Newbie
Offline
Activity: 10
Merit: 0
|
|
August 10, 2017, 11:07:28 PM |
|
sure mate here it is http://www.linuxfromscratch.org/blfs/view/7.4/postlfs/openssl.htmlHello mate, do you mind sharing which website you have downloaded and copied that file (bn.h) in detail (if possible with steps, may help other users too). Thanks One Page back...I sorted the issue by downloading openssl 1.0.1 from their website and copying the "bn.h" after install to \usr\local\include\openssl It then builds without issue. Hope it helps Thanks both of you, I've managed to build it too, if any one interested happy to share step by step detail Would be great if you could post a how-to here!
|
|
|
|
darklow
Newbie
Offline
Activity: 16
Merit: 0
|
|
August 10, 2017, 11:31:20 PM Last edit: August 10, 2017, 11:52:11 PM by darklow |
|
sure mate here it is http://www.linuxfromscratch.org/blfs/view/7.4/postlfs/openssl.htmlHello mate, do you mind sharing which website you have downloaded and copied that file (bn.h) in detail (if possible with steps, may help other users too). Thanks One Page back...I sorted the issue by downloading openssl 1.0.1 from their website and copying the "bn.h" after install to \usr\local\include\openssl It then builds without issue. Hope it helps Thanks both of you, I've managed to build it too, if any one interested happy to share step by step detail Would be great if you could post a how-to here! This is how it worked for me, increase is quite nice plus 3-4 MH/s vs palgin mod, getting 29-30 MH/s with 1070. To avoid error I needed to update one openssl file to past version: wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz tar -xvzf openssl-1.0.1e.tar.gz cp /usr/local/include/openssl/bn.h bn.h.backup sudo cp openssl-1.0.1e/crypto/bn/bn.h /usr/local/include/openssl/ git clone https://github.com/krnlx/ccminer-skunk-krnlx.git cd ccminer-skunk-krnlx/ sudo ./build.sh
Now test it and if it works, stop miner (pkill -e miner) and copy over and wait for miner to restart and Voilà! pkill -e miner ./ccminer sudo cp ccminer-krnlx/ccminer-skunk-krnlx/ccminer TPccminer/
If it works and you wish to thank me, go and check out my project https://cryptopanic.com/
|
|
|
|
Nexillus
|
|
August 11, 2017, 01:58:00 AM |
|
doesnt any wifi adapter work? i use a wifi adapter on nvoc and it worked fine No reject shares or other problems ?
|
|
|
|
JayneL
Member
Offline
Activity: 104
Merit: 10
|
|
August 11, 2017, 04:45:56 AM |
|
Hi guys now i got this error message mining sigt
"Warning: persistence mode is disabled on this device. This settings will go back to default as soon as driver unloads (e.g. last application like nvidia-smi or cuda ..."
How can i fix that?
And can you share ur experience mining SIGT @ current block and difficulty, Im mining on supernova 120mhs for SIGT for 20hrs (estimate) i got only 57 SIGT and i think this is bad. anyone can help me or advise a better pool?
Thanks again so much
God Bless
|
|
|
|
dbolivar
Member
Offline
Activity: 119
Merit: 10
|
|
August 11, 2017, 07:42:28 AM |
|
Does anybody successfully setup a rig with 5+ GPUs (or know someone who has) with the following mobos:
ASRock ATX Z270 Killer SLI/BR (LGA 1151)
Gigabyte GA-990FX-GAMING (AMD AM3+)
They have a good price where I live (the Gigabyte AM3+ is because I have an old Phenom II CPU around, so would save some more money).
Thanks
|
|
|
|
scryptr
Legendary
Offline
Activity: 1797
Merit: 1028
|
|
August 11, 2017, 12:27:12 PM Last edit: August 11, 2017, 01:10:04 PM by scryptr |
|
Does anybody successfully setup a rig with 5+ GPUs (or know someone who has) with the following mobos:
ASRock ATX Z270 Killer SLI/BR (LGA 1151)
Gigabyte GA-990FX-GAMING (AMD AM3+)
They have a good price where I live (the Gigabyte AM3+ is because I have an old Phenom II CPU around, so would save some more money).
Thanks
THE "Z" BOARDS NEED UPDATED BIOS-- They can be tricky for 5+ GPUs. I don't have one. I do have several GigaByte 990FXA boards, they need updated BIOS and can be tricky. Try ASRock H81 Pro BTC v2.0 for a mining board. They have Intel 1150 CPU sockets. The Gigabyte 990FXA boards were very difficult with Ubuntu 14.04.1, but loaded Win 7 or 8 with no problem. Later versions of Ubuntu (14.04.4+) were able to load. They will work with Sempron CPUs or better, and can unlock an AMD CPU for more cores. One of my Semprons unlocked to an AMD Athlon XII, the other did not. I just upgraded that board to an AMD 4350, it mines 24/7 on Win 7 x64 and 5 GTX 960 GPUs. Getting the 6th GPU to work was too much trouble. My other GB 990 FXA board has 6 GPUs, Win 7 x64, nVidia 750ti GPUs and an AMD 4350 CPU. I will again try 6 GPUs on my GTX 960 rig when I get my first GTX 1060. I don't know if the "6th GPU" problem was heat or lack of CPU power. The Sempron 145 is single core, it worked in 2013-2014 for early mining algorithms. Newer algorithms may need more CPU power. --scryptr
|
|
|
|
fullzero (OP)
|
|
August 11, 2017, 05:59:49 PM |
|
@fullzero Have you considered moving the configuration, or at least the key configuration parameters like pools and coin to mine, to a separate file? I sometimes change pools and coins, for instance, and currently I have several "1bash_xxx" files for each configuration, controlling the active one with a symlink to "1bash". One idea would be a config file like this (for instance in INI format, but just to illustrate): ::: 1bash.conf ::: [defaults] # Every configuration option # Below just what's different from default. Users define their config keys, # specifying the active one in 1bash [zec-nanopool] COIN="ZEC" ZEC_POOL="zec-us-east1.nanopool.org" [eth-dwarfpool] COIN="ETH" ETH_POOL="eth-us.dwarfpool.com" ::: 1bash ::: # 1) Read default options # 2) Read user options USER_CONF="zec-nanopool" ... Just an idea. I may be able to help you with that, if you want and find it a good idea. I know Bash doesn't have a built-in parser for INI (or whatever) config files, but there's some code around to do that. I went over this in detail previously in the thread. In v0019 the settings will be separate from the implementation; along with many other changes.
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
fullzero (OP)
|
|
August 11, 2017, 06:06:38 PM |
|
Hey, ty for adding teamviewer to nvOC!
But i got a problem: teamviewer never start on boot, i always need to enter this on guake terminal :
sudo teamviewer --daemon enable
My rigs are not at home, and if i need to reboot this, i can't control after the reboot :-(, please help me.
On your 1bash be sure to set TEAMVIEWER="YES" Oh thanks, there is a way to edit the 1bash in ubuntu ? if yes it need a restart ? thanks! Yes, you can. It is in the home directory. Please search in home folder (where you see all miners) EDIT: For restart, to apply the 1bash changes you don't need to restart whole rig, you can kill the mining process using 'CTRL + c' and it should restart the process with new changes, if it doesn't just close the terminal after 'CTRL+c' and close the terminal and restart the terminal (not the rig) press CTRL+c, it restarts 1bash, do you know how to disable this feature? I'd like to exit the terminal when I press CTRL+c, thanks. The way everything is setup; is to expect this to occur. You can change this but; it will break a lot of other things. When gnome terminal is open go to the top left of the screen and click terminal, then preferences, then profiles. select mining and click edit. Click the command tab. Change when command exits: to Exit the terminal. Friend, look, please. It's in your interests. I need to collect 30 farms for 12 Mining Edition cards and I want to do this on NVOC and I need to collect it before the end of the week, but without overclocking there is no sense at all. I sent you access to private messages. Very much I ask you, to solve a situation. I will try to do this tonight.
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
fullzero (OP)
|
|
August 11, 2017, 06:12:09 PM |
|
Hey Guys,
Have a problem with loading the OS as it tells me "xorg PROBLEM DETECTED" and then reboots and shows: error: unknown filesystem grab rescue>
What can it be and how can I solve this? Used flashing tools as described and tried it at least twice. I am using ASrock h110 and at the moment just one Manli P106-100 card just so I can test if I can install the OS before installing all 13 cards.
I need one or two of the: P106-100 to test and ensure nvOC will properly support these GPUs. A number of members have had problems using these GPUs. If someone is willing to sell me 1 or preferably 2 Please pm me. I have solved this issue by editing the line "XORG FAIL" to XORG "OK" which worked and the system started, now I have the different problem : When I run more then 6-7 cards on the board no matter in what miner I either get error 15 " cannot get current temperature " or the system just freezes after in about half an hour or a bit longer and the only thing that helps is to turn off/on the power socket... I have updated the drivers and now trying to wait for it to freeze on 6 cards since it works the longest out of all the set ups I tried. As soon as I try 10 or more GPUs I either get error 15 or just frozen system. I don't think it's one of the cards since I mixed them a couple of times and what I noticed is that it crashes faster as I add more GPUs. Do you have any idea where the problem can be? I have also 2 PSUs connected together one 600W Zalmann powering motherboard and 2400W HP server PSU which was remade for GPU mining and powers risers and GPUs, both of those seem to be working fine , so I have no idea where to look for solution. If anyone had this problem please let me know , would be greatly appreciated... Even willing to donate to somebody who's advice will help. PS. The cards are in stock mode, so it's not OC. UPD Been pretty stable on 6 cards , have been running for 8 hours now , probably will try and add a couple after a 16-20 hour mark... If you have another rig, I would try testing each of the GPUs an verifying they work individually; if they all do, then I would get a pico for your server PSU and try using only the server PSU. If you are using an atx PSU for the mobo and a server psu for everything else without joining them; this can cause problems.
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
fullzero (OP)
|
|
August 11, 2017, 06:13:29 PM |
|
Hi guys, if posted prior my apologies as I tried to search this thread and the global threads.
My question is in regards to 'Maximus007_Auto_Temperature_control'
When I have it on it doesnt matter what I set the 'target_temp' for each card at it seems to like running the cards at 70 to 80 degrees and will up and down scale the fans to keep them there. Fans are at 30 - 35%.
I prefer a temp of 55 to 60.
Then I thought I would turn it off but even if I set manual fan to yes and the auto temp to 'no' my fan speed of 65% is not reflected so I think the script runs regardless of what you put in 1bash.
Anyone had this issue and either (a) found a way to make it respect the selected temperature or (b) disable it and allow for manual fans?
Many thanks!
change: TARGET_TEMP_0=60
TARGET_TEMP_1=60
TARGET_TEMP_2=60
TARGET_TEMP_3=60
TARGET_TEMP_4=60
TARGET_TEMP_5=60
TARGET_TEMP_6=60
TARGET_TEMP_7=60
TARGET_TEMP_8=60
TARGET_TEMP_9=60
TARGET_TEMP_10=60
TARGET_TEMP_11=60
TARGET_TEMP_12=60
TARGET_TEMP_13=60 for b see: https://bitcointalk.org/index.php?topic=1854250.msg20730240#msg20730240Hi Fullzero, With a fresh install of NvOC , changing target temps doesnt do anything on my rig. The fans do move up and down but they dont maintain target temp. For example I set target temp as per your note to 60 and the cards run at 80. The fans go up and down on each card to maintain 80. The expected result is that they go faster to say 55% so the card runs at 60. If I follow the steps in (b) this doesnt do anything different. I am using v17 , was this an issue in 17? Or could it be my cards causing the issue I am in Australia and we have celcius as our default temperature and you guys use farenheit could that be an issue somewhere? In version v15 if I set manual fans to 70% they ran at 70% - for me in this version they seem to do their own thing I think living in Australia doesn't have anything to do with 'Maximus007_Auto_Temperature_control' script I would suggest try V18 and try the above suggested options, there were issues in v17 (I had similar one) so better try v18. If the issue still persists in V18 share your 1bash with me, i will compare it to mine and see if there is any issue. EDIT : Lets give fullzero max time on development getting done for next releases by solving the minor issues ourselves No worries ill download v18 and give that a shot. Is there a forum for minor issues such as this one as I agree with your suggestion. damNmad is right; using v0018 and the updated files from the top of the OP should solve this problem.
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
fullzero (OP)
|
|
August 11, 2017, 06:17:28 PM |
|
hmmmm i think it stay on that power limit, like now i try dual_eth_sc, i set power to 55, but in nvdia-smi i get 55w now seems oK are u lagging on dual_sia after a couple of hours then ang error of temperature cant read? a pl of 50 will not work as 53 is the minimum pl for a 1050. If you try to set a pl outside of the acceptable range; no powerlimit will be used. 75 is the max for a 1050; so choose a value >= 53 and <= 75
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
fullzero (OP)
|
|
August 11, 2017, 06:25:21 PM |
|
Ok I was able to root and pull the current specs of my cards. This is an 4x Gigabyte gtx 10606gb rig. I have my MC set to 1050 in 1bash and if I'm reading this right it says I'm at a current clock of 8748 with a max of 8754. How do I get more than a 750 MC increase? If u want to mine SIGT u have to lower your MemTransferRate and up your nvclock http://imgur.com/a/yZuOEBe in root and nvidia-settings -a /GPUGraphicsClockOffset[3]=value nvidia-settings -a /GPUMemoryTransferRateOffset[3]=value U can specify by GPU, like the other command nvidia-settings -a [gpu:0]/GPUGraphicsClockOffset[3]=value nvidia-settings -a [gpu:0]/GPUMemoryTransferRateOffset[3]=value I am mining Eth Is this what I need to do to get my cards on performance level 3? I currently have in 1bash CC=0 MC=950 But it doesn't appear to go past a MC of 750, in the Nvidia xserver it shows level 2 as highlighted and level 0,1,3 as greyed out and level 3 shows the clock that I have set in 1bash. Also something else I noticed this morning I have the powerlimit set to 75w right now in1bash. When I start up everything runs smoothly for about 15 minutes, then one of my cards changes from a PL of 75 up to 125 and my MH/s drops from 161 down to 142. I tested the rig with the card disconnected and it still has a 15-20 MH/s drop after about 15 minutes. So is my question/problem to complicated? Or am I that much of a noob you all just laugh it off and ignore me all together? I responded to you earlier; see: https://bitcointalk.org/index.php?topic=1854250.msg20731533#msg20731533let me know if that works
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
fullzero (OP)
|
|
August 11, 2017, 06:32:00 PM |
|
Hi! I'm about to build a rig with Pentium G4400. But after reading about Skylake issues with hyper threading don't know should I use it or better to return and exchange it with i3?
i have a rig runs 8 cards with G3900, no problem. I have a rig with G3900 and 10 cards, but it seems that the G3900 is bottlenecking the system. First core uses 100%, the other around 20%. Is there a way to split the workload on both cores (If I could run EWBF miner in two terminals or is there some other way)? Can somebody please help me, i'm a noob in linux. nvOC is a great system. Thanks for all the work. I tried opening two miners in two screens with some change in 1bash: screen -dmS minerX1 $HCD --eexit 3 --fee $EWBF_PERCENT --cuda_devices 0 1 2 3 4 --pec --server $ZEC_POOL --user $ZECADDR --pass z --port $ZEC_PORT; screen -dmS minerX2 $HCD --eexit 3 --fee $EWBF_PERCENT --cuda_devices 5 6 7 8 9 --pec --server $ZEC_POOL --user $ZECADDR --pass z --port $ZEC_PORT; After the change there are two processes in System monitor, but CPU usage is still the same (100% one core, 20% second core). Is it possible that System monitor doesn't show the correct CPU utilization? Will it help if I change the CPU from G3900 to i3 or perhaps i5? Fullzero, I see You have 13 GPUs on Asrock H110 PRO BTC (I am using the same motherboard). What kind of CPU do you have so that everything is working smoothly? Using a kabylake i5; I'm making another 13x rig soon with a g4560; I'll let you know if it works well as well. Thanks for the info. I will buy an i5. It looks like the G3900 is not strong enough. Regarding g4560: Is the Intel HyperThreading Bug fixed for ASrock H110 PRO BTC by default? And thanks for all the work on nvOC and great support by you and all the other forum members. g4560 works as well. I don't believe the H110 chipset has the HT bug; but I could be wrong. I also haven't tested with a skylake CPU. If one is buying a new CPU for this mobo; I recommend using a Kabylake g4560 or higher as it will unlock 2400 for ram.
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
fullzero (OP)
|
|
August 11, 2017, 06:38:08 PM |
|
yeah I see it i did not think nvidia did that. below is somthing that happens with eth and amd okay it the card was close to 7mh = over heat auto down clock if the is close to 4mh = the 4mh bug bascially power off plug a monitor into 1st card boot see what happens does not work shut down boot again does not work shut down move monitor to card 2 boot never saw the 4mh bug with a nvidia card and eth but I do not use nvidia with eth. I agree with Phil; that is an AMD problem. I might have a software fix for that 4mh problem / degrading hashrates on AMD gpus, will include it in the next rxOC.
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
|