Bitcoin Forum
November 18, 2024, 02:37:12 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 [73] 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 ... 416 »
  Print  
Author Topic: [OS] nvOC easy-to-use Linux Nvidia Mining  (Read 418244 times)
fullzero (OP)
Hero Member
*****
Offline Offline

Activity: 882
Merit: 1009



View Profile
July 03, 2017, 04:34:42 AM
 #1441

I didn't change any IPv6 settings with nvOC.  I'm not sure what the problem might be.  If you figure it out let me know, so I can apply it for the next version.

The cmd:

Code:
sudo dhclient -v -r 

(might help solve the problem, but probably not)

As you guessed, it didn't help.

Quote
there is a website:

test-ipv6.com

it attempts to help you identify the source of IPv6 problems; it might help, but probably will only tell you what you already know.

I tried bringing this up in Links, but it needs JavaScript to work.  I'd need to move the rig closer to where I can plug in a monitor, keyboard, and mouse to see what SJWfox says...maybe tomorrow, as I also want to move nvOC off of an SD card in a USB reader stick to the mining rig's M.2 SATA SSD.

In the meantime, I've gotten enough of a workaround set up that (1) apt-get upgrade works and (2) I have an auto-switcher up and running, as mentioned in my previous post.

It will be nice when there is no more NAT to deal with; although there will need to be better parameter security.

This afternoon, I knocked together a simple profitability auto-switcher that works with nvOC and NiceHash:

https://gitlab.com/salfter/nvoc-nicehash-switcher

It might also work if you're mining elsewhere, though profitability is determined by NiceHash (as exposed through their API).  It's a Python script that gathers information about what's profitable and calls shell scripts to reconfigure overclocking settings and launch miners on a per-algorithm basis.  It replaces oneBash for normal operation; oneBash is only needed for initial setup or to add/remove GPUs (it manages /etc/X11/xorg.conf).

Nice work  Smiley

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,  Smiley

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)
Hero Member
*****
Offline Offline

Activity: 882
Merit: 1009



View Profile
July 03, 2017, 04:41:25 AM
Last edit: July 03, 2017, 05:17:20 AM by fullzero
 #1442

I noticed a second terminal can be run that auto executes the onebash script, essentially running two (?) instances of ewbf miner on the same PC.  Sol/s drops 30%, but i exited the second one before seeing any results.  I might test it out more later, i wonder if i can run 2 instances, but at 70% solo rate; which still nets 40% more.  

I'm sure people here and full zero mustk now this doesn't work in the way i'm thinking.

It is highly unlikely there will be gains from running multiple instances of the same mining client; but I am open to experiments.  

You run multiple instances (it will be a lot less stable; the more so with each additional instance).

Let me know if you think it makes a difference.

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 Offline

Activity: 2
Merit: 0


View Profile
July 03, 2017, 06:56:54 AM
 #1443

Firstly thank you for this offering. Its my first time working with linux and it has been Quite educational and refreshing from windows.

My first issue thus far involves startup. Once the UI appears, terminal opens but repeatly says onebash does not exist. If i close terminal and reopen, it processes the bash and begins mining. Thoughts?

My second problem is a hard freeze though this happened in windows as well. I think i have a bad riser in the mix.
ijduncan
Newbie
*
Offline Offline

Activity: 21
Merit: 0


View Profile
July 03, 2017, 07:12:41 AM
 #1444

This afternoon, I knocked together a simple profitability auto-switcher that works with nvOC and NiceHash:

https://gitlab.com/salfter/nvoc-nicehash-switcher

It might also work if you're mining elsewhere, though profitability is determined by NiceHash (as exposed through their API).  It's a Python script that gathers information about what's profitable and calls shell scripts to reconfigure overclocking settings and launch miners on a per-algorithm basis.  It replaces oneBash for normal operation; oneBash is only needed for initial setup or to add/remove GPUs (it manages /etc/X11/xorg.conf).

Nice work  Smiley

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,  Smiley
[/quote]


This is really amazing work.
citronick
Legendary
*
Offline Offline

Activity: 1834
Merit: 1080


---- winter*juvia -----


View Profile
July 03, 2017, 07:22:43 AM
 #1445

This afternoon, I knocked together a simple profitability auto-switcher that works with nvOC and NiceHash:

https://gitlab.com/salfter/nvoc-nicehash-switcher

