if you just mean it isn't in the default /etc/bamt/bamt.conf... well there are tons of options that are not in that file!
Ha, they are in mine, well most anyway...I've kept a seperate .conf where I add in all the changes you post for reference.
Topic: BAMT version 0.5 - Easy USB based mining Linux with farm wide management tools - page 70. (Read 324176 times)
March 02, 2012, 10:45:37 AM
Ha, they are in mine, well most anyway...I've kept a seperate .conf where I add in all the changes you post for reference.
March 02, 2012, 08:42:01 AM
I'd also like the 8 GPU ability. However, with all the "features" of BAMT disabled, it seems like using BAMT is kind of pointless. It's got all the features for big time miners, but none of the support apparently. Kind of strange in my opinion, but eh..
What does this mean? Can you be specific? There are several "big time" miners using bamt. I know of one that is more than 50Ghash.
As far as options, yes they were a bit different, since I was following the suggested options for running with BAMT. I'll see what I can do about changing them in the config file.
I am not aware of any "suggested options" for using cgminer with BAMT. Use exactly the same options you would use with cgminer on any other system.
It is impossible to troubleshoot a potential issue if we are comparing two different configurations.
March 02, 2012, 08:26:55 AM
I'd also like the 8 GPU ability. However, with all the "features" of BAMT disabled, it seems like using BAMT is kind of pointless. It's got all the features for big time miners, but none of the support apparently. Kind of strange in my opinion, but eh..
As far as options, yes they were a bit different, since I was following the suggested options for running with BAMT. I'll see what I can do about changing them in the config file.
As far as options, yes they were a bit different, since I was following the suggested options for running with BAMT. I'll see what I can do about changing them in the config file.
March 02, 2012, 04:21:09 AM
I don't have
do_mgpumon: 0
what does it do? I use the web mgpumon without that on my settings
Code:
# start mgpumon in background using /etc/bamt/mgpumon.conf?
# (this will put the mgpumon web interface at http://this/mgpumon/
do_mgpumon: 0
This one doesn't run mgpumon, it's set on another rig.
Is this code in version .5b? Because, mine does not have it. Just curious, because I have my web interface working fine without the code.
that option has been available for quite some time, back to 0.4 days I believe.
what does it mean "mine does not have it"? you added it set to 1 and mgpumon did not start at boot?
if you just mean it isn't in the default /etc/bamt/bamt.conf... well there are tons of options that are not in that file!
March 02, 2012, 03:36:32 AM
I don't have
do_mgpumon: 0
what does it do? I use the web mgpumon without that on my settings
Code:
# start mgpumon in background using /etc/bamt/mgpumon.conf?
# (this will put the mgpumon web interface at http://this/mgpumon/
do_mgpumon: 0
This one doesn't run mgpumon, it's set on another rig.
Is this code in version .5b? Because, mine does not have it. Just curious, because I have my web interface working fine without the code.
March 01, 2012, 10:53:34 PM
I don't know but I wonder if some of us should finance a bounty for a cgminer only distro. BAMT does a lot (overclocking, pool management, restarting sick GPUs, etc) which is already duplicated by cgminer.
And all of which is completely optional, using a simple config file.
Since BAMT is 32bit I had to install LinuxCoin (which hasn't been updated in what 9 months? ) for my 8GPU watercooled rig. Just to get a test environment up and running quickly I just dropped LinuxCoin on a USB drive, installed cgminer, wrote a couple scripts to launch cgminer in screen on boot and edited a cgminer.conf.
The 32 vs 64 bit thing has been done to death. For people that want 8 gpus per rig, bamt will not be an option.
However, given how little economic sense an 8 gpu rig makes, and therefore how rare they are, and with the impending switch to FPGA based mining, I just don't see this as a very big problem.
Trust me when i say my Linux skills are "special" and not in a good way). That "temporary" rig has been rock solid. Not a beep just hashing away @ 3.2GH/s. It has done so well I am reluctant to touch anything.
So maybe we just need a simpler "static" distro (I would pay extra for one which has simple steps to setup and host via PXE) which grabs config files and sends statuses to a separate monitoring/management "server"?
So maybe we just need a simpler "static" distro (I would pay extra for one which has simple steps to setup and host via PXE) which grabs config files and sends statuses to a separate monitoring/management "server"?
How much will you pay? It sounds like all you want is BAMT with the options disabled. If you pay enough to make it worth my time, I would gladly generate any image type you want, PXE, 64bit, whatever.
March 01, 2012, 10:45:06 PM
Ok, I should have clarified that I have loaded systems... I'm sure bamt works great with 1 or 2 GPUs... but when it's trying to manage 6 - 7 GPUs it seems to be having trouble.
I realize I can disable the stuff in bamt that's causing the problems (which is what I've basically done by just invoking cgminer directly), but I would like those options ... there's clearly something wrong with the scripts that are causing the (perceived) instability. It's very seriously doubtful that I'm "doing something wrong," since I seem to be able to get bamt "stable" by disabling most of bamt. I won't discount the possibility, but I'm open to suggestions.
gnar1ta$- how are you starting the GPUs in your system if you're not using the bamt scripts?
I realize I can disable the stuff in bamt that's causing the problems (which is what I've basically done by just invoking cgminer directly), but I would like those options ... there's clearly something wrong with the scripts that are causing the (perceived) instability. It's very seriously doubtful that I'm "doing something wrong," since I seem to be able to get bamt "stable" by disabling most of bamt. I won't discount the possibility, but I'm open to suggestions.
gnar1ta$- how are you starting the GPUs in your system if you're not using the bamt scripts?
There are a great many people using bamt with 6 or 7 GPUs. Most of them use phoenix however.
The script simply starts cgminer im a screen session with the parameters you have supplied in the bamt.conf.
It does nothing else.
It is not running at all once cgminer has been started. It's only function is to start cgminer with your given parameters.
BAMT's dead gpu detection does not run if BAMT is in cgminer mode.
If you are observing different behavior when bamt starts cgminer compared to when you start it manually, I think you need to examine your bamt.conf and make sure the cgminer is getting the same parameters in both cases. otherwise, there isn't any difference (other than being in screen? unless you do that manually too).
March 01, 2012, 10:17:36 PM
I don't have
do_mgpumon: 0
what does it do? I use the web mgpumon without that on my settings
Code:
# start mgpumon in background using /etc/bamt/mgpumon.conf?
# (this will put the mgpumon web interface at http://this/mgpumon/
do_mgpumon: 0
This one doesn't run mgpumon, it's set on another rig.
March 01, 2012, 10:02:27 PM
Ok, I should have clarified that I have loaded systems... I'm sure bamt works great with 1 or 2 GPUs... but when it's trying to manage 6 - 7 GPUs it seems to be having trouble.
I realize I can disable the stuff in bamt that's causing the problems (which is what I've basically done by just invoking cgminer directly), but I would like those options ... there's clearly something wrong with the scripts that are causing the (perceived) instability. It's very seriously doubtful that I'm "doing something wrong," since I seem to be able to get bamt "stable" by disabling most of bamt. I won't discount the possibility, but I'm open to suggestions.
gnar1ta$- how are you starting the GPUs in your system if you're not using the bamt scripts?
I realize I can disable the stuff in bamt that's causing the problems (which is what I've basically done by just invoking cgminer directly), but I would like those options ... there's clearly something wrong with the scripts that are causing the (perceived) instability. It's very seriously doubtful that I'm "doing something wrong," since I seem to be able to get bamt "stable" by disabling most of bamt. I won't discount the possibility, but I'm open to suggestions.
gnar1ta$- how are you starting the GPUs in your system if you're not using the bamt scripts?
Code:
GPU 0: 75.0C 3403RPM | 297.7/297.0Mh/s | A:19040 R:454 HW:0 U: 2.09/m I: 8
GPU 1: 72.0C 2464RPM | 297.7/297.9Mh/s | A:19219 R:432 HW:0 U: 2.11/m I: 8
GPU 2: 73.0C 3524RPM | 297.1/297.1Mh/s | A:19162 R:472 HW:0 U: 2.11/m I: 8
GPU 3: 74.0C 3730RPM | 295.3/295.3Mh/s | A:18542 R:432 HW:0 U: 2.04/m I: 8
GPU 4: 74.0C 3182RPM | 295.4/295.3Mh/s | A:18668 R:448 HW:0 U: 2.05/m I: 8
GPU 5: 73.0C 2783RPM | 297.7/297.8Mh/s | A:19197 R:440 HW:0 U: 2.11/m I: 8
I have 2 rigs with 6 single GPU's. BAMT still launches them, I just use cgminer for everything. Here is bamt.conf (GPU 0-5 are the same)
Code:
---
settings:
miner_id: 6870
miner_loc: miner3
do_bcast_status: 1
do_manage_config: 0
start_mining_init_delay: 30
start_mining_miner_delay: 0
do_monitor: 0
do_mgpumon: 0
do_cgsnoop: 0
detect_defunct: 0
cgminer: 1
cgminer_opts: --api-listen --submit-stale --failover-only -o http://xx -u xx -p xx -o http://xx -u xx -p xx -I 8 -g 1 --auto-gpu --gpu-engine 800-950 --gpu-memdiff -100 --auto-fan
# GPU Configurtation
gpu0:
disabled: 0
cgminer: 1
monitor_temp_lo: 45
monitor_temp_hi: 80
monitor_load_lo: 80
monitor_hash_lo: 125
monitor_shares_lo: 1
I don't have
do_mgpumon: 0
what does it do? I use the web mgpumon without that on my settings
March 01, 2012, 08:48:51 PM
Ok, I should have clarified that I have loaded systems... I'm sure bamt works great with 1 or 2 GPUs... but when it's trying to manage 6 - 7 GPUs it seems to be having trouble.
I realize I can disable the stuff in bamt that's causing the problems (which is what I've basically done by just invoking cgminer directly), but I would like those options ... there's clearly something wrong with the scripts that are causing the (perceived) instability. It's very seriously doubtful that I'm "doing something wrong," since I seem to be able to get bamt "stable" by disabling most of bamt. I won't discount the possibility, but I'm open to suggestions.
gnar1ta$- how are you starting the GPUs in your system if you're not using the bamt scripts?
I realize I can disable the stuff in bamt that's causing the problems (which is what I've basically done by just invoking cgminer directly), but I would like those options ... there's clearly something wrong with the scripts that are causing the (perceived) instability. It's very seriously doubtful that I'm "doing something wrong," since I seem to be able to get bamt "stable" by disabling most of bamt. I won't discount the possibility, but I'm open to suggestions.
gnar1ta$- how are you starting the GPUs in your system if you're not using the bamt scripts?
Code:
GPU 0: 75.0C 3403RPM | 297.7/297.0Mh/s | A:19040 R:454 HW:0 U: 2.09/m I: 8
GPU 1: 72.0C 2464RPM | 297.7/297.9Mh/s | A:19219 R:432 HW:0 U: 2.11/m I: 8
GPU 2: 73.0C 3524RPM | 297.1/297.1Mh/s | A:19162 R:472 HW:0 U: 2.11/m I: 8
GPU 3: 74.0C 3730RPM | 295.3/295.3Mh/s | A:18542 R:432 HW:0 U: 2.04/m I: 8
GPU 4: 74.0C 3182RPM | 295.4/295.3Mh/s | A:18668 R:448 HW:0 U: 2.05/m I: 8
GPU 5: 73.0C 2783RPM | 297.7/297.8Mh/s | A:19197 R:440 HW:0 U: 2.11/m I: 8
I have 2 rigs with 6 single GPU's. BAMT still launches them, I just use cgminer for everything. Here is bamt.conf (GPU 0-5 are the same)
Code:
---
settings:
miner_id: 6870
miner_loc: miner3
do_bcast_status: 1
do_manage_config: 0
start_mining_init_delay: 30
start_mining_miner_delay: 0
do_monitor: 0
do_mgpumon: 0
do_cgsnoop: 0
detect_defunct: 0
cgminer: 1
cgminer_opts: --api-listen --submit-stale --failover-only -o http://xx -u xx -p xx -o http://xx -u xx -p xx -I 8 -g 1 --auto-gpu --gpu-engine 800-950 --gpu-memdiff -100 --auto-fan
# GPU Configurtation
gpu0:
disabled: 0
cgminer: 1
monitor_temp_lo: 45
monitor_temp_hi: 80
monitor_load_lo: 80
monitor_hash_lo: 125
monitor_shares_lo: 1
March 01, 2012, 07:25:37 PM
Ok, I should have clarified that I have loaded systems... I'm sure bamt works great with 1 or 2 GPUs... but when it's trying to manage 6 - 7 GPUs it seems to be having trouble.
I realize I can disable the stuff in bamt that's causing the problems (which is what I've basically done by just invoking cgminer directly), but I would like those options ... there's clearly something wrong with the scripts that are causing the (perceived) instability. It's very seriously doubtful that I'm "doing something wrong," since I seem to be able to get bamt "stable" by disabling most of bamt. I won't discount the possibility, but I'm open to suggestions.
gnar1ta$- how are you starting the GPUs in your system if you're not using the bamt scripts?
I realize I can disable the stuff in bamt that's causing the problems (which is what I've basically done by just invoking cgminer directly), but I would like those options ... there's clearly something wrong with the scripts that are causing the (perceived) instability. It's very seriously doubtful that I'm "doing something wrong," since I seem to be able to get bamt "stable" by disabling most of bamt. I won't discount the possibility, but I'm open to suggestions.
gnar1ta$- how are you starting the GPUs in your system if you're not using the bamt scripts?
Like I told you before I have 3 5970's which is 6 GPU total on 1 rig. I have no issues.
To help you better, please answer the following questions:
What GPU's you have?
Are you using extenders?
please post your bamt.conf here so I can see them.
thanks
March 01, 2012, 07:04:10 PM
Ok, I should have clarified that I have loaded systems... I'm sure bamt works great with 1 or 2 GPUs... but when it's trying to manage 6 - 7 GPUs it seems to be having trouble.
I realize I can disable the stuff in bamt that's causing the problems (which is what I've basically done by just invoking cgminer directly), but I would like those options ... there's clearly something wrong with the scripts that are causing the (perceived) instability. It's very seriously doubtful that I'm "doing something wrong," since I seem to be able to get bamt "stable" by disabling most of bamt. I won't discount the possibility, but I'm open to suggestions.
gnar1ta$- how are you starting the GPUs in your system if you're not using the bamt scripts?
I realize I can disable the stuff in bamt that's causing the problems (which is what I've basically done by just invoking cgminer directly), but I would like those options ... there's clearly something wrong with the scripts that are causing the (perceived) instability. It's very seriously doubtful that I'm "doing something wrong," since I seem to be able to get bamt "stable" by disabling most of bamt. I won't discount the possibility, but I'm open to suggestions.
gnar1ta$- how are you starting the GPUs in your system if you're not using the bamt scripts?
March 01, 2012, 06:17:34 PM
have you tried the older version of bamt? maybe for you it might be more stable.
March 01, 2012, 06:08:00 PM
If you don't like or think the restart script is causing stability problems, just turn it off. Add detect_defunct: 0 to your bamt.conf. I use cgminer exclusively now on 3 rigs and am still tweaking clocks, I've always had the script and all BAMT GPU control off and handle everything with cgminer. I set 30 sec delay to start X and 0 seconds between GPU's - no issues so far with 16 GPU's.
March 01, 2012, 06:04:53 PM
I don't know but I wonder if some of us should finance a bounty for a cgminer only distro. BAMT does a lot (overclocking, pool management, restarting sick GPUs, etc) which is already duplicated by cgminer.
Since BAMT is 32bit I had to install LinuxCoin (which hasn't been updated in what 9 months? ) for my 8GPU watercooled rig. Just to get a test environment up and running quickly I just dropped LinuxCoin on a USB drive, installed cgminer, wrote a couple scripts to launch cgminer in screen on boot and edited a cgminer.conf.
Trust me when i say my Linux skills are "special" and not in a good way). That "temporary" rig has been rock solid. Not a beep just hashing away @ 3.2GH/s. It has done so well I am reluctant to touch anything.
So maybe we just need a simpler "static" distro (I would pay extra for one which has simple steps to setup and host via PXE) which grabs config files and sends statuses to a separate monitoring/management "server"?
Since BAMT is 32bit I had to install LinuxCoin (which hasn't been updated in what 9 months? ) for my 8GPU watercooled rig. Just to get a test environment up and running quickly I just dropped LinuxCoin on a USB drive, installed cgminer, wrote a couple scripts to launch cgminer in screen on boot and edited a cgminer.conf.
Trust me when i say my Linux skills are "special" and not in a good way). That "temporary" rig has been rock solid. Not a beep just hashing away @ 3.2GH/s. It has done so well I am reluctant to touch anything.
So maybe we just need a simpler "static" distro (I would pay extra for one which has simple steps to setup and host via PXE) which grabs config files and sends statuses to a separate monitoring/management "server"?
+1
I will help fund this project.
March 01, 2012, 05:47:46 PM
I don't know but I wonder if some of us should finance a bounty for a cgminer only distro. BAMT does a lot (overclocking, pool management, restarting sick GPUs, etc) which is already duplicated by cgminer.
Since BAMT is 32bit I had to install LinuxCoin (which hasn't been updated in what 9 months? ) for my 8GPU watercooled rig. Just to get a test environment up and running quickly I just dropped LinuxCoin on a USB drive, installed cgminer, wrote a couple scripts to launch cgminer in screen on boot and edited a cgminer.conf.
Trust me when i say my Linux skills are "special" and not in a good way. That "temporary" rig has been rock solid. Not a peep just hashing away @ 3.2GH/s. It has done so well I am reluctant to touch anything.
So maybe we just need a simpler "static" distro (I would pay extra for one which has simple steps to setup and host via PXE) which grabs config files and pushes API stats to a "server" for centralized management and monitoring.
In essence dumb simple rigs which become little more than hashing appliances.
On edit: to clarify my jumbled thoughts.
Since BAMT is 32bit I had to install LinuxCoin (which hasn't been updated in what 9 months? ) for my 8GPU watercooled rig. Just to get a test environment up and running quickly I just dropped LinuxCoin on a USB drive, installed cgminer, wrote a couple scripts to launch cgminer in screen on boot and edited a cgminer.conf.
Trust me when i say my Linux skills are "special" and not in a good way. That "temporary" rig has been rock solid. Not a peep just hashing away @ 3.2GH/s. It has done so well I am reluctant to touch anything.
So maybe we just need a simpler "static" distro (I would pay extra for one which has simple steps to setup and host via PXE) which grabs config files and pushes API stats to a "server" for centralized management and monitoring.
In essence dumb simple rigs which become little more than hashing appliances.
On edit: to clarify my jumbled thoughts.
March 01, 2012, 05:47:09 PM
Ok, so I've been poking and prodding... prodding and poking, and then poking some more at BAMT.
I'm just having a devil of a time getting it stable under any circumstance. I've installed it on 4 or 5 machines, and on all of them, if I use the default tools to mine, the systems constantly reboot themselves with "stuck" GPUs or for some other reason... seem to vary.
Anyway, if I then disable auto mining and disable all GPUs in BAMT, then open a cgminer session manually, the systems are rock stable and happily mine away.
Why is Phoenix, Phoenix 2 and cgminer, when invoked via the bamt scripts so unstable/picky? The system is stable when doing it's own thing, so it's not the hardware, and the systems were stable prior to bamt with a Ubuntu install... what is bamt doing that it keeps thinking the system has become unstable and forces a reboot when none is actually required?
I'm just having a devil of a time getting it stable under any circumstance. I've installed it on 4 or 5 machines, and on all of them, if I use the default tools to mine, the systems constantly reboot themselves with "stuck" GPUs or for some other reason... seem to vary.
Anyway, if I then disable auto mining and disable all GPUs in BAMT, then open a cgminer session manually, the systems are rock stable and happily mine away.
Why is Phoenix, Phoenix 2 and cgminer, when invoked via the bamt scripts so unstable/picky? The system is stable when doing it's own thing, so it's not the hardware, and the systems were stable prior to bamt with a Ubuntu install... what is bamt doing that it keeps thinking the system has become unstable and forces a reboot when none is actually required?
Well, I have been mining on .5b since Monday night. And it is running strong without one problem. I have 1 rig with 3 5970 on a msi motherboard. and rig 2 has a ASUS motherboard with 1 5970.
I have them clocked at 825/300 and getting 382mh/s constant. No variance.
My temps range from 69c to 78c
Probably, you are doing something wrong with the bamt.conf file or over clocking too much.
March 01, 2012, 05:19:35 PM
Ok, so I've been poking and prodding... prodding and poking, and then poking some more at BAMT.
I'm just having a devil of a time getting it stable under any circumstance. I've installed it on 4 or 5 machines, and on all of them, if I use the default tools to mine, the systems constantly reboot themselves with "stuck" GPUs or for some other reason... seem to vary.
Anyway, if I then disable auto mining and disable all GPUs in BAMT, then open a cgminer session manually, the systems are rock stable and happily mine away.
Why is Phoenix, Phoenix 2 and cgminer, when invoked via the bamt scripts so unstable/picky? The system is stable when doing it's own thing, so it's not the hardware, and the systems were stable prior to bamt with a Ubuntu install... what is bamt doing that it keeps thinking the system has become unstable and forces a reboot when none is actually required?
I'm just having a devil of a time getting it stable under any circumstance. I've installed it on 4 or 5 machines, and on all of them, if I use the default tools to mine, the systems constantly reboot themselves with "stuck" GPUs or for some other reason... seem to vary.
Anyway, if I then disable auto mining and disable all GPUs in BAMT, then open a cgminer session manually, the systems are rock stable and happily mine away.
Why is Phoenix, Phoenix 2 and cgminer, when invoked via the bamt scripts so unstable/picky? The system is stable when doing it's own thing, so it's not the hardware, and the systems were stable prior to bamt with a Ubuntu install... what is bamt doing that it keeps thinking the system has become unstable and forces a reboot when none is actually required?
March 01, 2012, 04:27:27 PM
Is there a way to check VRM temps without X?
March 01, 2012, 01:28:38 AM
Quote
Your overclocking was too high.
Your GPU locked up.
In order to make the best of the situation, BAMT has disabled O/C on that GPU and rebooted.
This allowed your rig to continue mining in a situation where otherwise it would have sat there locked up. You're welcome.
Now you must reduce overclocking settings, remove the file in /live/image/BAMT/CONTROL/ACTIVE that has suspended o/c, and restart mining.
PS - Graphs and all recorded data are generated in ram only. They are lost at every reboot. This is to prevent your USB key from being destroyed. You can run Munin on a regular linux box and gather stats/graphs from an unlimted # of bamt rigs and store them for as long as you want, but a USB based system cannot do this.
Your GPU locked up.
In order to make the best of the situation, BAMT has disabled O/C on that GPU and rebooted.
This allowed your rig to continue mining in a situation where otherwise it would have sat there locked up. You're welcome.
Now you must reduce overclocking settings, remove the file in /live/image/BAMT/CONTROL/ACTIVE that has suspended o/c, and restart mining.
PS - Graphs and all recorded data are generated in ram only. They are lost at every reboot. This is to prevent your USB key from being destroyed. You can run Munin on a regular linux box and gather stats/graphs from an unlimted # of bamt rigs and store them for as long as you want, but a USB based system cannot do this.
Worked perfectly, Thanks. I'm glad to know that location to save me the time in case an overclock has issues again. Very happy with Phoenix2 as well, same hash rate but significantly reduced the invalids.
Edit: Actually it looks like I am wrong on the invalids. on one rig 15900 shares, 0 invalid reported by gpumon. Strange thing is invalid number may show 1 for a second then go back to 0. This did not happen with Phoenix1. 2 rigs doing the same thing with Phoenix2.
Jump to: