[OS] nvOC easy-to-use Linux Nvidia Mining

[Nexillus]

I'm really confused now, it just happened on VER15 within 15 minutes... With a different USB drive...

To my knowledge this should not be happening since these are 8GB cards and it will hit 3GB DAG file next year for ETH...

I've had these errors once too, but it was OC. Your temps are nice so that's not the issue. Lower both OC and MC with 100, see if it is stable then. If so, go up with 50, MC first.

I would try Maxximus007's suggestion.

Let me know if you keep getting these errors.

It is also possible that having less free space contributes to these errors with claymore; I think I am going to increase the size of the primary partition to very close to 16gb for the next version for this reason. 

Optimally for claymore you should have up to 16gb of free space and use it as virtual memory, I am considering pushing the size to 32gb and implementing this in an alternative build for better ethash mining.

I changed the OC by mem by 15 and it has been solid for the last 90 minutes. I just think it is very odd since it was on the OC for almost a week. I didn't know you changed the primary partition, I think many of us are using 32GB USB keys too.

[fullzero]

I'm really confused now, it just happened on VER15 within 15 minutes... With a different USB drive...

To my knowledge this should not be happening since these are 8GB cards and it will hit 3GB DAG file next year for ETH...

I've had these errors once too, but it was OC. Your temps are nice so that's not the issue. Lower both OC and MC with 100, see if it is stable then. If so, go up with 50, MC first.

I would try Maxximus007's suggestion.

Let me know if you keep getting these errors.

It is also possible that having less free space contributes to these errors with claymore; I think I am going to increase the size of the primary partition to very close to 16gb for the next version for this reason. 

Optimally for claymore you should have up to 16gb of free space and use it as virtual memory, I am considering pushing the size to 32gb and implementing this in an alternative build for better ethash mining.

I changed the OC by mem by 15 and it has been solid for the last 90 minutes. I just think it is very odd since it was on the OC for almost a week. I didn't know you changed the primary partition, I think many of us are using 32GB USB keys too.

You can extend the primary partition on any key, 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 will do this + add the cmds to enable Claymore to use 16gb VM in the next version.

[lhkj2000]

reserved

[pixelizedchaos]

Hello! I ran into a problem with my Msi Z270-A motherboard, so I am using 6 Asus dual 1070 OC graphics cards, and only 5 of them are being picked up. The second pci-e riser doesn't seem to be working. I tested the port, it does work and I have tested the riser cables, they all seem to be working. I am a little bit of a loss for words on what I should do to fix this problem.

What type of risers are you using, and how are they being powered?

Version 006 risers, with 2 risers plugged per port on my PSU using 6 pin to sata to molex, thanks for the help!

That sounds good for a riser setup.

First so we have a reference:

press f12 to open the guake terminal and enter the cmd:

Code:

lspci | grep VGA 

and record what it outputs + before swap for reference

Then:

shutdown and fully power down (PSU as well + click the ATX powerswitch a few times to clear any remaining power in the system)

then swap the 2nd riser (riser + cable) with the 6th gpu riser + cable

power on and enter

Code:

lspci | grep VGA 

and record what it outputs

then let me know what has been output each time.

Sorry for the delay!

Alright so something maybe worth mentioning, the boots seem to be taking significantly more time then before. (It's a problem I should be able to figure out once the GPU's are all running,

So the initial test returned:

1:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
3:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
6:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
7:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
8:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
9:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)

I was waiting for a solid 15 minutes for it to boot, and it wasn't so I used a different USB to boot since I believe the first USB might have been corrupted from all the restarts.

After here is what I got:
1:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
3:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
6:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
7:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
8:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
9:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)

[fullzero]

Hello! I ran into a problem with my Msi Z270-A motherboard, so I am using 6 Asus dual 1070 OC graphics cards, and only 5 of them are being picked up. The second pci-e riser doesn't seem to be working. I tested the port, it does work and I have tested the riser cables, they all seem to be working. I am a little bit of a loss for words on what I should do to fix this problem.

What type of risers are you using, and how are they being powered?

Version 006 risers, with 2 risers plugged per port on my PSU using 6 pin to sata to molex, thanks for the help!

That sounds good for a riser setup.

First so we have a reference:

