philipma1957
Legendary
 Offline
Activity: 4312
Merit: 8871
'The right to privacy matters'
|
 |
June 24, 2017, 12:38:35 PM |
|
Okay I like the software I have ordered some 32gb sticks
I am running version 15 on some 16gb sticks.
I feel like a moron as I simply can't burn a good copy of 16.
I am going to put up a ton of screen shots showing my issues on burning a copy of 16. and maybe somebody will tell me what is wrong with me
|
|
|
|
philipma1957
Legendary
Offline
Activity: 4312
Merit: 8871
'The right to privacy matters'
|
|
June 24, 2017, 01:15:34 PM |
|
Okay I like the software I have ordered some 32gb sticks
I am running version 15 on some 16gb sticks.
I feel like a moron as I simply can't burn a good copy of 16.
I am going to put up a ton of screen shots showing my issues on burning a copy of 16. and maybe somebody will tell me what is wrong with me
so here are unzipped downloads what do I do to fix them so they will copy onto my usb stick extract does not work so I most likely need to do some other thing do i use winzip or some other unzip software?  |
|
|
|
|
Maxximus007
|
|
June 24, 2017, 02:48:07 PM |
|
Okay I like the software I have ordered some 32gb sticks
I am running version 15 on some 16gb sticks.
I feel like a moron as I simply can't burn a good copy of 16.
I am going to put up a ton of screen shots showing my issues on burning a copy of 16. and maybe somebody will tell me what is wrong with me
so here are unzipped downloads what do I do to fix them so they will copy onto my usb stick extract does not work so I most likely need to do some other thing do i use winzip or some other unzip software? Hi, that is the bash file only (in Windows speak: the batch file). What you need is the image, to be found on the OP. His is rather large, around 6,44 Gb. This ZIP file can be unpacked with the standard Windows unzip tool. After that you will have a file named nvOC_v0016.img, around 15.6 Gb large. This is the 'image' of the bootable operating system nvOC. You can then download the image burning app to be found on: etcher.io Install the app on your computer, after starting the app you select the nvOC_v0016.img and the USB flash drive, and click on Flash! This will take some time. When it's finished, you can find a file called oneBash on the flash drive. Edit this file with your pool, address etc. Eject the flash drive, put it in your rig, power it up, and after a couple of minutes its mining away! |
|
|
|
|
philipma1957
Legendary
Offline
Activity: 4312
Merit: 8871
'The right to privacy matters'
|
|
June 24, 2017, 02:57:39 PM
Last edit: June 24, 2017, 04:27:53 PM by philipma1957 |
|
Duh thanks  got two 1080 ti's working nicely 353 watts  1271 sols  |
|
|
|
|
Maxximus007
|
|
June 24, 2017, 04:23:07 PM |
|
Duh thanks got two 1080 ti's working nicely Great! Please let us know your hashing rate and OC values (and brand). |
|
|
|
|
|
stef_stef
|
|
June 24, 2017, 04:56:25 PM |
|
Do you think it is possible to upload on MEGA next time?
In my experience it is way faster than google drive in terms of download speeds
|
|
|
|
|
philipma1957
Legendary
Offline
Activity: 4312
Merit: 8871
'The right to privacy matters'
|
|
June 24, 2017, 05:02:45 PM |
|
Duh thanks got two 1080 ti's working nicely Great! Please let us know your hashing rate and OC values (and brand). both cards power = 150 watts core = 222 ram = 10 >>> can I set -100 or -200 or - 300 ? hashrate 2 1080 ti's about 1270 they are: msi aero 1080ti asus 1080ti mobo gigabyte b250m cpu i5 7500t a photo  |
|
|
|
|
|
philipma1957
Legendary
Offline
Activity: 4312
Merit: 8871
'The right to privacy matters'
|
|
June 24, 2017, 05:42:33 PM |
|
Psu = EVGA 750 p2
and the asus is the one you linked to.
I think I am switching all rigs over to nvoc
I have a lot of biostar rigs
z170's
I want to use last slot but only 4 cards
all 1070's I will test later.
I don't think I need tould 3.5 setting with 4 cards.
now that I can load the image easy I will play with these cards and rigs.
|
|
|
|
|
fullzero (OP)
|
|
June 24, 2017, 06:28:23 PM |
|
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? So far it looks like 3,3 is better by the slightest margin (but this could easily be normal variance). Both are very stable. I would go with the 1080tis in case you want to mine an Ethash coin later on, plus they are more efficient. |
|
|
|
|
|
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)
|
|
June 24, 2017, 06:32:37 PM |
|
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.. Dual mining is always less stable, especially with OC and powerlimit. What ram, PSU, and CPU are you using? |
|
|
|
|
|
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)
|
|
June 24, 2017, 06:34:19 PM |
|
Do you think it is possible to upload on MEGA next time?
In my experience it is way faster than google drive in terms of download speeds
Yes I will do that next time; I think you asked before and I forgot: my bad. I will add it to the OP list so I don't forget this time. |
|
|
|
|
|
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)
|
|
June 24, 2017, 06:40:07 PM |
|
Duh thanks got two 1080 ti's working nicely Great! Please let us know your hashing rate and OC values (and brand). both cards power = 150 watts core = 222 ram = 10 >>> can I set -100 or -200 or - 300 ? hashrate 2 1080 ti's about 1270 they are: msi aero 1080ti asus 1080ti mobo gigabyte b250m cpu i5 7500t a photo Phil, you can use negative core and memory offsets; but how far you can go depends on the specific card. Most will go to -100mc, some will go to -200mc; but I haven't seen a card that can go below -200 mc. |
|
|
|
|
|
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)
|
|
June 24, 2017, 06:50:02 PM |
|
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. I would avoid using the onboard graphics as it will almost always wipe the xorg.conf and most likely set you on an infinite loop. If you really want to use the onboard you can remove the xorg check: in oneBash: the first implementation line: under the settings division: ######################################################################### change this to: and save to prevent the reboot loop: but you may end up using a blank xorg this way and not be able to OC. Much better boot-up speed, this time can use USB3 port fully compatible with build? You should be able to use the usb3 ports without issue; on almost all mobos. |
|
|
|
|
|
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)
|
|
June 24, 2017, 07:00:01 PM |
|
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: 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: ######################################################################### change this to: 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? 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 ? This is how the last part looks like here (same MB, 6 1070 Gigabyte): +-----------------------------------------------------------------------------+
| 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 |
+-----------------------------------------------------------------------------+ Also getting a ton of " An internal driver error occurred." and a handful of argument errors.
I would try removing your usb, restoring your mobo to factory default settings; then changing only: Above 4G to: enabled save and reboot attach usb key and ctrl + alt + del and see if it works |
|
|
|
|
|
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
|
|
June 24, 2017, 07:46:55 PM |
|
I've tried three different versions of nvOC now and I still just CAN'T GET THE OVERCLOCKS TO WORK!
I've tried individual and whole system and I even see the overclocks apply when onebash starts - but they aren't sticking.
I'm mining eth and in Windows with Afterburner I set all 5 cards (2 1070s and 3 1060s) to core +75 and mem +800 and I get 132mh/s
Using nvOC and trying to set the same overclocks, I get 120mh/s.
It's really frustrating. I just don't understand. Does Claymore set everything to factory clocks when it starts or something?
Anyone else mining ETH and managing to ue overclocking?
Also linux OC offsets are scaled differently than windows; you will need to use higher offsets to get the same results in linux. I am mining ETH and am overclocked (~30.9 MH/sec on 1070 Founders Ed cards and ~29.5 MH/sec on a frankenstein rig with 3 different kinds of 1070 cards). I recommend using v0016 if you aren't already and trying the OC settings: __CORE_OVERCLOCK=-100 MEMORY_OVERCLOCK=1000 if this is stable I would try: __CORE_OVERCLOCK=-100 MEMORY_OVERCLOCK=1100 then: __CORE_OVERCLOCK=-100 MEMORY_OVERCLOCK=1200 ... until you get a soft crash in Claymore, then I would backtrack to the previous setting OK... I have a very weird (at least to me) situation. I'm using v0016 and I followed your suggestion of trying memory overclocks of 1000, 1100 & 1200. I do see an improvement. previously I saw a hashrate of 120mh/s compared to Win8.1 / MSI Afterburner (core -200 memory +800) getting me around 132mh/s. Now when I tried your suggestion nvOC is giving me around 127mh/s but the weird thing is - I get this hashrate regardless of whether it's based on memory 1000, or 1100 or 1200. The same improvement. This suggests that your memory overclock is just somehow selecting some arbitrary amount whether I tell it 1000, 1100 or 1200. Not some precise amount which increases as I raise the number. I know the actual memory figure isn't raising it by 800 or 1000 or 1100 or whatever, because the (actual) memory is running in the 5000s. It would be nice to be able to set a precise number and see a precise gain. It would be especially nice to be able to at least equal (or even improve) what I can achieve in Windows, which seems to be about 132mh/s - not 127mh/s which is what nvOC is reporting. I know it's only 5mh/s but don't we all want the highest hash-rate we can achieve? I guess I also must consider power consumption. If nvOV is delivering 127mh/s but at much lower power than Windows at 132mh/s of course I will use it. I just wish it was clear to me what these overclocking setting numbers actuually mean. |
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
|
|
|
jmooney5115
Newbie
Offline
Activity: 38
Merit: 0
|
|
June 24, 2017, 08:23:41 PM |
|
I'll have to try out v0016 when I have more down time. I just swapped mobo so I can mine with 6x GPU. This mobo works with v0015 and I suspect it will work with v0016: GIGABYTE GA-Z270XP-SLI for anyone interested. |
|
|
|
|
|
Nexillus
|
|
June 24, 2017, 09:54:01 PM |
|
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.. Dual mining is always less stable, especially with OC and powerlimit. What ram, PSU, and CPU are you using? Humm something to consider, when I use to do this dual mining wasn't even an option. Here is the info you requested: PSU: Seasonic 1050 CPU: Intel Celeron g3930 RAM: Crucial 4GB. |
|
|
|
|
WarwickNZ
Newbie
Offline
Activity: 21
Merit: 0
|
|
June 24, 2017, 10:18:56 PM |
|
Hey,
Just wondering how many CPU threads you guys are using to mine monero without causing impact to GPU mining operations? Currently have mine set at 2 but was thinking it can probably do 3 using G4560.
Thanks
|
|
|
|
|
philipma1957
Legendary
Offline
Activity: 4312
Merit: 8871
'The right to privacy matters'
|
|
June 25, 2017, 12:06:47 AM |
|
okay I am running 3 card rig I got -pl 105 for all 3 cards to work. I am pulling about 375 at the k-watt meter for 1275 sols. I had to set each gpu individually to -pl 105 I can't run xmr cpu but not much coin no worries. my bash had 11 gpus i deleted 6-10 kept 0,1,2,3,4,5 all seems okay https://www.nicehash.com/index.jsp?p=miners&addr=1JdC6Xg3ajT3rge3FgPNSYYFpmf53Vbtjecan be viewed at link above. last one on the equihash list nvOCphiltest1 Phil, you can recomplile cpuminer-opt by opening the guake terminal and entering: and press enter then type: and press enter this will recompile for your specific cpu; after it is done, if you change plusCPU to YES in oneBash and enter your XMR info you will mine a little XMR on the side. When using a 1080ti I recommend only using 1 thread to ensure the GPU mining is not reduced at all. okay I did this and I am mining some xmr and of course the 2 1080ti's do zec  |
|
|
|
|