It might also work if you're mining elsewhere, though profitability is determined by NiceHash (as exposed through their API).  It's a Python script that gathers information about what's profitable and calls shell scripts to reconfigure overclocking settings and launch miners on a per-algorithm basis.  It replaces oneBash for normal operation; oneBash is only needed for initial setup or to add/remove GPUs (it manages /etc/X11/xorg.conf).

Nice work  Smiley

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,  Smiley


This is really amazing work.
[/quote]

wow.... genius!

If I provided you good and useful info or just a smile to your day, consider sending me merit points to further validate this Bitcointalk account ~ useful for future account recovery...
newmz
Sr. Member
****
Offline Offline

Activity: 372
Merit: 250


The road of excess leads to the palace of wisdom


View Profile
July 03, 2017, 08:58:33 AM
 #1446

@ fullzero  

here is a really detailed build of the nvoc0017  with 2 nvidia 1070's on a

GIGABYTE GA-Z270P-D3 LGA1151 Intel Z270 2-Way Crossfire ATX DDR4 Motherboard.

to all this is a solid board  really good

I tested stable up to 5 amd rx 480's  on win 10 and smos
I tested stable up to 4 1080 ti's on win 10 and win 7  tested up to 3 on nvoc

I am sure it will do 5  on all of the above well maybe not win 7.  I just did not test that high on all os's

https://bitcointalk.org/index.php?topic=1998198.0

Can I ask: why do you go for the higher end CPU?

I've been running 2 eth rigs on Asrock H81 Pro BTC boards for over a year, mostly using Ethos (which is an AMD linux mining distro). I recently started to convert to Nvidia so I'm using the same setup but one of them now using nvOC and 2 1070s + 3 1060s. I always used the cheapest low end pentium (I forget exactly which - 2 cores 3.3GHz) and it was always fine. Seems fine in nvOC so far too. Unless you want to run that XMR CPU miner I guess.

Crypto currency enthusiast and miner since 2015. Mined approx 200 ETH during 2016 and 2017 and sold it at approximately $US40 each. Then I watched it reach $1000+ each. If anyone bothers to read this stuff pay attention to this: HODL HODL HODL HODL HODL HODL

I started mining with 1 AMD 7950 and 1 R9-280X. Then I gradually built my AMD operation into 12 R9-290s. Awesome ETH hash but ridiculous power consumption and heat. Over the last year I defected to the Nvidia team. I now use GTX 1070s. They were expensive to buy (probably a bargain now) but awesome hash rate vs. power consumption. blah blah blah blah
Nexillus
Full Member
***
Offline Offline

Activity: 169
Merit: 100


View Profile
July 03, 2017, 12:59:55 PM
 #1447

I didn't change any IPv6 settings with nvOC.  I'm not sure what the problem might be.  If you figure it out let me know, so I can apply it for the next version.

The cmd:

Code:
sudo dhclient -v -r 

(might help solve the problem, but probably not)

As you guessed, it didn't help.

Quote
there is a website:

test-ipv6.com

it attempts to help you identify the source of IPv6 problems; it might help, but probably will only tell you what you already know.

I tried bringing this up in Links, but it needs JavaScript to work.  I'd need to move the rig closer to where I can plug in a monitor, keyboard, and mouse to see what SJWfox says...maybe tomorrow, as I also want to move nvOC off of an SD card in a USB reader stick to the mining rig's M.2 SATA SSD.

In the meantime, I've gotten enough of a workaround set up that (1) apt-get upgrade works and (2) I have an auto-switcher up and running, as mentioned in my previous post.

It will be nice when there is no more NAT to deal with; although there will need to be better parameter security.

This afternoon, I knocked together a simple profitability auto-switcher that works with nvOC and NiceHash:

https://gitlab.com/salfter/nvoc-nicehash-switcher

It might also work if you're mining elsewhere, though profitability is determined by NiceHash (as exposed through their API).  It's a Python script that gathers information about what's profitable and calls shell scripts to reconfigure overclocking settings and launch miners on a per-algorithm basis.  It replaces oneBash for normal operation; oneBash is only needed for initial setup or to add/remove GPUs (it manages /etc/X11/xorg.conf).

Nice work  Smiley

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,  Smiley

This is an AWESOME idea! I was curious though, do you really make more it being converted to BTC right away or mining the coins directly? Anyone with some feedback would be greatly appreciated.
f00ch0w
Newbie
*
Offline Offline

Activity: 36
Merit: 0


View Profile
July 03, 2017, 01:30:23 PM
Last edit: July 03, 2017, 01:40:25 PM by f00ch0w
 #1448