press f12 to open the guake terminal and enter the cmd:

Code:

lspci | grep VGA 

and record what it outputs + before swap for reference

Then:

shutdown and fully power down (PSU as well + click the ATX powerswitch a few times to clear any remaining power in the system)

then swap the 2nd riser (riser + cable) with the 6th gpu riser + cable

power on and enter

Code:

lspci | grep VGA 

and record what it outputs

then let me know what has been output each time.

Sorry for the delay!

Alright so something maybe worth mentioning, the boots seem to be taking significantly more time then before. (It's a problem I should be able to figure out once the GPU's are all running,

So the initial test returned:

1:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
3:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
6:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
7:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
8:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
9:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)

I was waiting for a solid 15 minutes for it to boot, and it wasn't so I used a different USB to boot since I believe the first USB might have been corrupted from all the restarts.

After here is what I got:
1:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
3:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
6:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
7:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
8:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
9:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)

It looks like Ubuntu is detecting all 6 cards;

so lets see what happens if you remove the xorg check:

in oneBash:

the first implementation line: under the settings division:

#########################################################################

Code:

XORG="FAIL"

change this to:

Code:

XORG="OK"

and save

and start the mining process

tell me if you see OC messages at the beginning of the mining process after the ifconfig output.

[7abazlam]

So I imaged the USB properly and replaced oneBash with my own configured one. Trying to boot however seems to suffer from repeated reboots (5+ so far).

Here are my specs:

- Asus Prime Z270-p. It's not listed under fully supported boards. I still used the "all mobo nvOC" for it. Please let me know if I should use another specific image.
- 6 *  MSI GTX 1060
- Intel pentium 1151 processor

BIOS changes
- Above 4G: enabled
- Primary display: PCIE
- Audio controller: disabled

Please let me know if I missed something.

I don't know if this is your issue or not, but worth giving it a shot:

"ensure you 'Clear Secure Boot Keys' in the bios."

https://drive.google.com/file/d/0B3ra23kLdr5lblFCdTN4M2dIQUE/view?usp=sharing

Do you have the monitor connected directly to the mobo?

This is the most likely reason I can think of that the xorg would corrupt every boot.

If you have been connecting the monitor directly to the mobo, move it to the primary GPU (the one connected to the 16x pcie slot closest to the CPU) and boot, it should display the message you have been seeing once, then work normally on the second boot.

Let me know if this is not the case.

I have HDMI cable connected to primary x16 PCIE port. But thanks for your prompt answers, fullzero!

[fullzero]

So I imaged the USB properly and replaced oneBash with my own configured one. Trying to boot however seems to suffer from repeated reboots (5+ so far).

Here are my specs:

- Asus Prime Z270-p. It's not listed under fully supported boards. I still used the "all mobo nvOC" for it. Please let me know if I should use another specific image.
- 6 *  MSI GTX 1060
- Intel pentium 1151 processor

BIOS changes
- Above 4G: enabled
- Primary display: PCIE
- Audio controller: disabled

Please let me know if I missed something.

I don't know if this is your issue or not, but worth giving it a shot:

"ensure you 'Clear Secure Boot Keys' in the bios."

https://drive.google.com/file/d/0B3ra23kLdr5lblFCdTN4M2dIQUE/view?usp=sharing

Do you have the monitor connected directly to the mobo?

This is the most likely reason I can think of that the xorg would corrupt every boot.

If you have been connecting the monitor directly to the mobo, move it to the primary GPU (the one connected to the 16x pcie slot closest to the CPU) and boot, it should display the message you have been seeing once, then work normally on the second boot.

Let me know if this is not the case.

I have HDMI cable connected to primary x16 PCIE port. But thanks for your prompt answers, fullzero!

Ok try this as well and let me know:

so lets see what happens if you remove the xorg check:

in oneBash:

the first implementation line: under the settings division:

#########################################################################

Code:

XORG="FAIL"

change this to:

Code:

XORG="OK"

and save

and start the mining process

tell me if you see OC messages at the beginning of the mining process after the ifconfig output.

[pixelizedchaos]

So I imaged the USB properly and replaced oneBash with my own configured one. Trying to boot however seems to suffer from repeated reboots (5+ so far).

Here are my specs:

