Pages:
Author

Topic: BAMT version 0.5 - Easy USB based mining Linux with farm wide management tools - page 40. (Read 324169 times)

legendary
Activity: 1260
Merit: 1000
I've already made it with regards to point 1.  What do you need to include it?

With regards to point two, as you said a number of pages ago, the utility of BAMT is that it already has all the tools built in for mining, instead of gathering them yourself.  So whether or not you're using GPUs, BAMT is still useful... or is that no longer the case with BAMT?

does stock linux have the ATI drivers, the SDK, the openCL libraries, atitweak, amdoverdrivectl, phoenix and cgminer preinstalled and ready to run?
does stock linux provide updates to this software via an automatic patch system?
etc,etc.
hero member
Activity: 616
Merit: 506
Here's what I'd like to see as far as cgminer in BAMT:  Just include a git directory that you can compile the latest version with if you're so inclined.  Just git pull, maybe a script to autogen, configure and make. 

sounds like a good project.  if someone makes it, i'll include in next version

Quote


At any rate, I have a question: BAMT complains heartily and refuses to start when no GPUs are detected (also I think this applies to a rig with GPUs that are unconfigured, too).  I have a rig with no GPUs, so I have to start cgminer manually because BAMT refuses to go further since no GPUs are detected.  Is there any way to disable this, since the rig will never have GPUs in it.


Trix are for kids, BAMT is for GPUs.   None of the BAMT tools, data collection, etc will work with non GPU devices anyway, so until that changes there is little point in using BAMT on a non gpu rig.   Since none of the BAMT stuff is going to work, why not disable the bamt startup script and just use the box like you would any other linux rig (or, use any other linux rig, whichever is easier).
legendary
Activity: 1260
Merit: 1000
Here's what I'd like to see as far as cgminer in BAMT:  Just include a git directory that you can compile the latest version with if you're so inclined.  Just git pull, maybe a script to autogen, configure and make. 

At any rate, I have a question: BAMT complains heartily and refuses to start when no GPUs are detected (also I think this applies to a rig with GPUs that are unconfigured, too).  I have a rig with no GPUs, so I have to start cgminer manually because BAMT refuses to go further since no GPUs are detected.  Is there any way to disable this, since the rig will never have GPUs in it.
hero member
Activity: 616
Merit: 506
So one my rigs had it's drive crap out, so I stuck my old BAMT key in there to keep it going until I get a new drive set up for it.  Working great, however I see the version of cgminer on it is outdated.

So, my question is, is there a quick and dirty way to update cgminer on BAMT or do I need to build the newer version from source and swap it in?

you can always build any version you like and throw it into /opt/miners/cgminer.   if there is ever a "stable" version of cgminer we will push out an update via the fixer, but I am hesitant to do that simply because we've seen so much trouble with past versions.  The version currently in BAMT has reduced the number of trouble reports massively compared to all the version before it, and versions ever since always seem to have some bug reported in the cgminer thread. 

If anybody who uses cgminer on lots of rigs (enough to have a fair sample, say 20+) wants to give feedback here or directly to me, that would help me know when/if there is a good version to push out, since I don't use it myself and I don't pay that much attention.


No, I agree with you, I wasn't asking for a a newer version push via the BAMT fixer, was just asking if there was a quicker way then building from the source.

As far as a "stable" version...  You of all people should know there is no such thing.  Look at all the chaos caused when the version number in BAMT went from 0.4 to 0.5.

Anyway, since BAMT is just a temp fix for me to keep the rig up for a few days, I'll not be building from source via ssh.   Wink

Regardless, hell of a little piece of software you put together lodcrappo.

thanks. fwiw building from source is just typing a few command, not a big deal and their all given in the cgminer docs.  dealing with the bugs in whatever version you choose is left as an exercise for the reader.

sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?
So one my rigs had it's drive crap out, so I stuck my old BAMT key in there to keep it going until I get a new drive set up for it.  Working great, however I see the version of cgminer on it is outdated.

