|
lodcrappo (OP)
|
 |
January 22, 2012, 08:49:09 AM |
|
Thanks, I managed to fix this. Turns out X was outputting through a different GPU. Now it's mining, but 3 of my cards are only about 50% load... Aggression is set at 14, any ideas?
Sounds like you might not have updated either. See previous post. PS sometimes X chooses a different GPU or screen to put it's output on than Linux chooses to use for the console. don't ask me why. best to just not connect a screen at all, use ssh. |
|
|
|
|
|
|
|
|
|
|
|
|
|
The Bitcoin software, network, and concept is called "Bitcoin" with a capitalized "B". Bitcoin currency units are called "bitcoins" with a lowercase "b" -- this is often abbreviated BTC.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
lodcrappo (OP)
|
|
January 22, 2012, 09:00:40 AM
Last edit: January 22, 2012, 09:11:31 AM by lodcrappo |
|
I've downloaded the most recent BAMT to try as an alternative to linuxcoin. Got it dd'd on an 8GB USB stick and worked the config file to match the same aticonfig settings I run with linuxcoin (latest-final). I started up gpumon and watched (nice console, BTW - only works with "sudo" for some reason). The cards were at full speed for roughly 2 minutes then they would effectively stop mining for a few seconds and then slowly restart every few minutes. I checked on the screen consoles and each card (5970-daul, 5850, 5870) and noticed that they were going idle and detaching. As the miners would re-attach, the number of invalids would climb to over 8% (within an hour). I am currently mining with btcguild only (so my pools file is just one line). I've checked my phoenix flags and they are identical to what I was running on linuxcoin. I'm back on linuxcoin for now, but would like to move to BAMT as I'm growing beyond one miner and would like to spend less time maintaining them. Anything obvious I'm missing?
pretty much everything in bamt only works as root. don't even bother with sudo, login as root from the start (or start a "root terminal", not regular one, from gui. but don't use the gui, it sucks. use ssh). <short rant that may not apply to you at all> yeah, yeah.. common belief is that it's "bad" to be root on a normal *nix system. BAMT is not a normal system. It is designed to be a single user (or preferably 0 user) environment. Many of the things you want to do on a mining rig always require root access anyway. Most (if not all) of the reasons you shouldn't be root do not apply, as this is not a general purpose system. So.. learn to live as root when in BAMT.</rant> Your connect and disconnect problem sounds like you have one of the below: #1 pool_timeout is set too low. If a share is not accepted within this time period (specified in seconds) then BAMT will kill phoenix and restart it with the next pool URL (or the same one if you have specified only one). #2 you've specified a max shares or a low max time value for this pool in the pools file. Specifying max shares will cause BAMT to always kill and move to next url after that # of shares are accepted. Specifying a low max time value is just like setting pool_timeout too low. see https://github.com/aaronwolfe/Big-A-Miner-Thing/wiki/Using-bamt |
|
|
|
|
|
lodcrappo (OP)
|
|
January 22, 2012, 09:09:00 AM
Last edit: January 22, 2012, 09:31:14 AM by lodcrappo |
|
Have just setup BAMT on a rig. Works great except for one thing.
Mining doesn't start up on a bootup. I have to type in /etc/init.d/mine restart after a boot.
Shouldn't mining start up automajically?
Yes, it should. what is showing in the mining screen sessions after a boot up, or do they even exist yet? There are some time delays in the init process that are there to let X get started and ready before the GPUs fire off. If your system just takes longer to get X running than the default delay, then the miners are starting too soon and will fail. To see if that is what is happening, try adjusting these to be longer: # at boot, how long to wait for X to start (seconds) start_mining_init_delay: 20 # delay in between starting individual GPUs (seconds) start_mining_miner_delay: 3 Maybe try 60 seconds on the start_mining_init_delay just to be sure, and if that fixes it then reduce until it breaks again. |
|
|
|
|
|
lodcrappo (OP)
|
|
January 22, 2012, 09:46:46 AM |
|
THE OCTOBAMT CHALLENGE
Spent some time trying to help LittleDuke get 8 GPUs working in bamt. Also reviewed this thread and a found everyone else who has tried 8 got the same results we did: It doesn't work.
7 GPUs = totally fine
8 GPUs = the ati driver crashes, machine locks up, game over
Pretty sure more than 8 is impossible on any linux box, but it would be nice to get that 8th slot working for people who cram 4 5970s into a box etc.
I don't have any machines anything like that, so testing things is quite difficult here. If you do have a rig that can support 8 GPUs, I hearby invite you to enter the first annual OCTOBAMT challenge!
The rules are simple: Using any tool or technique, get BAMT working with 8 GPUs. The solution must be something we can apply to the standard BAMT image without reducing the existing BAMT functionality, otherwise anything goes.
The first person to complete the challenge will be awarded a fantastic prize package which includes unspecified items of practically undefinable value. You will be as a god among men, celebrated and feared throughout the land. Don't let this amazing opportunity pass you by.
Hints:
My suspicion is that the drivers we use are just broken. Limited experiments with other versions have revealed that certain versions, such as 10.11 and 11.12 behave differently than our version (11.6 iirc). Other versions, 11.7-11.10 seem to lock up just the same as 11.6.
However, 10.11 and 11.12 seem to introduce their own problems, which may or may not be something that can be resolved.
|
|
|
|
|
|
bulanula
|
|
January 22, 2012, 11:39:52 AM |
|
What SDK does this use ? 2.1 or 2.4 ?
Thank you !
|
|
|
|
|
|
lodcrappo (OP)
|
|
January 22, 2012, 11:40:20 AM |
|
What SDK does this use ? 2.1 or 2.4 ?
Thank you !
2.4 |
|
|
|
|
|
|
|
bulanula
|
|
January 22, 2012, 02:39:21 PM |
|
Any idea about how I might replace that with 2.1 because 5870s + 2.1 = rocks while 5870s + 2.4 = meh. Thanks ! |
|
|
|
|
|
lodcrappo (OP)
|
|
January 22, 2012, 02:40:34 PM |
|
Any idea about how I might replace that with 2.1 because 5870s + 2.1 = rocks while 5870s + 2.4 = meh. Thanks ! Just install the version you prefer, same as you would do on any linux box. |
|
|
|
|
|
bulanula
|
|
January 22, 2012, 02:45:19 PM |
|
Just install the version you prefer, same as you would do on any linux box. So the two would not conflict like on Winblows, right ? |
|
|
|
|
|
lodcrappo (OP)
|
|
January 22, 2012, 02:47:24 PM |
|
Just install the version you prefer, same as you would do on any linux box. So the two would not conflict like on Winblows, right ? probably not, linux isn't as silly as windows in general. OTOH I've never tried it, so who knows. You could remove 2.4 if it causes some problem. Google around for how to install the sdk on debian, thats what you need to do. |
|
|
|
|
|
abracadabra
|
|
January 22, 2012, 06:36:30 PM |
|
Have just setup BAMT on a rig. Works great except for one thing.
Mining doesn't start up on a bootup. I have to type in /etc/init.d/mine restart after a boot.
Shouldn't mining start up automajically?
Yes, it should. what is showing in the mining screen sessions after a boot up, or do they even exist yet? Sorry.. linux newb. Where would I see or find those screen sessions? I have seen a message that states ""Starting mining processes...: mineNo protocol specified" But a restart starts the miners fine, so I believe my bamt.conf and pools are correct. There are some time delays in the init process that are there to let X get started and ready before the GPUs fire off. If your system just takes longer to get X running than the default delay, then the miners are starting too soon and will fail.
To see if that is what is happening, try adjusting these to be longer:
# at boot, how long to wait for X to start (seconds)
start_mining_init_delay: 20
# delay in between starting individual GPUs (seconds)
start_mining_miner_delay: 3
Maybe try 60 seconds on the start_mining_init_delay just to be sure, and if that fixes it then reduce until it breaks again.
I'll try to up the init_delay to 60 and post a result. Thanks! |
|
|
|
|
|
abracadabra
|
|
January 22, 2012, 06:41:12 PM |
|
lodcrappo,
upping the init delay to 60 did the trick!
Thanks!
|
|
|
|
|
|
BinaryMage
|
|
January 22, 2012, 09:20:57 PM |
|
Slight bump on my earlier question. 3 of my 5 cards (5870s) are mining at only about 50% load in BAMT. CPU usage shows 1 core maxed, the other unused. (C2D E8500) All GPUs have been tested and work @ 100% load with Ubuntu 11.04/Phoenix/phatk2. Seems to me like BAMT is only using one core of the CPU - how do I configure it to use both? (I looked on the wiki & searched the forums, both returned nothing)
did you apply all the fixes? Non-updated BAMT machines can have a bug where xscreensaver kicks in and steals your hash power. Sounds sort of like this is what you have going on. CPU use should be 0, or nearly 0, all the time. If it is maxed, Bad Things are happening. It's probably only maxing one core because only one process is going nuts. If you did update already, try running top. What does it say is using all your CPU time? I'm using BAMT 0.4b, is that what you meant by fixes? |
|
|
|
|
lodcrappo (OP)
|
|
January 22, 2012, 10:12:40 PM |
|
I'm using BAMT 0.4b, is that what you meant by fixes?
No. There are about a dozen bugfixes and new feature packages you are missing, including the bugfix that will almost certainly solve your problem. As root, run: /opt/bamt/fixer more details here = http://aaronwolfe.com/bamt/download.html |
|
|
|
|
|
BinaryMage
|
|
January 22, 2012, 10:30:44 PM |
|
I'm using BAMT 0.4b, is that what you meant by fixes?
No. There are about a dozen bugfixes and new feature packages you are missing, including the bugfix that will almost certainly solve your problem. As root, run: /opt/bamt/fixer more details here = http://aaronwolfe.com/bamt/download.htmlAh, I see. Thanks, will try. |
|
|
|
|
lodcrappo (OP)
|
|
January 24, 2012, 09:27:03 AM |
|
Is there a price that could be paid that would lead to BAMT being updated to work beautifully with P2Pool? EDIT: Whoops, it's late and I didn't read the most recent posts to the thread. Anyway, if this happens, you have another donation guaranteed from me. I would love to do it myself, but I don't have the necessary skill set.  Fix #20, containing a super charged version of Phoenix 1.7.4 is available now via the BAMT fixer. As root, /opt/bamt/fixer Several additional improvements are coming in the next few days... |
|
|
|
|
|
fitty
|
|
January 24, 2012, 08:49:33 PM |
|
Fix #20, containing a super charged version of Phoenix 1.7.4 is available now via the BAMT fixer.
Donation sent. Donation sent too. =) Has anyone ever tried to setup a lan boot server to host the images for each rig? The cheap ass flash drives I bought are dying left right and center. I'd also like to remotely reset the image for a rig if it was running into issues. I have a remote reboot setup already when it locks up, but if it's loading the same image that doesn't always fix the problem. I'd like to have one machine with a HD (maybe raid 1) to host the 10 rig images and have everything boot from LAN. I've found the fastest fix is just swap in a new flash drive and that fixes 99% of the problems I've run into. I'm not sure if it's the flash drive dying or something being corrupted, it's not worth figuring out since it takes 15 seconds to swap the flash drive. But if it's a remote farm that is a little more trouble. =) Some rigs I switched to laptop HDs I had lying around and that works fine. I'm just wondering if anyone has gone a step further to help manage remote farms. If no one else has done it does anyone know how hard this would be to setup? If it's not horribly difficult I'll start a bounty. =) |
|
|
|
|
fitty
|
|
January 24, 2012, 09:45:29 PM |
|
What SDK does this use ? 2.1 or 2.4 ?
Thank you !
I sorta remember this being the case but it's been awhile. Can you tell me the hash rates between the two? Does it effect the 5830s also? Also if you successfully swap back to 2.1 let us know how it works out. =) |
|
|
|
|
lodcrappo (OP)
|
|
January 25, 2012, 06:18:25 AM |
|
Fix #20, containing a super charged version of Phoenix 1.7.4 is available now via the BAMT fixer.
Donation sent. Donation sent too. =) Has anyone ever tried to setup a lan boot server to host the images for each rig? The cheap ass flash drives I bought are dying left right and center. I'd also like to remotely reset the image for a rig if it was running into issues. I have a remote reboot setup already when it locks up, but if it's loading the same image that doesn't always fix the problem. I'd like to have one machine with a HD (maybe raid 1) to host the 10 rig images and have everything boot from LAN. I've found the fastest fix is just swap in a new flash drive and that fixes 99% of the problems I've run into. I'm not sure if it's the flash drive dying or something being corrupted, it's not worth figuring out since it takes 15 seconds to swap the flash drive. But if it's a remote farm that is a little more trouble. =) Some rigs I switched to laptop HDs I had lying around and that works fine. I'm just wondering if anyone has gone a step further to help manage remote farms. If no one else has done it does anyone know how hard this would be to setup? If it's not horribly difficult I'll start a bounty. =) I have been looking at network boot. it would not be too difficult. the debian live tools can generate a netboot image from the same source that makes regular bamt. also, found some additional writes to disk that are eliminated in upcoming version, that will help keys live longer. |
|
|
|
|
|