- Asus Prime Z270-p. It's not listed under fully supported boards. I still used the "all mobo nvOC" for it. Please let me know if I should use another specific image.
- 6 *  MSI GTX 1060
- Intel pentium 1151 processor

BIOS changes
- Above 4G: enabled
- Primary display: PCIE
- Audio controller: disabled

Please let me know if I missed something.

I don't know if this is your issue or not, but worth giving it a shot:

"ensure you 'Clear Secure Boot Keys' in the bios."

https://drive.google.com/file/d/0B3ra23kLdr5lblFCdTN4M2dIQUE/view?usp=sharing

Do you have the monitor connected directly to the mobo?

This is the most likely reason I can think of that the xorg would corrupt every boot.

If you have been connecting the monitor directly to the mobo, move it to the primary GPU (the one connected to the 16x pcie slot closest to the CPU) and boot, it should display the message you have been seeing once, then work normally on the second boot.

Let me know if this is not the case.

I have HDMI cable connected to primary x16 PCIE port. But thanks for your prompt answers, fullzero!

Ok try this as well and let me know:

so lets see what happens if you remove the xorg check:

in oneBash:

the first implementation line: under the settings division:

#########################################################################

Code:

XORG="FAIL"

change this to:

Code:

XORG="OK"

and save

and start the mining process

tell me if you see OC messages at the beginning of the mining process after the ifconfig output.

Yeah so, I have the HDMI connected to the first PCI-E x16 slot, unfortunately it seems like it is still only registering GPU (0-4) so only 5.

To clarify, its the "Second" PCI-E x16 slot that seems like it's not working, have tested it solo, it works, its just that slot that's not showing any of the GPU's during the mining process. Perhaps its a power to that pci-e x16 slot issue? 

So I tried the xorg="OK" and it doesn't seem to be working either, still showing me 5 of the 6 GPU.

MSI Z270-A Pro & 6 ASUS Dual OC 1070.

[Alquemista]

Hi there,
I just built my first mining rig, well, trying to, still awaiting for the risers, so I installed v16 and it's not mounting the oneBash partition automatically, also I set up an account with suprnova and updated my LBC details in the oneBash file I keep getting a Stratum Authentication Error, my worker is name.BLA and I set the password as 'x' as seen below in the oneBash source, nothing at all. Anyone have the same problem?

[fullzero]

So I imaged the USB properly and replaced oneBash with my own configured one. Trying to boot however seems to suffer from repeated reboots (5+ so far).

Here are my specs:

- Asus Prime Z270-p. It's not listed under fully supported boards. I still used the "all mobo nvOC" for it. Please let me know if I should use another specific image.
- 6 *  MSI GTX 1060
- Intel pentium 1151 processor

BIOS changes
- Above 4G: enabled
- Primary display: PCIE
- Audio controller: disabled

Please let me know if I missed something.

I don't know if this is your issue or not, but worth giving it a shot:

"ensure you 'Clear Secure Boot Keys' in the bios."

https://drive.google.com/file/d/0B3ra23kLdr5lblFCdTN4M2dIQUE/view?usp=sharing

Do you have the monitor connected directly to the mobo?

This is the most likely reason I can think of that the xorg would corrupt every boot.

If you have been connecting the monitor directly to the mobo, move it to the primary GPU (the one connected to the 16x pcie slot closest to the CPU) and boot, it should display the message you have been seeing once, then work normally on the second boot.

Let me know if this is not the case.

I have HDMI cable connected to primary x16 PCIE port. But thanks for your prompt answers, fullzero!

Ok try this as well and let me know:

so lets see what happens if you remove the xorg check:

in oneBash:

the first implementation line: under the settings division:

#########################################################################

Code:

XORG="FAIL"

change this to:

Code:

XORG="OK"

and save

and start the mining process

tell me if you see OC messages at the beginning of the mining process after the ifconfig output.

Yeah so, I have the HDMI connected to the first PCI-E x16 slot, unfortunately it seems like it is still only registering GPU (0-4) so only 5.

To clarify, its the "Second" PCI-E x16 slot that seems like it's not working, have tested it solo, it works, its just that slot that's not showing any of the GPU's during the mining process. Perhaps its a power to that pci-e x16 slot issue? 

