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.

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.

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.

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

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.

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.

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.

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 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:

Code:

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.

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

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

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

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.

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:

Code:

COIN="DUAL_ETH_SC"

at the very top of oneBash

there is a hardcoded -dcri 70 for this coin selection, you can add -ethi x with:

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.

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

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.