<<  >> (p.47)
    Author Topic: [ mining os ] nvoc  (Read 418569 times)

    • cvitanihc0011
    Newbie
    *
    Offline Offline

    Activity: 35
    Merit: 0


    View Profile
    July 04, 2017, 08:24:47 AM
     #921
    Quote from: gyoztes on July 04, 2017, 07:37:11 AM
    Pls anybody explain me the difference between MANUAL_FAN="YES" + FAN_SPEED=75 and  MANUAL_FAN="NO". Stability? Consumption? Because I have used both of them and did no see difference in hash and consumption too.

    I can not find the optimized setup for 1070. Do you have suggested setup? Or the newest oneBash is the suggested?

    Thank you!

    zec - pl 125 , cc 125 , mc 650 = > 460 sols . Rig running v solid - 8 GPU
    eth - pl 85  , cc 150 , mc 1100= > 30.3mh  . Solid .. no crashes ..

    You can try different settings and see how it behaves. I don't like to watch them all day for crashes .

  • gigi8114
    Newbie
    *
    Offline Offline

    Activity: 2
    Merit: 0


    View Profile
    July 04, 2017, 09:22:07 AM
     #922
    Quote from: fullzero on July 04, 2017, 06:18:49 AM
    Quote from: gigi8114 on 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?

    are you using the Newest_oneBash linked on the OP?

    I think you might be having a problem related to the way workers were being named when their host address is less than 100.

    I fixed this in the Newest_oneBash.

    also ensure

    Code:
    ETHERMINEdotORG="YES"

    Let me know if this is the problem.


    Hi,
    I found the solution, i think it was because i tried to put a custom worker name - maybe you can include such a feature in the future?
    Also, I couldn't find how I can see the current mining process. I did see the screen -r commands, but that implies killing the current process and restarting it. I'd like to be able to see, from SSH, the current mining process without killing it. Is this possible?

  • lbrasi
    Newbie
    *
    Offline Offline

    Activity: 26
    Merit: 0


    View Profile
    July 04, 2017, 11:46:58 AM
     #923
    Quote from: gigi8114 on July 04, 2017, 09:22:07 AM
    Quote from: fullzero on July 04, 2017, 06:18:49 AM
    Quote from: gigi8114 on 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?

    are you using the Newest_oneBash linked on the OP?

    I think you might be having a problem related to the way workers were being named when their host address is less than 100.

    I fixed this in the Newest_oneBash.

    also ensure

    Code:
    ETHERMINEdotORG="YES"

    Let me know if this is the problem.


    Hi,
    I found the solution, i think it was because i tried to put a custom worker name - maybe you can include such a feature in the future?
    Also, I couldn't find how I can see the current mining process. I did see the screen -r commands, but that implies killing the current process and restarting it. I'd like to be able to see, from SSH, the current mining process without killing it. Is this possible?


    I believe you must kill the process first. When the mining process starts from boot up, you can SSH in and type

    Code:
    ps aux | grep gnome-terminal  (find the PID for gnome-terminal-server)
    kill PID
    export DISPLAY=:0
    screen -dmS rig1  (rig1 can be named whatever you like)
    screen -x rig1
    bash '/media/m1/1263-A96E/oneBash'

  • S9k
    Newbie
    *
    Offline Offline

    Activity: 26
    Merit: 0


    View Profile
    July 04, 2017, 01:09:02 PM
     #924
    Hi,

    Please help!
    I have got stuck on this problems  Huh
    My configuration:

    -ASUS PRIME Z270-P - 2 . I tried both, results are similar.
    -EVGA GeForce GTX 1080 GAMING ACX 3.0 - 2
    -MSI Geforce GTX 1080 Gaming X-  2
    -The Gigabyte power supply unit on 1200 watts


    Three video cards work perfectly in any any combinations,

    m1@m1-desktop:~$ nvidia-smi -L
    GPU 0: GeForce GTX 1080 (UUID: GPU-43453088-0fca-9442-106d-7594d157ebf2)
    GPU 1: GeForce GTX 1080 (UUID: GPU-d099b67e-f204-66fa-96dc-365a6b559a7e)
    GPU 2: GeForce GTX 1080 (UUID: GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac)
    m1@m1-desktop:~$

    m1@m1-desktop:~$ lspci |grep VGA
    01:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
    03:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
    05:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
    m1@m1-desktop:~$


    but if I add the fourth (in this case the ID GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac ), then the system falls. Here what I see in dmesg


    [   98.722227] nvidia-modeset: Allocated GPU:0 (GPU-43453088-0fca-9442-106d-7594d157ebf2) @ PCI:0000:01:00.0
    [   98.769072] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769117] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769144] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769169] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769193] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769217] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769241] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.359255] nvidia-modeset: Allocated GPU:1 (GPU-5c9c8e29-a088-90a6-2a20-b2b2b971d1fb) @ PCI:0000:05:00.0
    [   99.398991] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399035] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399063] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399087] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399112] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399136] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buff er], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399160] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.984670] nvidia-modeset: Allocated GPU:2 (GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac) @ PCI:0000:06:00.0
    [  100.619118] nvidia-modeset: Allocated GPU:3 (GPU-d099b67e-f204-66fa-96dc-365a6b559a7e) @ PCI:0000:03:00.0
    [  100.743159] NVRM: GPU at PCI:0000:01:00: GPU-43453088-0fca-9442-106d-7594d157ebf2
    [  100.743162] NVRM: GPU Board Serial Number:
    [  100.743164] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 000001e0 00000801 00000004 00000005
    [  100.743649] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000004 00000005 00000004
    [  102.432593] r8169 0000:07:00.0 enp7s0: link up
    [  102.432600] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready
    [  103.743306] nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
    [  103.773941] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
    [  105.501795] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
    [  105.501798] Bluetooth: BNEP filters: protocol multicast
    [  105.501802] Bluetooth: BNEP socket layer initialized
    [  105.613048] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
    [  105.613106] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
    [  105.704570] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
    [  105.704972] BUG: unable to handle kernel paging request at ffff88167153d830
    [  105.704974] IP: [<ffffffffc0262880>] _nv008171rm+0x620/0x780 [nvidia]
    [  105.705052] PGD 220c067 PUD 0
    [  105.705053] Oops: 0000 [#1] SMP

    Three days I try to solve a problem.
    I changed versions of BIOS (0325,0608,0610) and risers, control 4G is included, has updated NVIDIA drivers to 381.22 - nothing helps.
    Maybe somebody will have ideas?

  • tempgoga
    Newbie
    *
    Offline Offline

    Activity: 29
    Merit: 0


    View Profile
    July 04, 2017, 01:32:39 PM
     #925
    If anyone is interested my 7 card rig with all GTX1070 FE is finally stable running for the past 72 hours with the following clocks and pl:

    __CORE_OVERCLOCK_0=000
    MEMORY_OVERCLOCK_0=1400

    __CORE_OVERCLOCK_1=000
    MEMORY_OVERCLOCK_1=1400

    __CORE_OVERCLOCK_2=000
    MEMORY_OVERCLOCK_2=1300

    __CORE_OVERCLOCK_3=000
    MEMORY_OVERCLOCK_3=1600  

    __CORE_OVERCLOCK_4=000
    MEMORY_OVERCLOCK_4=1400

    __CORE_OVERCLOCK_5=000
    MEMORY_OVERCLOCK_5=1300

    __CORE_OVERCLOCK_6=000
    MEMORY_OVERCLOCK_6=1200


    INDIVIDUAL_POWERLIMIT_0=125

    INDIVIDUAL_POWERLIMIT_1=125

    INDIVIDUAL_POWERLIMIT_2=120

    INDIVIDUAL_POWERLIMIT_3=130

    INDIVIDUAL_POWERLIMIT_4=125

    INDIVIDUAL_POWERLIMIT_5=120

    INDIVIDUAL_POWERLIMIT_6=120

    i determined the power limit for the cards by their individual temperature and lowered/increased their clocks accordingly, if i give them all the same power limit GPU 3 is 10 degrees C cooler then GPU 2/5/6 while GPU 0/1/4 are right in the middle, at the current power limits all the cards are pretty much the same temp plus or minus 1 degree.

    i might be able to push GPUs 1-5 further, i suspect GPU 6 was causing my crashes since the last crash when it was clocked @ 1300 it was the only GPU to lose its sensor connections, since lowering it to 1200 everything is stable so there might be room for higher clocks on the rest of the cards.

    wish there was a way to determine which are samsung and which are micron..

  • xleejohnx
    Hero Member
    *****
    Offline Offline

    Activity: 672
    Merit: 500


    View Profile
    July 04, 2017, 01:39:01 PM
     #926
    Quote from: salfter on July 04, 2017, 07:34:35 AM
    Quote from: fullzero on July 03, 2017, 07:02:03 PM
    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.

    I've committed an update that, if it pans out, rolls everything into one Python script...no auxiliary shell scripts.  I'm testing it right now to verify that it behaves the same as the previous version.  I suspect I'll know in the morning.

    Edit: Just did some accelerated testing by manually switching to a less-profitable coin first...the script killed the miner and fired up the appropriate miner.  I think the most recent update is ready for wider testing:

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


    If I could make my nvOS stable I would like to test this
    I blame my biostar z170 board for all of my problems lol
    Maybe tomorrow I can give it a go
    As I see a super coin as the super highway and alt coins as taxis and trucks needed to move transactions. ~philipma1957

  • philipma1957
    Legendary
    *
    Online Online

    Activity: 4690
    Merit: 10956


    'The right to privacy matters'


    View Profile WWW
    July 04, 2017, 02:55:23 PM
     #927
    Quote from: xleejohnx on July 04, 2017, 01:39:01 PM
    Quote from: salfter on July 04, 2017, 07:34:35 AM
    Quote from: fullzero on July 03, 2017, 07:02:03 PM
    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.

    I've committed an update that, if it pans out, rolls everything into one Python script...no auxiliary shell scripts.  I'm testing it right now to verify that it behaves the same as the previous version.  I suspect I'll know in the morning.

    Edit: Just did some accelerated testing by manually switching to a less-profitable coin first...the script killed the miner and fired up the appropriate miner.  I think the most recent update is ready for wider testing:

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


    If I could make my nvOS stable I would like to test this
    I blame my biostar z170 board for all of my problems lol
    Maybe tomorrow I can give it a go

    my biostar z170 is flawless up to 4 cards  after that not so good.

    since I have six of them  I use  3 cards a board easy peasy that way.
    ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
    ████████████████████████████████▀██
    ██████████████████████████████▀██▄█
    ████████████████████████████▀██████
    █████████████████████████▀█████████
    ██████████████████████▀████████████
    █▄██▀▀█████████████▀███████▄▄▄█████
    ███▄████▀▀██████▀▀█████▄▄▀▀▀███████
    █████▄▄█████▀▀█▀██████████▄████████
    ████████▀▀███▄███████████▄█████████
    █████████▄██▀▀▀▀███▀▀██████████████
    ███████████▄▄█▀████▄███████████████
    ███████████████▄▄██████████████████
    		 AltairTech.io │ 〔 ⛏ Miners〔 ⌨ Parts〔 🖰 Accessories 
    _______Based in Missouri, USA._______▐__________Your One-Stop Shop for Bitcoin Mining Solutions_____________________Mining Farm Consulting__________    		.
    .🛒SHOP NOW .

  • philipma1957
    Legendary
    *
    Online Online

    Activity: 4690
    Merit: 10956


    'The right to privacy matters'


    View Profile WWW
    July 04, 2017, 02:57:44 PM
     #928
    Quote from: Gaza8143 on July 04, 2017, 02:01:53 PM


    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.

    ########

    Interesting when I first set up rig 7x cards used 1150 watts.  

    When I had PL set to 125  the power use dropped to 985w at the wall.

    Now if I turn PL off or use 135 or 140 there is zero change at the wall it still uses 985w.

    When terminal boots up I can see the PL come up but I have a theory that it is stuck at 125 and not changing.

    Is that possible?

    I have another rig that I just set up with 4 cards and it uses 785w regardless of the power setting.  On that rig the correct setting shows when terminal spools up but it is not limiting power. With 125 on each card I thought it should be 700 w max.

    Any ideas on if PL can get 'sticky' ?




    do not use the master setting  use individual.  for each card  and try
    124
    125
    126
    124
    125
    126
    ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
    ████████████████████████████████▀██
    ██████████████████████████████▀██▄█
    ████████████████████████████▀██████
    █████████████████████████▀█████████
    ██████████████████████▀████████████
    █▄██▀▀█████████████▀███████▄▄▄█████
    ███▄████▀▀██████▀▀█████▄▄▀▀▀███████
    █████▄▄█████▀▀█▀██████████▄████████
    ████████▀▀███▄███████████▄█████████
    █████████▄██▀▀▀▀███▀▀██████████████
    ███████████▄▄█▀████▄███████████████
    ███████████████▄▄██████████████████
    		 AltairTech.io │ 〔 ⛏ Miners〔 ⌨ Parts〔 🖰 Accessories 
    _______Based in Missouri, USA._______▐__________Your One-Stop Shop for Bitcoin Mining Solutions_____________________Mining Farm Consulting__________    		.
    .🛒SHOP NOW .

  • DJ ACK
    Newbie
    *
    Offline Offline

    Activity: 13
    Merit: 0


    View Profile
    July 04, 2017, 03:41:56 PM
     #929
    Does anyone know of a way to detect GPU memory vendor information in Linux?  Similar to how GPU-Z can display the info in Winblows.  I want to group my mining rig clusters based on GPU memory vendors.  I think this will dramatically help in improving stability when tweaking each card in each rig.  Grin Grin

  • lbrasi
    Newbie
    *
    Offline Offline

    Activity: 26
    Merit: 0


    View Profile
    July 04, 2017, 03:53:55 PM
     #930
    Quote from: salfter on July 04, 2017, 07:34:35 AM
    Quote from: fullzero on July 03, 2017, 07:02:03 PM
    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.

    I've committed an update that, if it pans out, rolls everything into one Python script...no auxiliary shell scripts.  I'm testing it right now to verify that it behaves the same as the previous version.  I suspect I'll know in the morning.

    Edit: Just did some accelerated testing by manually switching to a less-profitable coin first...the script killed the miner and fired up the appropriate miner.  I think the most recent update is ready for wider testing:

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


    For some odd reason since you consolidated all the code to the switch.py, now the only miner that runs is equihash.

  • tempgoga
    Newbie
    *
    Offline Offline

    Activity: 29
    Merit: 0


    View Profile
    July 04, 2017, 03:55:32 PM
     #931
    Quote from: DJ ACK on July 04, 2017, 03:41:56 PM
    Does anyone know of a way to detect GPU memory vendor information in Linux?  Similar to how GPU-Z can display the info in Winblows.  I want to group my mining rig clusters based on GPU memory vendors.  I think this will dramatically help in improving stability when tweaking each card in each rig.  Grin Grin



    I wish there was a way, i've been looking for over a week now, maybe it can only be done on windows? or maybe the tool/command just doesn't exist on linux yet?

  • xleejohnx
    Hero Member
    *****
    Offline Offline

    Activity: 672
    Merit: 500


    View Profile
    July 04, 2017, 04:42:56 PM
     #932
    Quote from: fullzero on July 04, 2017, 03:43:48 PM
    Quote from: salfter on July 04, 2017, 07:34:35 AM
    Quote from: fullzero on July 03, 2017, 07:02:03 PM
    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.

    I've committed an update that, if it pans out, rolls everything into one Python script...no auxiliary shell scripts.  I'm testing it right now to verify that it behaves the same as the previous version.  I suspect I'll know in the morning.

    Edit: Just did some accelerated testing by manually switching to a less-profitable coin first...the script killed the miner and fired up the appropriate miner.  I think the most recent update is ready for wider testing:

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


    Looks good; I will probably change this py a little when I integrate it to make it read all the variables from oneBash.



    I like the sound of this even better!!!
    As I see a super coin as the super highway and alt coins as taxis and trucks needed to move transactions. ~philipma1957

  • f00ch0w
    Newbie
    *
    Offline Offline

    Activity: 36
    Merit: 0


    View Profile
    July 04, 2017, 04:55:34 PM
    Last edit: July 04, 2017, 05:18:54 PM by f00ch0w
     #933
    Seems like the 6pin powered risers didn't solve the issue. Rig did work stable for longest period now, think it was something over 24hrs. Plugged out 1 GPU to see is 6x GPUs causing it to crash... Every GPU was on separate cable on PSU but still crashed... Out of ideas now

    EDIT: Now my x4 1070 rigs are crashing too. Same shit all over again, Either GPU1/2/3/4 has stopped working bla bla, crashes the whole rig... Can anyone provide me with a solution?

    Also, I've got a Gigabyte H110-D3A on those 1070 rigs, could that be the issue? Put one as a test back on AsRock to see for a test, will let ya know

    EDIT2: Yep, AsRock didnt make a difference. Sometimes it crashes with a freeze

  • smokinggun46
    Newbie
    *
    Offline Offline

    Activity: 14
    Merit: 0


    View Profile
    July 04, 2017, 05:12:18 PM
     #934
    Quote from: Sydewinder on July 04, 2017, 05:24:34 AM
    Quote from: smokinggun46 on 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. 

    did you change picie to gen 2 in the bios?

    On Biostar Z270GT6, the only option for selecting gen1,gen2,gen3 are under something called "max-link".  When doing initital setup, I wasn't sure what "max-link" is and the description didn't have any clues on PCIE. 

    But i managed to get nvOC to boot up by using a different USB (same brand, same type, ordered 2).  Im reluctant to reboot mobo at least for another 3-4 days!

  • S9k
    Newbie
    *
    Offline Offline

    Activity: 26
    Merit: 0


    View Profile
    July 04, 2017, 05:12:50 PM
     #935
    Quote from: fullzero on July 04, 2017, 03:54:47 PM
    Quote from: S9k on July 04, 2017, 01:09:02 PM
    Hi,

    Please help!
    I have got stuck on this problems  Huh
    My configuration:

    -ASUS PRIME Z270-P - 2 . I tried both, results are similar.
    -EVGA GeForce GTX 1080 GAMING ACX 3.0 - 2
    -MSI Geforce GTX 1080 Gaming X-  2
    -The Gigabyte power supply unit on 1200 watts


    Three video cards work perfectly in any any combinations,

    m1@m1-desktop:~$ nvidia-smi -L
    GPU 0: GeForce GTX 1080 (UUID: GPU-43453088-0fca-9442-106d-7594d157ebf2)
    GPU 1: GeForce GTX 1080 (UUID: GPU-d099b67e-f204-66fa-96dc-365a6b559a7e)
    GPU 2: GeForce GTX 1080 (UUID: GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac)
    m1@m1-desktop:~$

    m1@m1-desktop:~$ lspci |grep VGA
    01:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
    03:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
    05:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
    m1@m1-desktop:~$


    but if I add the fourth (in this case the ID GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac ), then the system falls. Here what I see in dmesg


    [   98.722227] nvidia-modeset: Allocated GPU:0 (GPU-43453088-0fca-9442-106d-7594d157ebf2) @ PCI:0000:01:00.0
    [   98.769072] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769117] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769144] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769169] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769193] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769217] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   98.769241] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.359255] nvidia-modeset: Allocated GPU:1 (GPU-5c9c8e29-a088-90a6-2a20-b2b2b971d1fb) @ PCI:0000:05:00.0
    [   99.398991] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399035] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399063] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399087] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399112] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399136] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buff er], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.399160] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
    [   99.984670] nvidia-modeset: Allocated GPU:2 (GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac) @ PCI:0000:06:00.0
    [  100.619118] nvidia-modeset: Allocated GPU:3 (GPU-d099b67e-f204-66fa-96dc-365a6b559a7e) @ PCI:0000:03:00.0
    [  100.743159] NVRM: GPU at PCI:0000:01:00: GPU-43453088-0fca-9442-106d-7594d157ebf2
    [  100.743162] NVRM: GPU Board Serial Number:
    [  100.743164] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 000001e0 00000801 00000004 00000005
    [  100.743649] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000004 00000005 00000004
    [  102.432593] r8169 0000:07:00.0 enp7s0: link up
    [  102.432600] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready
    [  103.743306] nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
    [  103.773941] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
    [  105.501795] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
    [  105.501798] Bluetooth: BNEP filters: protocol multicast
    [  105.501802] Bluetooth: BNEP socket layer initialized
    [  105.613048] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
    [  105.613106] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
    [  105.704570] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
    [  105.704972] BUG: unable to handle kernel paging request at ffff88167153d830
    [  105.704974] IP: [<ffffffffc0262880>] _nv008171rm+0x620/0x780 [nvidia]
    [  105.705052] PGD 220c067 PUD 0
    [  105.705053] Oops: 0000 [#1] SMP

    Three days I try to solve a problem.
    I changed versions of BIOS (0325,0608,0610) and risers, control 4G is included, has updated NVIDIA drivers to 381.22 - nothing helps.
    Maybe somebody will have ideas?

    My guess is your mobo is trying to is using SLI.  Are you using an M2 ssd?

    There should be some setting in the bios related to SLI; disable it what slots are you using and are you using risers, if so on which GPUs?

    If you are using risers; how are they powered?

    Hi,
    no, I don't use M2 SSD.
    I use risers of the version 006s with the molex socket.

    I managed to solve a problem. I modified etc/default/grub



    m1@m1-desktop:/etc/default$ more grub
    # If you change this file, run 'update-grub' afterwards to update
    #boot/grub/grub.cfg.
    # For full documentation of the options in this file, see:
    #   info -f grub -n 'Simple configuration'

    GRUB_DEFAULT=0
    #GRUB_HIDDEN_TIMEOUT=0
    GRUB_HIDDEN_TIMEOUT_QUIET=true
    GRUB_TIMEOUT=10
    GRUB_DISTRIBUTOR=`lsb_release -i -s 2>dev/null || echo Debian`
    GRUB_CMDLINE_LINUX_DEFAULT="vga=0 rdblacklist=nouveau nouveau.modeset=0"
    GRUB_CMDLINE_LINUX=""

    sudo update-grub

    also I have created the file  disable-nouveau.conf which contains two lines

    m1@m1-desktop:/etc/modprobe.d$ moreetc/modprobe.d/disable-nouveau.conf
    blacklist nouveau
    options nouveau modeset=0

    sudo reboot

  • salfter
    Hero Member
    *****
    Offline Offline

    Activity: 651
    Merit: 501


    My PGP Key: 92C7689C


    View Profile WWW
    July 04, 2017, 05:16:03 PM
     #936
    Quote from: lbrasi on July 04, 2017, 03:53:55 PM
    Quote from: salfter on July 04, 2017, 07:34:35 AM
    Quote from: fullzero on July 03, 2017, 07:02:03 PM
    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.

    I've committed an update that, if it pans out, rolls everything into one Python script...no auxiliary shell scripts.  I'm testing it right now to verify that it behaves the same as the previous version.  I suspect I'll know in the morning.

    Edit: Just did some accelerated testing by manually switching to a less-profitable coin first...the script killed the miner and fired up the appropriate miner.  I think the most recent update is ready for wider testing:

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


    For some odd reason since you consolidated all the code to the switch.py, now the only miner that runs is equihash.

    Mine's been running daggerhashimoto almost exclusively since the latest release.  Looking at current-profit, we have:

    Code:
    neoscrypt: 0.00122266 BTC/day (3.14 USD/day)
    lyra2rev2: 0.00044478 BTC/day (1.14 USD/day)
    daggerhashimoto: 0.00221102 BTC/day (5.67 USD/day)
    lbry: 0.00039243 BTC/day (1.01 USD/day)
    equihash: 0.00163831 BTC/day (4.20 USD/day)
    pascal: -0.00003248 BTC/day (-0.08 USD/day)

    I now have it logging the data (instead of overwriting it), and I have the current unpaid balances at NiceHash.  I'll let it keep running and see what happens.
    Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR | My Bitcoin Note Generator | Pool Auto-Switchers: zpool MiningPoolHub NiceHash
    Bitgem Resources: Pool Explorer Paper Wallet

  • lbrasi
    Newbie
    *
    Offline Offline

    Activity: 26
    Merit: 0


    View Profile
    July 04, 2017, 05:23:52 PM
     #937
    Quote from: salfter on July 04, 2017, 05:16:03 PM
    Quote from: lbrasi on July 04, 2017, 03:53:55 PM
    Quote from: salfter on July 04, 2017, 07:34:35 AM
    Quote from: fullzero on July 03, 2017, 07:02:03 PM
    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.

    I've committed an update that, if it pans out, rolls everything into one Python script...no auxiliary shell scripts.  I'm testing it right now to verify that it behaves the same as the previous version.  I suspect I'll know in the morning.

    Edit: Just did some accelerated testing by manually switching to a less-profitable coin first...the script killed the miner and fired up the appropriate miner.  I think the most recent update is ready for wider testing:

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


    For some odd reason since you consolidated all the code to the switch.py, now the only miner that runs is equihash.

    Mine's been running daggerhashimoto almost exclusively since the latest release.  Looking at current-profit, we have:

    Code:
    neoscrypt: 0.00122266 BTC/day (3.14 USD/day)
    lyra2rev2: 0.00044478 BTC/day (1.14 USD/day)
    daggerhashimoto: 0.00221102 BTC/day (5.67 USD/day)
    lbry: 0.00039243 BTC/day (1.01 USD/day)
    equihash: 0.00163831 BTC/day (4.20 USD/day)
    pascal: -0.00003248 BTC/day (-0.08 USD/day)

    I now have it logging the data (instead of overwriting it), and I have the current unpaid balances at NiceHash.  I'll let it keep running and see what happens.

    I am noticing if something other than equihash is more profitable in "current-profit" it does kill the equihash mining processes but fails to start anything else.

  • salfter
    Hero Member
    *****
    Offline Offline

    Activity: 651
    Merit: 501


    My PGP Key: 92C7689C


    View Profile WWW
    July 04, 2017, 06:29:41 PM
     #938
    Quote from: lbrasi on July 04, 2017, 05:23:52 PM
    Quote from: salfter on July 04, 2017, 05:16:03 PM
    Quote from: lbrasi on July 04, 2017, 03:53:55 PM
    For some odd reason since you consolidated all the code to the switch.py, now the only miner that runs is equihash.

    Mine's been running daggerhashimoto almost exclusively since the latest release.  Looking at current-profit, we have:

    I am noticing if something other than equihash is more profitable in "current-profit" it does kill the equihash mining processes but fails to start anything else.

    I manually switched to equihash, let it get up and running, and then fired up the script.  It killed the equihash miner and restarted the daggerhashimoto miner.

    You are aware that the miner runs in a screen session, right?  When the script switches from one algo to another, the screen session associated with the first miner ends and a new one is started with the second miner.  screen -dr miner will bring up the currently-running miner.
    Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR | My Bitcoin Note Generator | Pool Auto-Switchers: zpool MiningPoolHub NiceHash
    Bitgem Resources: Pool Explorer Paper Wallet

  • lbrasi
    Newbie
    *
    Offline Offline

    Activity: 26
    Merit: 0


    View Profile
    July 04, 2017, 06:40:51 PM
     #939
    Quote from: salfter on July 04, 2017, 06:29:41 PM
    Quote from: lbrasi on July 04, 2017, 05:23:52 PM
    Quote from: salfter on July 04, 2017, 05:16:03 PM
    Quote from: lbrasi on July 04, 2017, 03:53:55 PM
    For some odd reason since you consolidated all the code to the switch.py, now the only miner that runs is equihash.

    Mine's been running daggerhashimoto almost exclusively since the latest release.  Looking at current-profit, we have:

    I am noticing if something other than equihash is more profitable in "current-profit" it does kill the equihash mining processes but fails to start anything else.

    I manually switched to equihash, let it get up and running, and then fired up the script.  It killed the equihash miner and restarted the daggerhashimoto miner.

    You are aware that the miner runs in a screen session, right?  When the script switches from one algo to another, the screen session associated with the first miner ends and a new one is started with the second miner.  screen -dr miner will bring up the currently-running miner.

    I was able to resolve the issue by removing all the old mine_ALGO.sh files from themedia/m1/1263-A96E directory.  I assumed these would not interfere with the new switch.py script.

  • Nexillus
    Full Member
    ***
    Offline Offline

    Activity: 169
    Merit: 100


    View Profile
    July 04, 2017, 07:41:43 PM
     #940
    Putting up another rig here soon. Going to test out the mining Algo switching that was just put out a few pages back.

    Anyone have suggested settings for 1060s? Saw some on the first page but wanted to see if anyone else has some.
    Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 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 ... 352 »
      Print  
Page 46
Viewing Page: 47

IRLBTC™ © 2025 IRLBTC.com