So I tried the xorg="OK" and it doesn't seem to be working either, still showing me 5 of the 6 GPU.

MSI Z270-A Pro & 6 ASUS Dual OC 1070.

If you enter the following in the guake terminal (f12), what does it output?

Code:

lspci | grep VGA

[fullzero]

Hi there,
I just built my first mining rig, well, trying to, still awaiting for the risers, so I installed v16 and it's not mounting the oneBash partition automatically, also I set up an account with suprnova and updated my LBC details in the oneBash file I keep getting a Stratum Authentication Error, my worker is name.BLA and I set the password as 'x' as seen below in the oneBash source, nothing at all. Anyone have the same problem?

If you are using an ssd see the links on the OP for setting up auto launch.

With supernova you use your login as the address and the worker name is just the second portion;

BLA

if I am interpreting your post correctly.

[citronick]

I just got around to test v16.

Same error messages like below.

Getting infinite loop.

LCD connected to mobo graphics (like always in v15 and BIOS set to on board graphics not PCI)

Will test on PCI graphics later thi PM - hopefully no more infinite loops - will post results later.

Much better boot-up speed, this time can use USB3 port fully compatible with build?

I just added 5 more 20A circuits in my warehouse - fun times begins!

I can't seem to get v16 to work on tb-250.

It boots up then terminal pops up and says:

dos2unix: converting file /media/m1/1263-A96E/onebash to unix format

xorg problem detected

restarting xorg

rebooting in 5

Have tried different USB's and also booting with only one card but still have the same problem.

Anyone know what the problem might be?

Have you waited for the second boot?

If you are using one GPU it is expected that oneBash will need to rebuild the xorg file and reboot before OC will work as intended.

It should work without rebooting on the second boot; unless you have connected the monitor directly to the motherboard (always connect a monitor to the primary GPU).

I have had one member report that their rig is caught in an infinite loop of reboots; so I would like to know if this is happening to you as well.

[mkfantastico]

Hey folks,

Just got two 1070 rigs working well with nvOC v016; stable with remote via TeamViewer all working. What's the best/cleanest way to edit onebash directly on the machine, stop mining and restart with new settings? I've searched for the onebash file on the linux partition and can't seem to find it.

(Never mind, I am a moron. I figured it out).

[pixelizedchaos]

So I imaged the USB properly and replaced oneBash with my own configured one. Trying to boot however seems to suffer from repeated reboots (5+ so far).

Here are my specs:

- Asus Prime Z270-p. It's not listed under fully supported boards. I still used the "all mobo nvOC" for it. Please let me know if I should use another specific image.
- 6 *  MSI GTX 1060
- Intel pentium 1151 processor

BIOS changes
- Above 4G: enabled
- Primary display: PCIE
- Audio controller: disabled

Please let me know if I missed something.

I don't know if this is your issue or not, but worth giving it a shot:

"ensure you 'Clear Secure Boot Keys' in the bios."

https://drive.google.com/file/d/0B3ra23kLdr5lblFCdTN4M2dIQUE/view?usp=sharing

Do you have the monitor connected directly to the mobo?

This is the most likely reason I can think of that the xorg would corrupt every boot.

If you have been connecting the monitor directly to the mobo, move it to the primary GPU (the one connected to the 16x pcie slot closest to the CPU) and boot, it should display the message you have been seeing once, then work normally on the second boot.

Let me know if this is not the case.

I have HDMI cable connected to primary x16 PCIE port. But thanks for your prompt answers, fullzero!

Ok try this as well and let me know:

so lets see what happens if you remove the xorg check:

in oneBash:

the first implementation line: under the settings division:

#########################################################################

Code:

XORG="FAIL"

change this to:

Code:

XORG="OK"

and save

and start the mining process

tell me if you see OC messages at the beginning of the mining process after the ifconfig output.

Yeah so, I have the HDMI connected to the first PCI-E x16 slot, unfortunately it seems like it is still only registering GPU (0-4) so only 5.

To clarify, its the "Second" PCI-E x16 slot that seems like it's not working, have tested it solo, it works, its just that slot that's not showing any of the GPU's during the mining process. Perhaps its a power to that pci-e x16 slot issue? 

So I tried the xorg="OK" and it doesn't seem to be working either, still showing me 5 of the 6 GPU.

MSI Z270-A Pro & 6 ASUS Dual OC 1070.

If you enter the following in the guake terminal (f12), what does it output?

Code:

lspci | grep VGA

still getting
1:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
3:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
6:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
7:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
8:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
9:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)

[pixelizedchaos]

Also getting a ton of " An internal driver error occurred." and a handful of argument errors.

[Maxximus007]

I just got around to test v16.

Same error messages like below.

Getting infinite loop.

LCD connected to mobo graphics (like always in v15 and BIOS set to on board graphics not PCI)

Will test on PCI graphics later thi PM - hopefully no more infinite loops - will post results later.

Much better boot-up speed, this time can use USB3 port fully compatible with build?

I just added 5 more 20A circuits in my warehouse - fun times begins!

I can't seem to get v16 to work on tb-250.

It boots up then terminal pops up and says:

dos2unix: converting file /media/m1/1263-A96E/onebash to unix format

xorg problem detected

restarting xorg

rebooting in 5

Have tried different USB's and also booting with only one card but still have the same problem.

Anyone know what the problem might be?

Have you waited for the second boot?

If you are using one GPU it is expected that oneBash will need to rebuild the xorg file and reboot before OC will work as intended.

It should work without rebooting on the second boot; unless you have connected the monitor directly to the motherboard (always connect a monitor to the primary GPU).

I have had one member report that their rig is caught in an infinite loop of reboots; so I would like to know if this is happening to you as well.

Hi, you should NOT connect your monitor to the onboard graphics! That wil ruin the xorg.conf, so please move it to the primary PCI card. The new V0016 is checking your xorg.conf, correcting these issues, so after moving to the PCI card, you will have one more reboot and after that it should work.

[Alquemista]

Hi there,
I just built my first mining rig, well, trying to, still awaiting for the risers, so I installed v16 and it's not mounting the oneBash partition automatically, also I set up an account with suprnova and updated my LBC details in the oneBash file I keep getting a Stratum Authentication Error, my worker is name.BLA and I set the password as 'x' as seen below in the oneBash source, nothing at all. Anyone have the same problem?

If you are using an ssd see the links on the OP for setting up auto launch.

With supernova you use your login as the address and the worker name is just the second portion;

BLA

if I am interpreting your post correctly.

Thank you, working perfectly now. Sorry english isn't my first language, thanks for your help and for this great distro.

[Maxximus007]

So I imaged the USB properly and replaced oneBash with my own configured one. Trying to boot however seems to suffer from repeated reboots (5+ so far).

Here are my specs:

- Asus Prime Z270-p. It's not listed under fully supported boards. I still used the "all mobo nvOC" for it. Please let me know if I should use another specific image.
- 6 *  MSI GTX 1060
- Intel pentium 1151 processor

BIOS changes
- Above 4G: enabled
- Primary display: PCIE
- Audio controller: disabled

Please let me know if I missed something.

I don't know if this is your issue or not, but worth giving it a shot:

"ensure you 'Clear Secure Boot Keys' in the bios."

https://drive.google.com/file/d/0B3ra23kLdr5lblFCdTN4M2dIQUE/view?usp=sharing

Do you have the monitor connected directly to the mobo?

This is the most likely reason I can think of that the xorg would corrupt every boot.

If you have been connecting the monitor directly to the mobo, move it to the primary GPU (the one connected to the 16x pcie slot closest to the CPU) and boot, it should display the message you have been seeing once, then work normally on the second boot.

Let me know if this is not the case.

I have HDMI cable connected to primary x16 PCIE port. But thanks for your prompt answers, fullzero!

Ok try this as well and let me know:

so lets see what happens if you remove the xorg check:

in oneBash:

the first implementation line: under the settings division:

#########################################################################

Code:

XORG="FAIL"

change this to:

Code:

XORG="OK"

and save

and start the mining process

tell me if you see OC messages at the beginning of the mining process after the ifconfig output.

Yeah so, I have the HDMI connected to the first PCI-E x16 slot, unfortunately it seems like it is still only registering GPU (0-4) so only 5.

To clarify, its the "Second" PCI-E x16 slot that seems like it's not working, have tested it solo, it works, its just that slot that's not showing any of the GPU's during the mining process. Perhaps its a power to that pci-e x16 slot issue? 