So, my question is, is there a quick and dirty way to update cgminer on BAMT or do I need to build the newer version from source and swap it in?

you can always build any version you like and throw it into /opt/miners/cgminer.   if there is ever a "stable" version of cgminer we will push out an update via the fixer, but I am hesitant to do that simply because we've seen so much trouble with past versions.  The version currently in BAMT has reduced the number of trouble reports massively compared to all the version before it, and versions ever since always seem to have some bug reported in the cgminer thread. 

If anybody who uses cgminer on lots of rigs (enough to have a fair sample, say 20+) wants to give feedback here or directly to me, that would help me know when/if there is a good version to push out, since I don't use it myself and I don't pay that much attention.


No, I agree with you, I wasn't asking for a a newer version push via the BAMT fixer, was just asking if there was a quicker way then building from the source.

As far as a "stable" version...  You of all people should know there is no such thing.  Look at all the chaos caused when the version number in BAMT went from 0.4 to 0.5.

Anyway, since BAMT is just a temp fix for me to keep the rig up for a few days, I'll not be building from source via ssh.   Wink

Regardless, hell of a little piece of software you put together lodcrappo.
hero member
Activity: 616
Merit: 506
So one my rigs had it's drive crap out, so I stuck my old BAMT key in there to keep it going until I get a new drive set up for it.  Working great, however I see the version of cgminer on it is outdated.

So, my question is, is there a quick and dirty way to update cgminer on BAMT or do I need to build the newer version from source and swap it in?

you can always build any version you like and throw it into /opt/miners/cgminer.   if there is ever a "stable" version of cgminer we will push out an update via the fixer, but I am hesitant to do that simply because we've seen so much trouble with past versions.  The version currently in BAMT has reduced the number of trouble reports massively compared to all the version before it, and versions ever since always seem to have some bug reported in the cgminer thread. 

If anybody who uses cgminer on lots of rigs (enough to have a fair sample, say 20+) wants to give feedback here or directly to me, that would help me know when/if there is a good version to push out, since I don't use it myself and I don't pay that much attention.
sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?
So one my rigs had it's drive crap out, so I stuck my old BAMT key in there to keep it going until I get a new drive set up for it.  Working great, however I see the version of cgminer on it is outdated.

So, my question is, is there a quick and dirty way to update cgminer on BAMT or do I need to build the newer version from source and swap it in?
hero member
Activity: 616
Merit: 506
Will/should BAMT run on a Raspberry Pi?

Thanks

will: no, its an x86 distro
should: i guess a matter of opinion
member
Activity: 546
Merit: 10
Good, cause I thought I was going crazy with those for a while   Cheesy

You could also use the "idgpu" tool.
http://bamter.org/redmine/news/11


hmmm, didnt work for me.  All my fans stayed at the speed they are set too in conf file.  I went ahead and adjusted fans manually to figure it out.
sr. member
Activity: 446
Merit: 250
Will/should BAMT run on a Raspberry Pi?

Thanks
sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?
Yup, the card/GPU number has nothing to do with the location of the card on the board.  

I believe it is determined by "casting the bones" of a small rodent, possibly a shrew, after it has been roasted in the fires of a active volcano, then pickled in brine for 4 weeks, removed, and used as a paintbrush by a large Scottish woman (possibly named Helga), to paint a picture of the third largest moon of Jupiter.

I could be wrong though.

The number of the cards in my 890FXA-GD70 motherboard moving away from the processor currently is 0, 1, 5, 4, 2, 3.  That's just using the PCI-e slots, if I ever decide to use the PCI slot, those numbers are bunk.   Grin
hero member
Activity: 626
Merit: 500
Mining since May 2011.
Good, cause I thought I was going crazy with those for a while   Cheesy

You could also use the "idgpu" tool.
http://bamter.org/redmine/news/11
member
Activity: 546
Merit: 10
Good, cause I thought I was going crazy with those for a while   Cheesy
hero member
Activity: 616
Merit: 506
Thx for that explanation, this will help me isolate my troubled cards.  