Seems like 6x pin powered risers solved my issue with 1050ti's crashing. Thanks a lot @fullzero and others

Now, I'm interested, is there a way to see all rigs on API and to be able to see that from outside network? If so, how to configure it with router? I got a MikroTik behind the 24-port switch.
achalmersman
Newbie
*
Offline Offline

Activity: 17
Merit: 0


View Profile
July 03, 2017, 02:02:14 PM
 #1449

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 !!
gyoztes
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
July 03, 2017, 03:09:21 PM
 #1450

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:

Code:
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!
jmooney5115
Newbie
*
Offline Offline

Activity: 38
Merit: 0


View Profile
July 03, 2017, 03:28:47 PM
 #1451

...do you really make more it being converted to BTC right away or mining the coins directly? Anyone with some feedback would be greatly appreciated.

My experience it is about the same, without the need to exchange to BTC. I've mined some ETH and HUSH straight to my wallet. I've also spent a lot of time mining for NiceHash. It is nice getting BTC up front and it's simple.

For example, say you mine ZEC for a week and don't exchange for BTC/USD. If ZEC value drops and BTC stays the same you can lose money while mining straight ZEC.
jmooney5115
Newbie
*
Offline Offline

Activity: 38
Merit: 0


View Profile
July 03, 2017, 03:29:52 PM
 #1452

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?

Code:
wget http://pastebin.com/link
salfter
Hero Member
*****
Offline Offline

Activity: 651
Merit: 501


My PGP Key: 92C7689C


View Profile WWW
July 03, 2017, 03:34:20 PM
Last edit: July 03, 2017, 04:10:56 PM by salfter
 #1453

This is an AWESOME idea! I was curious though, do you really make more it being converted to BTC right away or mining the coins directly? Anyone with some feedback would be greatly appreciated.

The last time I had lots of miners running, I was mining coins directly (first with CryptoSwitcher, then with MinerSwitcher) and exchanging them manually.  With transaction fees from my altcoin wallets to the exchange, conversion fees at the exchange, and transaction fees from the exchange to my Bitcoin wallet, they would've all added up to a decent chunk of mining revenue.  With many of these (especially the transaction fees) being fixed fees instead of percentages, the effective percentage of fees would be even higher.  I also hadn't gotten around to automating the actual altcoin-to-BTC exchange process, so there was a bit of a time suck involved in periodically logging into the exchange, sending it funds, waiting for the funds to appear, putting in bids, etc.  (I also tended to want to drive the bid up, so sales weren't likely to go through immediately.)

While I haven't yet run the numbers to quantify it, I suspect that if BTC is your goal, a service such as NiceHash is likely to work out better for a small-time operator like me.  Economies of scale work in their favor...when they go to exchange altcoins for Bitcoin, your holdings are sent along with everyone else's and processed in one transaction.  That's one transaction fee to send to the exchange and one fee to receive the results back.  It seems intuitive that this should result in more BTC in your wallet.  Whether it actually does, of course, would be an interesting test to run.

One way to minimize the impact of transaction fees if you mine directly would be to have your altcoin proceeds sent directly to exchange accounts.  Not all pools are compatible with this approach, though; in particular, any arrangement in which miners are paid out of a coinbase transaction (P2Pool, Eligius, etc.) is likely not going to work with an exchange wallet.  Beyond that, keeping substantial funds in an exchange wallet has never been a good idea.

Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR | My Bitcoin Note Generator | Pool Auto-Switchers: zpool MiningPoolHub NiceHash
Bitgem Resources: Pool Explorer Paper Wallet
Nexillus
Full Member
***
Offline Offline

Activity: 169
Merit: 100


View Profile
July 03, 2017, 03:47:13 PM
 #1454

Seems like 6x pin powered risers solved my issue with 1050ti's crashing. Thanks a lot @fullzero and others

Now, I'm interested, is there a way to see all rigs on API and to be able to see that from outside network? If so, how to configure it with router? I got a MikroTik behind the 24-port switch.

Best way to do this is to setup a OpenVPN into the network and allowing it on the same subnet. Once you VPN, the connection will act just like if you were on the home network. It will also be secure if you use higher level of encryption like AES256-CBC.
Nexillus
Full Member
***
Offline Offline

Activity: 169
Merit: 100


View Profile
July 03, 2017, 03:50:58 PM
 #1455

This is an AWESOME idea! I was curious though, do you really make more it being converted to BTC right away or mining the coins directly? Anyone with some feedback would be greatly appreciated.

The last time I had lots of miners running, I was mining coins directly (first with CryptoSwitcher, then with MinerSwitcher) and exchanging them manually.  With transaction fees from my altcoin wallets to the exchange, conversion fees at the exchange, and transaction fees from the exchange to my Bitcoin wallet, they would've all added up to a decent chunk of mining revenue.  With many of these (especially the transaction fees) being fixed fees instead of percentages, the effective percentage of fees would be even higher.  I also hadn't gotten around to automating

While I haven't yet run the numbers to quantify it, I suspect that if BTC is your goal, a service such as NiceHash is likely to work out better for a small-time operator like me.  Economies of scale work in their favor...when they go to exchange altcoins for Bitcoin, your holdings are sent along with everyone else's and processed in one transaction.  That's one transaction fee to send to the exchange and one fee to receive the results back.  It seems intuitive that this should result in more BTC in your wallet.  Whether it actually does, of course, would be an interesting test to run.

One way to minimize the impact of transaction fees if you mine directly would be to have your altcoin proceeds sent directly to exchange accounts.  Not all pools are compatible with this approach, though; in particular, any arrangement in which miners are paid out of a coinbase transaction (P2Pool, Eligius, etc.) is likely not going to work with an exchange wallet.  Beyond that, keeping substantial funds in an exchange wallet has never been a good idea.

These are very valid points, I am going to have to do some pondering on this idea.

Your sentence should be highlight and bolded lmao. One reason why I got my Trezor is the offline hardware wallet.
salfter
Hero Member
*****
Offline Offline

Activity: 651
Merit: 501


My PGP Key: 92C7689C


View Profile WWW
July 03, 2017, 03:57:01 PM
 #1456

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/2sF7wm5

One 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.)

Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR | My Bitcoin Note Generator | Pool Auto-Switchers: zpool MiningPoolHub NiceHash
Bitgem Resources: Pool Explorer Paper Wallet
salfter
Hero Member
*****
Offline Offline