So I tried the xorg="OK" and it doesn't seem to be working either, still showing me 5 of the 6 GPU.

MSI Z270-A Pro & 6 ASUS Dual OC 1070.

If you enter the following in the guake terminal (f12), what does it output?

Code:

lspci | grep VGA

still getting
1:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
3:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
6:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
7:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
8:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)
9:00.0 VGA compatible controller: Nvidia Corporation Device 1b81 (rev a1)

Well that is 6, so the cards are there. If I understand it correctly, the mining software sees only 5 after starting up? That can be a power issue. The riser was powered you wrote, the card is powered correctly as well?
In a guake terminal (F12), what shows

Code:

nvidia-smi

?

This is how the last part looks like here (same MB, 6 1070 Gigabyte):

Code:

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|    0      1168    G   /usr/lib/xorg/Xorg                             110MiB |
|    0      1820    G   compiz                                          33MiB |
|    0      2349    C   /home/m1/zec/v3_4/miner                        593MiB |
|    1      1168    G   /usr/lib/xorg/Xorg                               7MiB |
|    1      2349    C   /home/m1/zec/v3_4/miner                        593MiB |
|    2      1168    G   /usr/lib/xorg/Xorg                               7MiB |
|    2      2349    C   /home/m1/zec/v3_4/miner                        593MiB |
|    3      1168    G   /usr/lib/xorg/Xorg                               7MiB |
|    3      2349    C   /home/m1/zec/v3_4/miner                        593MiB |
|    4      1168    G   /usr/lib/xorg/Xorg                               7MiB |
|    4      2349    C   /home/m1/zec/v3_4/miner                        593MiB |
|    5      1168    G   /usr/lib/xorg/Xorg                               7MiB |
|    5      2349    C   /home/m1/zec/v3_4/miner                        593MiB |
+-----------------------------------------------------------------------------+

[dittie]

Anyone knows if EWBF will be updated to 0.3.4b ? Any reasons to do so ? I see 2% dev fee was added though but hashrate suppose to also increase by 2%.

Thanks

You can do it yourself if you want, see some pages back. It's about 1-2% faster but dev fee is a fixed 2%. Currently the only reason I see is that you'd want the new monitoring page. Personally I keep 3.3b running.

I agree with Maxximus007; but added the ability to choose between the two with v0016 as some members want to use 3.4.

I will run some rigs on each version and will be able to give solid data on relative performance later.

Great software fullzero! Thanks!

Do you have the results for the EWBF performance? I'm still running 0.3.3 now but would like to know if its worth it to switch to 0.3.4.

If I would be getting new 1080's, would you recommend me going for the Ti version or is the performance difference with the normal 1080 small?

[Nexillus]

I'm really confused now, it just happened on VER15 within 15 minutes... With a different USB drive...

To my knowledge this should not be happening since these are 8GB cards and it will hit 3GB DAG file next year for ETH...

I've had these errors once too, but it was OC. Your temps are nice so that's not the issue. Lower both OC and MC with 100, see if it is stable then. If so, go up with 50, MC first.

I would try Maxximus007's suggestion.

Let me know if you keep getting these errors.

It is also possible that having less free space contributes to these errors with claymore; I think I am going to increase the size of the primary partition to very close to 16gb for the next version for this reason.  

Optimally for claymore you should have up to 16gb of free space and use it as virtual memory, I am considering pushing the size to 32gb and implementing this in an alternative build for better ethash mining.

I changed the OC by mem by 15 and it has been solid for the last 90 minutes. I just think it is very odd since it was on the OC for almost a week. I didn't know you changed the primary partition, I think many of us are using 32GB USB keys too.

You can extend the primary partition on any key, 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 will do this + add the cmds to enable Claymore to use 16gb VM in the next version.

This is starting to be very frustrating overall, after 8 hours it just "froze" no crash, no failure just frozen... Had to hard reset it.

Another  question is, what is people's variance on hashrate? I have my go up and down quite often between 177-180. Sometimes goes down to 175. Anyone else have variance with mining? Is this caused by dual mining?

I am starting to think a possible hardware failure somewhere with the lack of stability in the rig..