If you know,
Under the "GPUs Detected:" the GPUs are listed and numbered starting with zero.  Next to that number is a label of the sort "0X:00.0" which I assume is which PCI slot the GPU is in.  Those numbers dont seem to make a lot of sense when I look at my board though (trying to find which card is which).  I assumed that the board manufacturer has numbered the slots in jumbled way, not left to right.  Think that is the case?

Those numbers do not indicate a particular slot on your board.  They are just the order the devices are enumerated by the ATI drivers and they can change whenever you add, remove, or rearrange cards.  For instance you might have 2 gpus that show up as 0 and 1, then you add add a third GPU in a new slot and it becomes 0, what was 0 becomes 2 and 1 stays at 1.    Or not.  There is no useful correlation that I have ever seen, though some boards do seem to stay put more than others.


member
Activity: 546
Merit: 10
Thx for that explanation, this will help me isolate my troubled cards.  

If you know,
Under the "GPUs Detected:" the GPUs are listed and numbered starting with zero.  Next to that number is a label of the sort "0X:00.0" which I assume is which PCI slot the GPU is in.  Those numbers dont seem to make a lot of sense when I look at my board though (trying to find which card is which).  I assumed that the board manufacturer has numbered the slots in jumbled way, not left to right.  Think that is the case?
hero member
Activity: 616
Merit: 506
Sometimes BAMT will create a file to disable overclocking.  You have to go to " /live/image/BAMT/CONTROL/ACTIVE " and delete the file there.

In my experience I have never seen any card but 0 get flagged there, so it can be difficult to figure out which card is the culprit.

Does anybody know of a log or something which may indicate which card f'ed up?  Has anybody seen any other card but 0 get flagged?

The logic is very simple.  If a phoenix process goes "zombie", i.e. the Linux kernel can't get the process to respond anymore, then the GPU associated with that phoenix instance is flagged with a noOC file, and the system is cold booted.  until the file is removed, bamt will not overclock that GPU any more.

Sometimes an overclocked or malfunctioning card will cause some other GPU to lock up.  Sometimes it will cause *all* the GPUs to lock up.  In this situation, GPU 0 or (more rarely) other gpus may be flagged when they are not actually the culprit.  

There is no good solution here.  Before I made mother do this, people were constantly having "bamt problems" that were nothing more than overzealous overclocking.  Take a stroll through the old 0.4 thread sometime if you want to see just how bad it was.  9 out of 10 or more posts were from people who simply overclocked their cards too much.

Now, we get the same people with questions about why BAMT won't overclock their GPUs.  Is this better?  Probably.  At least the rigs keep mining and it calls attention to the fact there is a problem.

In a perfect world, I wouldn't have to make mother babysit Smiley  But I don't see that happening.  People will always think they can just apply whatever settings they used under some other OS, some other mining client, or using some other kernel/settings without doing any testing.  When things crash, mother just tries to keep you mining.

Remember this:  If mother is disabling overclocking on your GPU(s), *a GPU is locking up*.  The only thing that triggers mother to place the noOC file is a hung phoenix, and the only thing that hangs phoenix is a locked up GPU (at least, no one has suggested or proven otherwise yet).  So, you will have to make some change to fix the problem.  It is highly likely the change to fix this will be: reducing your overclocking settings on one or more cards.