Activity: 651
Merit: 501


My PGP Key: 92C7689C


View Profile WWW
July 03, 2017, 04:30:20 PM
 #1457

This afternoon, I knocked together a simple profitability auto-switcher that works with nvOC and NiceHash:

https://gitlab.com/salfter/nvoc-nicehash-switcher

Nice work  Smiley

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,  Smiley

Sounds like a plan.  Smiley 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.  Grin

Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR | My Bitcoin Note Generator | Pool Auto-Switchers: zpool MiningPoolHub NiceHash
Bitgem Resources: Pool Explorer Paper Wallet
fullzero (OP)
Hero Member
*****
Offline Offline

Activity: 882
Merit: 1009



View Profile
July 03, 2017, 06:21:09 PM
 #1458

Firstly thank you for this offering. Its my first time working with linux and it has been Quite educational and refreshing from windows.

My first issue thus far involves startup. Once the UI appears, terminal opens but repeatly says onebash does not exist. If i close terminal and reopen, it processes the bash and begins mining. Thoughts?

My second problem is a hard freeze though this happened in windows as well. I think i have a bad riser in the mix.

If you are having hard crashes without initializing the OC then it is almost assuredly due to hardware.

My guess is that you are using an SSD.

See these posts:

https://bitcointalk.org/index.php?topic=1854250.msg19328385#msg19328385

https://bitcointalk.org/index.php?topic=1854250.msg19300078#msg19300078


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)
Hero Member
*****
Offline Offline

Activity: 882
Merit: 1009



View Profile
July 03, 2017, 06:27:35 PM
 #1459

Seems like 6x pin powered risers solved my issue with 1050ti's crashing. Thanks a lot @fullzero and others

Now, I'm interested, is there a way to see all rigs on API and to be able to see that from outside network? If so, how to configure it with router? I got a MikroTik behind the 24-port switch.

Glad your 1050tis are good.  Smiley

There are a crazy number of different ways you can remotely interact with rigs.  Each as its advantages and disadvantages.

For now; I am going to finish work on my own: rather than continuing to implement each individual requested type.

When I am done, if members still want some other kind of solution; I will implement it.


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)
Hero Member
*****
Offline Offline

Activity: 882
Merit: 1009



View Profile
July 03, 2017, 06:30:15 PM
 #1460

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.

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
Pages: « 1 ... 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 [73] 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 ... 416 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!