|
fullzero (OP)
|
 |
July 01, 2017, 04:46:29 PM |
|
Hello every one. Complete noob here, noob to this forum, noob to mining, and complete idiot noob when it comes to linux. I just got bit by the "you should disable your internal graphics adapter in the BIOS and plug your monitor into the GPU on the 16x slot, so that your xorg.conf file does not get screwed up" bug in this operating system. Had to get to post #199 on this thread before I figured it out. Fullzero...you friggin rock for this OS, period! but you really...really...really...really should have put that information on the OP, it would have saved me hours (and hours) of trying different things to get the overclocks going. I did not just want to jump to the end to cry "help me! wah!". Anyways here is what I'm using, mobo is BIOSTAR TB250-BTC. 5 Gigabyte gtx 1060 6GB GPUs (waiting for the 6th card). 1000W PSU, low end Celeron cpu, 4GB RAM. I plan to use the M.2 adapter for the 7th GPU later, we'll see how that goes. I post this just in case another noob with similar hardware starts having the problem that they cannot overclock their GPUs and they are also getting fan setting errors during boot.  Let me know if I should post specific model numbers for the hardware. getting 1600 Sols, cc is at 200, mc is at 900, power limit is at 110, temps are in the low 60s. Currently testing for stability Updated OP; I had noted I should do this; but kept forgetting to actually do 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)
|
|
July 01, 2017, 04:52:26 PM |
|
I wanted to give some feedback, after a lot of research and feedback from Fullzero I would recommend to anyone that it issuing a 4-6 GPU system to use 8GB of RAM minimum instead of 4GB. I have been running my system now for 5 days and have not had any "random freezes/crashes" even with pushing some OCs in testing the new ver 0017. I think this is something we overlook.
What makes you think that there's a need for additional RAM? Top is showing that I'm not using more than about 1.2GB with four cards. I'll test this weekend on my 6 GPU system, but doubt it would use more than 2GB I thought the same thing until I really looked into it fullzero had suggested it had to do with the possibility with the DAG and virtual memory for Linux and or Windows. Before I had random freezes, kept the same settings, added the RAM and no more issues. Depending on the Algo ram will matter more or less. When mining ZEC 4gb should be good. When mining Ethash, especially Ethash + another algo when dualmining; you will have better stability with more ram. In general; more ram less problems. |
|
|
|
|
|
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
|
|
|
newmz
Sr. Member
 Offline
Activity: 372
Merit: 250
The road of excess leads to the palace of wisdom
|
|
July 01, 2017, 05:01:44 PM |
|
Finally with nvOC0017 I am working and stable!.
Eth mining 2 1070s and 3 1060s.
global core OC of 50 and mem OC 1300,
Using genoil I get 130+mh/s
Thanks fullzero.
Due o price pressure I am dual mining ETH and pascal on nicehash
|
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
|
|
|
|
fullzero (OP)
|
|
July 01, 2017, 05:02:34 PM |
|
Phil, nice rig and walkthru. I made a link to it on the OP. In general, I would like more members to make guides / walkthrus / videos explaining - demonstrating how to do X. So long as they don't contain incorrect information I will add them to the OP.  In general; the shorter and more specific; the better. Also I would like to start a list of member rig hardware / configurations to be used as a reference / guide for new members. Optimally I would like someone else to oversee this and I will link it to the OP. |
|
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
|
fullzero (OP)
|
|
July 01, 2017, 05:09:10 PM |
|
Does anyone have any idea how i can check if my cards are Samsung or Micron memory in ubuntu? i've looked but i cant find anything that will tell me this info.
this cmd will give you detailed information; but its not as helpful as some of the windows tools: lspci -vnn | grep VGA -A 12 You should be able to use the memory info from this cmd to identify different manufacturers. I don't have this info; but I am reasonably sure that is how the windows applications which provide this work; and it is available somewhere on the internet. |
|
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
|
fullzero (OP)
|
|
July 01, 2017, 05:15:51 PM |
|
probably need to post your system config mobo/ram/gpus etc. There are specific builds for specific mobos/configs.. I recommend trying nvOC.  |
|
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
|
fullzero (OP)
|
|
July 01, 2017, 05:19:42 PM |
|
Genoil uses a different implementation of the CUDA cores; this is almost like mining a different algorithm. OC which works with Claymore is not expected to work with Genoil-NC. You will most likely need to use lower clocks to achieve stability when using Genoil; however it will likely still have a higher hashrate than Claymore.
Seems better, thank you! Can you check genoil + eth single + dwarfpool? I use this setup but got error mentioned before. ETH_WORKER="" ETH_ADDRESS="0x5095F783a926d*D8121.p*2/gy*@*t.hu" ETH_POOL="eth-eu.dwarfpool.com:8008" ETH_EXTENTION_ARGUMENTS="" # add any additional claymore arguments desired here error: [CUDA]:Using grid size 8192, block size 128 ℹ 08:01:59|ethminer Connecting to stratum server eth-eu.dwarfpool.com:8008 ℹ 08:01:59|stratum Connected to stratum server eth-eu.dwarfpool.com : 8008 ℹ 08:01:59|stratum Starting farm ℹ 08:01:59|stratum Subscribed to stratum server terminate called after throwing an instance of 'Json::LogicError' what(): Value is not convertible to bool. /media/m1/1263-A96E/oneBash: line 1551: 3990 Aborted $HCD -S $ETH_POOL -O $ETHADDR:x -U FAILURE; reinit in 5 Thank you! I am assuming you intentionally altered your eth address and that is not what you are actually using. I would use something as a worker, probably not an issue, but to eliminate it as a potential problem it is a good idea. I am not sure what syntax dwarfpool uses. There is a switch: which changes the syntax for address/worker to address.worker you may need to change it to yes for dwarfpool; not sure what syntax dwarfpool uses. |
|
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
|
fullzero (OP)
|
|
July 01, 2017, 05:20:31 PM |
|
Finally with nvOC0017 I am working and stable!.
Eth mining 2 1070s and 3 1060s.
global core OC of 50 and mem OC 1300,
Using genoil I get 130+mh/s
Thanks fullzero.
Due o price pressure I am dual mining ETH and pascal on nicehash
Glad you got it working well. |
|
|
|
|
|
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
|
|
|
|
xleejohnx
|
|
July 01, 2017, 05:27:15 PM |
|
probably need to post your system config mobo/ram/gpus etc. There are specific builds for specific mobos/configs.. I recommend trying nvOC. Lol that was smooth |
As I see a super coin as the super highway and alt coins as taxis and trucks needed to move transactions. ~philipma1957
|
|
|
philipma1957
Legendary
Offline
Activity: 4312
Merit: 8871
'The right to privacy matters'
|
|
July 01, 2017, 05:48:14 PM |
|
Phil, nice rig and walkthru. I made a link to it on the OP. In general, I would like more members to make guides / walkthrus / videos explaining - demonstrating how to do X. So long as they don't contain incorrect information I will add them to the OP. In general; the shorter and more specific; the better. Also I would like to start a list of member rig hardware / configurations to be used as a reference / guide for new members. Optimally I would like someone else to oversee this and I will link it to the OP. been busy moving shifting and arranging gear. I plan to build and illustrate 3 or 4 different rigs with your software. |
|
|
|
dj--alex
Member
Offline
Activity: 81
Merit: 10
|
|
July 01, 2017, 06:37:09 PM
Last edit: July 01, 2017, 08:44:25 PM by dj--alex |
|
Posted by: GaryH Insert Quote Quote from: dj--alex on Today at 12:35:09 PM Please help i already write here early not get answer Cannot overclock any GPU>0 Screenshot https://pp.userapi.com/c840225/v840225257/1033e/5v2hp7Fs-sI.jpgprobably need to post your system config mobo/ram/gpus etc. There are specific builds for specific mobos/configs.. ===================== ookay my xorg https://pastebin.com/rPDe8gLQAMD AM3+ Dual core 3200Mhz, 4Gb ram, 1 GTX 780, 1 GTX 1060, HDD 750Gb Linux Mint 18.1 x64 Kernel 4.10 Nvidia-381 Overclocked only one card. 500mhz mem 2 cannot be overclocked.. i thinking requires monitors on EVERY videocard?  Why? maybe emulator monitors? Ohhh im already post ALL OF THIS DATA some days early... and wait 2-3 days for answer ================== I want to test another coin on GTX 680. In my house i have ONLY 1 CARD - GTX 680 2Gb + Linux Mint. How i can do this to use with <2GB mem? GPU_FORCE_64BIT_PTR 0 GPU_MAX_HEAP_SIZE 100 GPU_USE_SYNC_OBJECTS 1 GPU_MAX_ALLOC_PERCENT 100 GPU_SINGLE_ALLOC_PERCENT 100 |
|
|
|
|
|
salfter
|
|
July 01, 2017, 08:40:36 PM |
|
All gfx cards are out of stock  have heard AMD and Nvidia coming up with specialized minings cards When can we expect it to hit stores? The local Fry's got a handful of nVidia cards back in stock this week...everything from 1050s to 1080Tis. You'll pay through the nose for them, of course: the 1070s were going for a bit over $500 pre-rebate (for EVGA 1070 FTWs, IIRC). I'm not sure if they're still there or if someone snapped them up. They didn't receive huge quantities...maybe 3 or 4 1070s and a few more 1080s and 1080Tis. Keep an eye out for deals on used cards. My first 1070 (a PNY that looks like a reference implementation) cost me $375 on eBay, shipped maybe three weeks ago. I spent last weekend out of town for an event. Before going, I checked OfferUp for my destination and found someone selling an MSI 1070 Gaming X for $340. I asked the seller if he could hold it until I got down there last Friday; he did. Drove down, swapped cash for the card, added it to the rig when I got back home. I've seen some deals pop up on Craigslist as well, but I can only act on so many of them at a time. |
|
|
|
painmaker
Member
Offline
Activity: 71
Merit: 10
|
|
July 01, 2017, 09:15:03 PM |
|
Hi there!
Been trying nvOC 0012 after OP pointed me to it in another thread and liked it but went back to my own installation for stability reasons and some other things i missed or didn't like. Still I'd like to say thanks for all the work devoted into nvOC and for sharing it with the community!
Now I got my hands on a nice 8xGPU supermicro 4028 case (X9 board inside) for a couple of days (already feelin' sad that I'll have to return this nice machine) and for the sake of simplicity thought I give nvOC another shot (v0017 this time).
After applying my settings to oneBash I fired up nvOC and found it mining smoothly albeit I didn't manage to get a desktop displayed on any of the graphics-ports (tried pretty much all display-port slots of all cards, especiall GPU #0 which was not easy to find out which one it is (inner left if viewing from the back)). the onboard vga-port shows the ubuntu typical purple background but i cannot see anything else on it.
Logging in via ssh works though so I went on checking temps and stuff and found that the fan-speeds were like I configured them for GPU #0 to GPU #3 but running on default for GPU #4 to GPU #7!
Miners were running on all GPU's present, did not find out how to check OC-settings but I suspect only the cards with set fan-speeds will have their OC-settings applied.
Digging a bit deeper into xorg.conf and the output of nvidia-smi I noticed the the graphic cards PCI-device-addresses on this machine do not start at 01 and go up sequentially but are 04, 05, 08, 09 and 84, 85, 88, 89. The cards in the lower addresses had their fanspeed applied correctly, the 8X ones not.
Inspecting nvOC's xorg.conf I found the there are entries for graphic cards on addresses 01 til 14 which might nicely explain why in my case only the cards within this range get their settings applied. So I went on and changed some other device-entries numbers to 84,85, 88, 89 hoping this would do the trick.
Sadly it didn't, behaviour was just like before.
My guess is that these numbers are hardcoded in some other config somewhere in the system and I might need to alter this as well. Any ideas where else I might need to look?
Thanks in advance,
pain
|
|
|
|
|
madbuda
Newbie
Offline
Activity: 44
Merit: 0
|
|
July 01, 2017, 11:05:37 PM |
|
Fullzero thanks for detailed instruction of my idea and including it into nvOS v0017
here are some operations for image space releasing:
sudo apt update
sudo apt upgrade
===skip===
it allows to descrease size image on 2++Gb
PS:I would like to add monitoring system into your project.
Now, I'm choosing from zabbix, munin and cacti. What would you advice?
@_Parallax_ sudo apt-get purge $(dpkg -l linux-{image,headers}-"[0-9]*" | awk '/ii/{print $2}' | grep -ve "$(uname -r | sed -r 's/-[a-z]+//')")will do all of that in a single line or install byobu then you can run `sudo purge-old-kernels` I use zabbix with grafana. Gives me telegram alerts and pretty graphs *edit, forgot the closing ) Excellent example, thanks! Could you show how did you install setting of zabbix and grafana? Well, I tried but mod's keep deleting my post  I'll write something up and post it to github and just link it here |
|
|
|
|
philipma1957
Legendary
Offline
Activity: 4312
Merit: 8871
'The right to privacy matters'
|
|
July 01, 2017, 11:25:56 PM |
|
Fullzero thanks for detailed instruction of my idea and including it into nvOS v0017
here are some operations for image space releasing:
sudo apt update
sudo apt upgrade
===skip===
it allows to descrease size image on 2++Gb
PS:I would like to add monitoring system into your project.
Now, I'm choosing from zabbix, munin and cacti. What would you advice?
@_Parallax_ sudo apt-get purge $(dpkg -l linux-{image,headers}-"[0-9]*" | awk '/ii/{print $2}' | grep -ve "$(uname -r | sed -r 's/-[a-z]+//')")will do all of that in a single line or install byobu then you can run `sudo purge-old-kernels` I use zabbix with grafana. Gives me telegram alerts and pretty graphs *edit, forgot the closing ) Excellent example, thanks! Could you show how did you install setting of zabbix and grafana? Well, I tried but mod's keep deleting my post I'll write something up and post it to github and just link it here send it to me in pm I will post it. |
|
|
|
smokinggun46
Newbie
Offline
Activity: 14
Merit: 0
|
|
July 02, 2017, 01:12:11 AM |
|
Using Biostar Racing Z270 GT6: set maxTOLUD, did not set security settings (no option in Z270). A few questions and problems:: 1) Plugging in a second GPU (via risers, 1st GPU also via risers) causes the motherboard to black screen on boot. Here's a teamviewer screenshot of how it looks like (display stopped working when a 2nd GPU came in, had to remote in with teamviewer). http://imgur.com/a/H5flW2) The closest PCIE to the CPU is a 1x, then a 16x. Which slot is considered my "primary GPU"? Is it the 16x? |
|
|
|
|
|
car1999
|
|
July 02, 2017, 02:16:04 AM |
|
MSI Z170A GAMING M5 is in the fully supported list, this mobo has 7x pcie and 2x M.2 slots, so it might support 9 cards. I tried and found that only the 1st M.2 slot(near CPU) worked with M.2 to pcie adapter, so I can run only 8 cards. Any body tried 9 cards?
|
|
|
|
|
|
fullzero (OP)
|
|
July 02, 2017, 02:33:49 AM |
|
Posted by: GaryH Insert Quote Quote from: dj--alex on Today at 12:35:09 PM Please help i already write here early not get answer Cannot overclock any GPU>0 Screenshot https://pp.userapi.com/c840225/v840225257/1033e/5v2hp7Fs-sI.jpgprobably need to post your system config mobo/ram/gpus etc. There are specific builds for specific mobos/configs.. ===================== ookay my xorg https://pastebin.com/rPDe8gLQAMD AM3+ Dual core 3200Mhz, 4Gb ram, 1 GTX 780, 1 GTX 1060, HDD 750Gb Linux Mint 18.1 x64 Kernel 4.10 Nvidia-381 Overclocked only one card. 500mhz mem 2 cannot be overclocked.. i thinking requires monitors on EVERY videocard? Why? maybe emulator monitors? Ohhh im already post ALL OF THIS DATA some days early... and wait 2-3 days for answer ================== I want to test another coin on GTX 680. In my house i have ONLY 1 CARD - GTX 680 2Gb + Linux Mint. How i can do this to use with <2GB mem? GPU_FORCE_64BIT_PTR 0 GPU_MAX_HEAP_SIZE 100 GPU_USE_SYNC_OBJECTS 1 GPU_MAX_ALLOC_PERCENT 100 GPU_SINGLE_ALLOC_PERCENT 100 Maxwell and older Nvidia cards use different commands to OC. I don't have any so I haven't tested them. If you ask on the ccminer thread there are a lot of knowledgeable members who most likely have maxwell rigs and can help you. |
|
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
|
fullzero (OP)
|
|
July 02, 2017, 02:44:12 AM |
|
Hi there!
Been trying nvOC 0012 after OP pointed me to it in another thread and liked it but went back to my own installation for stability reasons and some other things i missed or didn't like. Still I'd like to say thanks for all the work devoted into nvOC and for sharing it with the community!
Now I got my hands on a nice 8xGPU supermicro 4028 case (X9 board inside) for a couple of days (already feelin' sad that I'll have to return this nice machine) and for the sake of simplicity thought I give nvOC another shot (v0017 this time).
After applying my settings to oneBash I fired up nvOC and found it mining smoothly albeit I didn't manage to get a desktop displayed on any of the graphics-ports (tried pretty much all display-port slots of all cards, especiall GPU #0 which was not easy to find out which one it is (inner left if viewing from the back)). the onboard vga-port shows the ubuntu typical purple background but i cannot see anything else on it.
Logging in via ssh works though so I went on checking temps and stuff and found that the fan-speeds were like I configured them for GPU #0 to GPU #3 but running on default for GPU #4 to GPU #7!
Miners were running on all GPU's present, did not find out how to check OC-settings but I suspect only the cards with set fan-speeds will have their OC-settings applied.
Digging a bit deeper into xorg.conf and the output of nvidia-smi I noticed the the graphic cards PCI-device-addresses on this machine do not start at 01 and go up sequentially but are 04, 05, 08, 09 and 84, 85, 88, 89. The cards in the lower addresses had their fanspeed applied correctly, the 8X ones not.
Inspecting nvOC's xorg.conf I found the there are entries for graphic cards on addresses 01 til 14 which might nicely explain why in my case only the cards within this range get their settings applied. So I went on and changed some other device-entries numbers to 84,85, 88, 89 hoping this would do the trick.
Sadly it didn't, behaviour was just like before.
My guess is that these numbers are hardcoded in some other config somewhere in the system and I might need to alter this as well. Any ideas where else I might need to look?
Thanks in advance,
pain
I don't have one of these server mobos; but I believe they have 2x or maybe even 3x distinct pcie buses. unfortunately when using 7+ GPUs it is not enough to change the xorg.conf. In your case I am not sure how the multiple buses interact or if they are completely distinct, most likely it will be a pia to get them all OCed. I was just about to give in and order one of these beast mobos (I want a deathstar class rig) when I saw a thread talking about the new biostar 12x pcie mobo that will be shipping soon. I will get one and see how they do. If you do a plain: it will most likely point you to the different pcie buses and you can delve further from there. |
|
|
|
|
|
mnh_license@proton.me https://github.com/hartmanm How difficulty adjustment works: Every 2016 blocks, the Network adjusts the current difficulty to estimated difficulty in an attempt to keep the block generation time at 10 minutes or 600 seconds. Thus the Network re-targets the difficulty at a total difficulty time of: 2016 blocks * 10 minutes per block = 20160 minutes / 60 minutes = 336 hours / 24 hours = 14 days. When the Network hashrate is increasing; a difficulty ( 2016 blocks ) should take less than 14 days. How much less can be estimated by comparing the % Network hashrate growth + what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ) against what the Network hashrate was at the beginning of the difficulty ( 2016 blocks ). This is only an estimate because you cannot account for "luck"; but you can calculate reasonably well using explicitly delimited stochastic ranges. The easy way to think about this is to look at this graph and see how close to 0 the current data points are on its y axis. If the blue line is above 0 the difficulty ( 2016 ) blocks should take less than 14 days; if it is below it should take more. http://bitcoin.sipa.be/growth-10k.png
|
|
|
|
fullzero (OP)
|
|
July 02, 2017, 02:57:18 AM |
|
Using Biostar Racing Z270 GT6: set maxTOLUD, did not set security settings (no option in Z270). A few questions and problems:: 1) Plugging in a second GPU (via risers, 1st GPU also via risers) causes the motherboard to black screen on boot. Here's a teamviewer screenshot of how it looks like (display stopped working when a 2nd GPU came in, had to remote in with teamviewer). http://imgur.com/a/H5flW2) The closest PCIE to the CPU is a 1x, then a 16x. Which slot is considered my "primary GPU"? Is it the 16x? I haven't tested this mobo, so I don't know good bios settings. for 2x GPUs you will most likely not need to set maxTOLUD; a general side effect of this or the similar enable above 4g encoding is that the screen will be all black during boot. the closest 16x is the primary |
|
|
|
|
|
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
|
|
|
|