(the rest isn't aimed at anyone in particular, just to address what I know will be in the head of some readers at this point)...

"But but but I know these cards are stable at XXX mhz because blah blah".    

No.  

You know that they were stable at that speed using some particular OS, mining client, kernel and settings.  That is all.  It doesn't mean much if you're no longer using that exact OS, client, kernel and settings.

Some platforms use a GUI that can use 10% or more of a GPUs time just by being loaded (Ubuntu I am looking at you and your crapmaster "Unity".  Windows isn't much better).   BAMT's GUI uses so little resources that I haven't been able to measure it with any certainty.  This means your GPU may have been getting an awful lot of breaks from mining while the OS took over every so many ms.  That just isn't happening anymore.  Your GPU is now spending all of it's time mining without those tiny constant breaks.  

BAMT also strives to include the very best kernels for Phoenix.  We often use patched kernels with additional improvements from the stock versions.  This means that not only is your GPU working constantly, it may well be working harder at the same clockrate.

Put it all together and surely you can understand why the rate your GPU was stable at in (whatever) doesn't mean much when you move to BAMT, and you may very likely find a drop of some Mhz is required for stability.

The good side is that ultimately, you will find that same or higher shares submitted and at lower clock rates == generally less power.  After all, you're now wasting less time and power doing stuff that doesn't get you paid.




hero member
Activity: 658
Merit: 500
Sometimes BAMT will create a file to disable overclocking.  You have to go to " /live/image/BAMT/CONTROL/ACTIVE " and delete the file there.

In my experience I have never seen any card but 0 get flagged there, so it can be difficult to figure out which card is the culprit.

Does anybody know of a log or something which may indicate which card f'ed up?  Has anybody seen any other card but 0 get flagged?

Thanks.

If that is the case, its probably a false alarm. Prior to BAMT, i was using linuxcoin and all 4 GPUs have never crashed at the clock setting. Its a conservative clock 800/300



I would suggest starting up with purely stock settings, then tweaking them out one at a time in cgminer, then saving the config.  I don't know if you are having the same issue I did or not, but different OSes, driver versions, and/or miners sometimes order/number the cards differently.  What may have been card 0 in linuxcoin, may be card 2 in BAMT.  I had a card go from 5, to number 3 when I went from BAMT to Ubuntu.  It really had me confused for a bit.

I havent restarted since manually set the clock. It has been hashing ok so far. I will keep an eye on it tho. "Mother" is quite a strict lady isnt she?
sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?
Sometimes BAMT will create a file to disable overclocking.  You have to go to " /live/image/BAMT/CONTROL/ACTIVE " and delete the file there.

In my experience I have never seen any card but 0 get flagged there, so it can be difficult to figure out which card is the culprit.

Does anybody know of a log or something which may indicate which card f'ed up?  Has anybody seen any other card but 0 get flagged?

Thanks.

If that is the case, its probably a false alarm. Prior to BAMT, i was using linuxcoin and all 4 GPUs have never crashed at the clock setting. Its a conservative clock 800/300



I would suggest starting up with purely stock settings, then tweaking them out one at a time in cgminer, then saving the config.  I don't know if you are having the same issue I did or not, but different OSes, driver versions, and/or miners sometimes order/number the cards differently.  What may have been card 0 in linuxcoin, may be card 2 in BAMT.  I had a card go from 5, to number 3 when I went from BAMT to Ubuntu.  It really had me confused for a bit.
hero member
Activity: 658
Merit: 500
Sometimes BAMT will create a file to disable overclocking.  You have to go to " /live/image/BAMT/CONTROL/ACTIVE " and delete the file there.

In my experience I have never seen any card but 0 get flagged there, so it can be difficult to figure out which card is the culprit.

Does anybody know of a log or something which may indicate which card f'ed up?  Has anybody seen any other card but 0 get flagged?

Thanks.

If that is the case, its probably a false alarm. Prior to BAMT, i was using linuxcoin and all 4 GPUs have never crashed at the clock setting. Its a conservative clock 800/300

member
Activity: 546
Merit: 10
Sometimes BAMT will create a file to disable overclocking.  You have to go to " /live/image/BAMT/CONTROL/ACTIVE " and delete the file there.

In my experience I have never seen any card but 0 get flagged there, so it can be difficult to figure out which card is the culprit.

Does anybody know of a log or something which may indicate which card f'ed up?  Has anybody seen any other card but 0 get flagged?
Pages:
Jump to: