|
fullzero (OP)
|
 |
July 03, 2017, 06:41:54 PM |
|
Hi guys I am very happy with the stability of my rig but I am still trying to get my head around the overclocking.
I dont seem to get much difference between the following combos
Cc 100 mem 100
Cc 100 mem 600
CC 100 mem 1100
Cc -100 mem 1100
CC -200 mem 1100
They all yeild around 24.5 MHs on ETH and 570 MHs in SC
Sometimes I get some nice results which I cant get again. For example I tried CC -50 and mem 1100 and I had 27 ETH and 570 SC
I tried some other settings then decided -50 and 1100 was the winner only to find this time I get my normal 25 ETH results. After writing down 50 different combinations and re doing them 3x each I am convinced they all do the same thing.
If I use these cards in windows I can hit 28 ETH and 530 SC with MSI after burner.
I am using ASUS GTX 1070 Turbos which are lower end 1070s unfortunately. ( Im not expecting founders edition results! )
I did have the one video card setup issue which caused my xorg to default but this is now fixed. ( I can see all card limits set when terminal opens and I can see the settings on the Nvidia server )
Im thinking maybe my process is wrong or am I simply wanting too much out of the cards?
To try new settings I close terminal, edit onebash, save onebash, close onebash and open terminal. ( do I need yo reatart nvOC at the power? )
I write down the first 10 results and take the average.
With MSI afterburner when I move the sliders I see some big changes but with nvOC the numbers change by small increments and if I do get a big jump I cant seem to re produce it with identical settings at a future date.
If my process is wrong or if my results are about right in Linux I would aporeciate the feedback, thanks!
I think you are using too low of a powerlimit and this is preventing higher OC from making a difference. What powerlimit are you using? When dual mining you need to use a higher powerlimit; ensure: POWERLIMIT="YES"
POWERLIMIT_WATTS=125 or higher maybe up to 135 . I don't have any ASUS GTX 1070 Turbos so I don't know what is OPT for them. |
|
|
|
|
|
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)
|
|
July 03, 2017, 06:44:46 PM |
|
Hi Guys,
I continue the trying to switch to dwarfpool from nanopool. v17 nvOC, same hw and other sw params, just the pool is the different.
claymore:
ETH - Total Speed: 211.976 Mh/s, Total Shares: 832, Rejected: 0, Time: 02:11
ETH: GPU0 30.360 Mh/s, GPU1 30.396 Mh/s, GPU2 30.362 Mh/s, GPU3 30.394 Mh/s, GPU4 30.543 Mh/s, GPU5 29.973 Mh/s, GPU6 29.947 Mh/s
genoil:
m 03:45:20|ethminer Mining on PoWhash #7a75ced3 : 182.44MH/s [A3+0:R0+0:F0]
m 03:45:21|ethminer Mining on PoWhash #7a75ced3 : 190.81MH/s [A3+0:R0+0:F0]
m 03:45:21|ethminer Mining on PoWhash #7a75ced3 : 185.98MH/s [A3+0:R0+0:F0]
m 03:45:22|ethminer Mining on PoWhash #7a75ced3 : 189.03MH/s [A3+0:R0+0:F0]
m 03:45:22|ethminer Mining on PoWhash #7a75ced3 : 182.75MH/s [A3+0:R0+0:F0]
m 03:45:23|ethminer Mining on PoWhash #7a75ced3 : 186.61MH/s [A3+0:R0+0:F0]
m 03:45:24|ethminer Mining on PoWhash #7a75ced3 : 178.26MH/s [A3+0:R0+0:F0]
m 03:45:24|ethminer Mining on PoWhash #7a75ced3 : 187.75MH/s [A3+0:R0+0:F0]
m 03:45:25|ethminer Mining on PoWhash #7a75ced3 : 183.28MH/s [A3+0:R0+0:F0]
m 03:45:25|ethminer Mining on PoWhash #7a75ced3 : 189.52MH/s [A3+0:R0+0:F0]
m 03:45:26|ethminer Mining on PoWhash #7a75ced3 : 183.68MH/s [A3+0:R0+0:F0]
Can anybody explain the difference? The genoil is the worse, I dont know why.
I use an other rig exactly the same hw and sw just genoil and nanopool. Here I got 216 MH/s.
Any idea or suggession?
Thank you!
What are your settings? for 1070s with genoil I would use: POWERLIMIT="YES"
POWERLIMIT_WATTS=110
__CORE_OVERCLOCK=-200
MEMORY_OVERCLOCK=900
MANUAL_FAN="YES"
FAN_SPEED=75 or higher note the core clock is negative: -200 power limit: 100 core: 110 mem: 1300 I tried your settings and nothing changed. :-( nanopool + genoil: 216, dwarfpool + genoil: 180 I have written to dwarfpool admin but have not got solution. Any new idea? I like the nanopool's web admin page but do not like the 1% fee. I would like to switch only for this. What your favourite pool and why? Thanks! I am currently using Nicehash with Genoil for my Ethash optimized rigs; and slushpool for my Equihash optimized rigs. The better Genoil hashrate + no fee makes up for the nicehash fee. |
|
|
|
|
|
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)
|
|
July 03, 2017, 06:46:34 PM |
|
How come I don't see the Pastebin option in v0017 of the oneBash? I've downloaded a fresh copy and cannot find it.Never mind, I'm a dofus. It's in the 2unix file. Is this just one line to implement? wget http://pastebin.com/link I made a guide its linked on the OP; but here its is anyway: https://bitcointalk.org/index.php?topic=1854250.msg19785891#msg19785891 |
|
|
|
|
|
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
|
|
|
cvitanihc0011
Newbie
 Offline
Activity: 35
Merit: 0
|
|
July 03, 2017, 06:54:45 PM |
|
Anybody managed to dual mine ? If so ... I need to edit something in this section for ETH intensity ? if [ $COIN == "DUAL_ETH_SC" ] In windows I had -ethi x -dcri y . Here I see only dcri. I have to add ethi on that line or on top of the oneBash in the ETH_EXTENTION_ARGUMENTS section ? So many new things since I first found this 3 weeks ago  |
|
|
|
|
weareken
Newbie
Offline
Activity: 27
Merit: 0
|
|
July 03, 2017, 06:56:35 PM |
|
@Fullzero - thanks so much. This is working so well for me. A few requests if I could be be so selfish: 1) Can you confirm that this version of Genoil the optimizations merged from this pull request? Seems like people are getting 6%-10% performance improvement on GTX 1060's ( https://github.com/Genoil/cpp-ethereum/pull/228) 2) Any chance of adding in the Creep Miner for Burstcoin (proof of capacity) mining ( https://github.com/Creepsky/creepMiner). Then we'd have GPU, CPU, and Hard Drive mining in one! 3) Beyond cleaning out headers, are there other ways to get the image smaller so we can have more disk space, and/or offer a bigger image because most of us are using 32GB thumb drives? I like to add a few personalizations but don't have the space to download all the dependencies and make the apps Keep up the great work! |
|
|
|
|
|
fullzero (OP)
|
|
July 03, 2017, 06:56:52 PM |
|
Seems like 6x pin powered risers solved my issue with 1050ti's crashing. Thanks a lot @fullzero and others
I bought a couple of those recently to use with my 1070s...have a Spotswood frame on the way after finding a tower case inadequate for keeping even two GPUs cool, let alone four or more: http://amzn.to/2sF7wm5One didn't work at all. The other appears to run OK at first, but as soon as the miner software starts hammering the card, the card falls off the bus and quits working until at least a reset (or did it need a power cycle?). I went into the BIOS settings and set the PCIe slots to their slowest setting; that didn't help. I might still have some ribbon risers hiding in a box; I never had trouble with them in the past (last used them with two Radeons (HD 6870 and HD 7750) on an Intel D945GNT), but I don't know if they'd have enough reach to load up the frame with 8 GPUs. Is there a longer ribbon riser available than 12"? If not, what USB (or other cable type) risers have been less troublesome than others? (In the meantime, swapping GPUs around so the hotter-running one is on the bottom has helped. At 125W each and fans on automatic, the upper GPU with better cooling stays in the low 70s, while the lower GPU stays in the upper 70s while mining Equihash. Fans at 75% keep both GPUs in the 60s.) Please use full url's / non reference links in the future. I recommend getting risers from hawkfish007: pm hawkfish007 pcie powered risers 6x pack or via Amazon if you want ~$10 moreYou can use longer USB cables with these risers if you want; but they should be long enough for almost all use cases. |
|
|
|
|
|
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)
|
|
July 03, 2017, 07:02:03 PM |
|
Nice work  I will integrate this into the next oneBash / v0018. I will keep your default BTC address and ensure it is clear you implemented the instantaneous profit switching algorithm. I do think with when using different algos in makes sense to have different clocks; however I don't think the settings for those should be spread out over a bunch of different bash files. I will bring all the settings inside oneBash and make a: SALFTER_NICEHASH_PROFIT_SWITCHING="YES" YES / NO switch Using your implementation; it should only require a few modifications to implement other targets such as 'lowest difficulty out of a given set of coins' and more. Thanks for providing another tool to the community, Sounds like a plan. More centralized configuration probably would make it easier to add more algos. I originally had the card configuration code duplicated across all of those batch files, before I separated it out into set_power.sh. I have an idea to get rid of most of those scripts, but I've put off my paying job enough for this morning and need to hunker down to that. I will hold off on integrating this for now then (and wait for your changes); in the meantime I will make a link to your repo on the OP. |
|
|
|
|
|
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)
|
|
July 03, 2017, 07:12:24 PM |
|
Anybody managed to dual mine ? If so ... I need to edit something in this section for ETH intensity ? if [ $COIN == "DUAL_ETH_SC" ] In windows I had -ethi x -dcri y . Here I see only dcri. I have to add ethi on that line or on top of the oneBash in the ETH_EXTENTION_ARGUMENTS section ? So many new things since I first found this 3 weeks ago You should only need to switch: at the very top of oneBash there is a hardcoded -dcri 70 for this coin selection, you can add -ethi x with: ETH_EXTENTION_ARGUMENTS=" -ethi x" where x is an integer |
|
|
|
|
|
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)
|
|
July 03, 2017, 07:30:08 PM
Last edit: July 03, 2017, 08:27:26 PM by fullzero |
|
@Fullzero - thanks so much. This is working so well for me. A few requests if I could be be so selfish: 1) Can you confirm that this version of Genoil the optimizations merged from this pull request? Seems like people are getting 6%-10% performance improvement on GTX 1060's ( https://github.com/Genoil/cpp-ethereum/pull/228) 2) Any chance of adding in the Creep Miner for Burstcoin (proof of capacity) mining ( https://github.com/Creepsky/creepMiner). Then we'd have GPU, CPU, and Hard Drive mining in one! 3) Beyond cleaning out headers, are there other ways to get the image smaller so we can have more disk space, and/or offer a bigger image because most of us are using 32GB thumb drives? I like to add a few personalizations but don't have the space to download all the dependencies and make the apps Keep up the great work! 1 - yes this is new cuda implementation I used when compiling Genoil: the hash changes DRAMATICALLY as you increase the memory clock; however most of these clocks are currently unstable. I suspect most of the individuals who have reported 10% gains; did so before having a soft crash and realizing that although the client is capable of significantly higher hashrates; it is not stable with most of them. In my experience with this; I have found running the client with less cards is more stable and can reach higher OC (thus more gains). 2 - I will add this to the list. 3 - You can extend the primary partition on any key / ssd; by connecting it to a computer with nvOC that has already booted and clicking the ubuntu launcher at the top left and typing gp then click Gparted. Find the sdb drive select the larger partition; it it is mounted unmount it; then rightclick and select resize and set the max size. click the green checkmark to execute the change, wait for completion and it should be ~17gb larger. I am planning on increasing the image to 32gb + add the cmds to enable Claymore / other clients to use 16gb VM in a later version. |
|
|
|
|
|
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
|
|
|
achalmersman
Newbie
Offline
Activity: 17
Merit: 0
|
|
July 03, 2017, 08:10:52 PM |
|
Sorry im a Genoil newb. I was using Claymore until nvOC 17 and now that I am using Genoil I am getting some crashes possibly from overclock. Is there a switch or a watchdog or something to auto restart Genoil like Claymore does? I've lowered the OC a bit. For now it could be down for hours before I realize Genoil crashed. With Claymore I could just look back and see if it reset itself / instable etc. Thanks a bunch !!
A 0 hash detector / restarter has already been requested and added to the list. For now I recommend lowering your clocks / moving your powerlimit up or down (depending on what it is currently ) each time you have an error. I have stabilized all my rigs running genoil this way; and they are all outperforming claymore. Sorry I missed that had already been implemented. I had another hang less than 8 hours from the the one this morning. This time was different though. All the previous Genoil issues gave me a memory error so I attributed it to OC. This one was "Error CUDA mining: the launch timed out and was terminated. CUDA error in func 'search' at line 346: the launch timed out and was terminated. " I have no power limits set. I now have my clocks set to -100 core and +950 memory on gtx 1070s. On Claymore I was running +100 and +1150 stable. Ill see how it does now. I do believe it is still beating Claymore but I may do some 24hr tests back to back. I will add that I am now running 8 cards in this rig via 2 M.2 adapters. It does seem as though the stability issues rose not long after the last 2 cards however I had only been running V17 / Genoil a day or so before adding the 7th and 8th card. Running 6 1070s, 1 1060, and 1 970 in the nvOC rig. Thanks again for all your hard work!! Is the default address in your onebash files yours? I would like to give you some hashes |
|
|
|
|
weareken
Newbie
Offline
Activity: 27
Merit: 0
|
|
July 03, 2017, 08:24:57 PM |
|
@Fullzero - thanks so much. This is working so well for me. A few requests if I could be be so selfish: 1) Can you confirm that this version of Genoil the optimizations merged from this pull request? Seems like people are getting 6%-10% performance improvement on GTX 1060's ( https://github.com/Genoil/cpp-ethereum/pull/228) 2) Any chance of adding in the Creep Miner for Burstcoin (proof of capacity) mining ( https://github.com/Creepsky/creepMiner). Then we'd have GPU, CPU, and Hard Drive mining in one! 3) Beyond cleaning out headers, are there other ways to get the image smaller so we can have more disk space, and/or offer a bigger image because most of us are using 32GB thumb drives? I like to add a few personalizations but don't have the space to download all the dependencies and make the apps Keep up the great work! 1 - yes this is new cuda implementation I used when compiling Genoil: the hash changes DRAMITACALLY as you increase the memory clock; however most of these clocks are currently unstable. I suspect most of the individuals who have reported 10% gains; did so before having a soft crash and realizing that although the client is capable of significantly higher hashrates; it is not stable with most of them. In my experience with this; I have found running the client with less cards is more stable and can reach higher OC (thus more gains). 2 - I will add this to the list. 3 - You can extend the primary partition on any key / ssd; by connecting it to a computer with nvOC that has already booted and clicking the ubuntu launcher at the top left and typing gp then click Gparted. Find the sdb drive select the larger partition; it it is mounted unmount it; then rightclick and select resize and set the max size. click the green checkmark to execute the change, wait for completion and it should be ~17gb larger. I am planning on increasing the image to 32gb + add the cmds to enable Claymore / other clients to use 16gb VM in a later version. Awesome! You rock. What's your address for sending hashes? |
|
|
|
|
|
fullzero (OP)
|
|
July 03, 2017, 08:26:33 PM |
|
Sorry im a Genoil newb. I was using Claymore until nvOC 17 and now that I am using Genoil I am getting some crashes possibly from overclock. Is there a switch or a watchdog or something to auto restart Genoil like Claymore does? I've lowered the OC a bit. For now it could be down for hours before I realize Genoil crashed. With Claymore I could just look back and see if it reset itself / instable etc. Thanks a bunch !!
A 0 hash detector / restarter has already been requested and added to the list. For now I recommend lowering your clocks / moving your powerlimit up or down (depending on what it is currently ) each time you have an error. I have stabilized all my rigs running genoil this way; and they are all outperforming claymore. Sorry I missed that had already been implemented. I had another hang less than 8 hours from the the one this morning. This time was different though. All the previous Genoil issues gave me a memory error so I attributed it to OC. This one was "Error CUDA mining: the launch timed out and was terminated. CUDA error in func 'search' at line 346: the launch timed out and was terminated. " I have no power limits set. I now have my clocks set to -100 core and +950 memory on gtx 1070s. On Claymore I was running +100 and +1150 stable. Ill see how it does now. I do believe it is still beating Claymore but I may do some 24hr tests back to back. I will add that I am now running 8 cards in this rig via 2 M.2 adapters. It does seem as though the stability issues rose not long after the last 2 cards however I had only been running V17 / Genoil a day or so before adding the 7th and 8th card. Running 6 1070s, 1 1060, and 1 970 in the nvOC rig. Thanks again for all your hard work!! Is the default address in your onebash files yours? I would like to give you some hashes Most of them are mine; for some of the smaller alts I didn't bother to make a wallet and just added someone else's address. Thanks for hashes. let me know how genoil goes with powerlimit (probably can go lower than you would expect). |
|
|
|
|
|
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)
|
|
July 03, 2017, 08:41:26 PM |
|
Awesome! You rock.
What's your address for sending hashes?
Please use the default ZEC or NICE coin selections: Thanks for the hashes . Maxximus007 made a bash script which implements auto fan speed and if needed powerlimit changes to enact set temperature limits. MAXXIMUS007_AUTO_OPT_TEMP_CONTROL bash Link is near the top of the OP I will integrate this into the next oneBash / v0018 |
|
|
|
|
|
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
|
|
|
atlasprime
Newbie
Offline
Activity: 2
Merit: 0
|
|
July 03, 2017, 10:14:17 PM |
|
Sorry im a Genoil newb. I was using Claymore until nvOC 17 and now that I am using Genoil I am getting some crashes possibly from overclock. Is there a switch or a watchdog or something to auto restart Genoil like Claymore does? I've lowered the OC a bit. For now it could be down for hours before I realize Genoil crashed. With Claymore I could just look back and see if it reset itself / instable etc. Thanks a bunch !!
A 0 hash detector / restarter has already been requested and added to the list. For now I recommend lowering your clocks / moving your powerlimit up or down (depending on what it is currently ) each time you have an error. I have stabilized all my rigs running genoil this way; and they are all outperforming claymore. Thank you! I saw that before but didnt really put 2 and 2 together. |
|
|
|
|
gigi8114
Newbie
Offline
Activity: 2
Merit: 0
|
|
July 03, 2017, 11:23:45 PM |
|
Hi,
Trying out your OS, but first thing i'm encountering is when trying to change pools to european ones, the miner can't connect anymore (even with nanopool).
Second, when trying to use ethermine as a pool (with the switch turned to YES), it loops to read response failed end of file and cannot resolve hostname and read response failed end of file again, etc etc - no, it's not an internet or dns problem i assure, it works great.
Could you link a working onebash example with eu1.ethermine.org:4444 , so I can see what I did wrong?
|
|
|
|
|
dragnan
Newbie
Offline
Activity: 2
Merit: 0
|
|
July 04, 2017, 02:35:03 AM |
|
Greetings,
Awesome work on this distro! I'm using it on a TB250-BTC with 6x EVGA 1070 SC and trying to tweak the OC to match my Windows 10 setup.
The issue I'm running into is that I cannot increase the power limit above 170 and it's limiting my overclock and reducing overall Sol/s by around 100-150. Power is cheap where I live so the extra watts are not an issue. Using a 1000w and 1200w dual PSU setup so that is no concern either.
In Windows I can get 2850 Sol/s but only around 2700-2750 in Linux.
Do you know if the power limit cap is a limitation of the driver?
Any help is much appreciated.
Thanks,
Dragnan
|
|
|
|
|
smokinggun46
Newbie
Offline
Activity: 14
Merit: 0
|
|
July 04, 2017, 04:35:14 AM |
|
Love this OS. I've been using a new mobo: Biostar Z270GT6; got it to work all day yesterday on 5 GPUs. Tinkered a bit today, tried to boot mobo, got pass BIOS screen, then got spammed with PCIE bus error severity=corrected. It just spammed and spammed non stop, and would probably never stop if I hadn't powered down. A similar issue that is answered can be found here: https://askubuntu.com/questions/771899/pcie-bus-error-severity-corrected PS: 32GB USB still has some imaging issues, I've tried reformatting without the "quick" option, and tried both NTFS and FAT32. |
|
|
|
|
Sydewinder
Newbie
Offline
Activity: 12
Merit: 0
|
|
July 04, 2017, 05:24:34 AM |
|
Love this OS. I've been using a new mobo: Biostar Z270GT6; got it to work all day yesterday on 5 GPUs. Tinkered a bit today, tried to boot mobo, got pass BIOS screen, then got spammed with PCIE bus error severity=corrected. It just spammed and spammed non stop, and would probably never stop if I hadn't powered down. A similar issue that is answered can be found here: https://askubuntu.com/questions/771899/pcie-bus-error-severity-corrected PS: 32GB USB still has some imaging issues, I've tried reformatting without the "quick" option, and tried both NTFS and FAT32. did you change picie to gen 2 in the bios? |
|
|
|
|
|
fullzero (OP)
|
|
July 04, 2017, 06:03:05 AM |
|
Greetings,
Awesome work on this distro! I'm using it on a TB250-BTC with 6x EVGA 1070 SC and trying to tweak the OC to match my Windows 10 setup.
The issue I'm running into is that I cannot increase the power limit above 170 and it's limiting my overclock and reducing overall Sol/s by around 100-150. Power is cheap where I live so the extra watts are not an issue. Using a 1000w and 1200w dual PSU setup so that is no concern either.
In Windows I can get 2850 Sol/s but only around 2700-2750 in Linux.
Do you know if the power limit cap is a limitation of the driver?
Any help is much appreciated.
Thanks,
Dragnan
The effective powerlimit should be the same; in windows it is in %TDP and in linux in is in watts. If you set the powerlimit above the acceptable range; no powerlimit will be set (but you will see output telling you the acceptable range). If you look at the top of the mining process it should tell you if the powerlimit was successfully applied or not. Also; the OC curve is different in Linux than it is in windows. You will need to use higher clocks to achieve the same hashrate; but you can use higher clocks than you can in windows. |
|
|
|
|
|
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
|
|
|
tiefschwarz
Newbie
Offline
Activity: 4
Merit: 0
|
|
July 04, 2017, 06:04:47 AM |
|
Hi fullzero,
great work on this distro.
My next rig will be based on a biostar tb250 btc pro with 12 PCIe Interfaces. Do you know if i can use 12 similar nvidia cards or will there be any limitations of the driver like in Windows (max. 8 GPUs of a kind)?
Cheers
tiefschwarz
|
|
|
|
|
|
