Pages:
Author

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

hero member
Activity: 626
Merit: 500
Mining since May 2011.
me again,

one of my cards crashed tonight, cant tell why. But after restarting mining the card got back to 800/1000 instead of 525/225 and went bananas. my bamt.conf is still fine, saying 525/225 clock/ram. But no matter how often i restart mining or keep coldrebooting, it wont overclock this damn card. What the hell?

https://bitcointalksearch.org/topic/m.985548
hero member
Activity: 502
Merit: 500
mother disabled ocing on he card
read the thread near the bening it will link you to the bamt 4 thread to a command that will delete the error code in mother
hero member
Activity: 525
Merit: 500
..yeah
me again,

one of my cards crashed tonight, cant tell why. But after restarting mining the card got back to 800/1000 instead of 525/225 and went bananas. my bamt.conf is still fine, saying 525/225 clock/ram. But no matter how often i restart mining or keep coldrebooting, it wont overclock this damn card. What the hell?
member
Activity: 63
Merit: 10
I see people keep asking for a BAMT able to run with 7970 cards so I am thinking to share mine.
It may work for you or it may not...give it a try. It worked for me two months already so is not gonna blow your PC.

It is a BAMT updated to SDK 2.6 and 8.921 AMD driver using cgminer 2.5.0.
SDK 2.6 was recommended by ckolivas for 7970 and the 8.921 driver was (I tried all recent drivers) the only one that did not gave me hardware errors with cgminer.
Other (more recent) SDK/driver combinations could work also but this one worked perfectly for me.

All you need to do is edit bamt.conf at the cgminer_opts line and enable cgminer in each GPU section for how many cards you have.
If you want to use a separate cgminer config be my guest, I personally enter all the options I need in that cgminer_opts line.

I give no guarantees that it will work for you, it does for me with three 7970 cards.

root password = root
user password = live

Download:
https://ca.isohunt.com/torrent_details/402809617/BAMT+for+7970?tab=summary

Hope this damn torrent will work, eventually add these trackers to your bit-torrent client:

http://announce.opensharing.org:2710/announce
http://exodus.desync.com:6969/announce



It work for my, Thanks a lot
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Well when you keep apologising by saying: "sorry I made that mistake BECAUSE the API is crap"
I oddly enough don't take that nicely at all.

... that's why I said stop replying ...

Who are these people you have sent forth with API bugs?

I'm having difficulty remembering any bugs in the API that ever related to BAMT ...
(probably >99% of the code in the API was put there by me)

I think there was an issue where you were sending the wrong 'quit' string to the API (with a \n) once ...
.. and I know BAMT still puts a \n on the end of everything it send to the API ... which it shouldn't ...

...

2.3.1f came from me - I added BFL and Icarus API support to 2.3.1 while ckolivas was away ...
... and that's why people with BFL singles and MiniRigs still use BAMT with their GPU rigs ...
(that 2.3.1f number already tells you it came from me - ckolivas doesn't put letters in there - I do)

...

Meh
rjk
sr. member
Activity: 448
Merit: 250
1ngldh
When Kano gets a chip on his shoulder, it's almost impossible to remove and usually results in major collateral damage to anything or anyone within a large radius.
It's a shame.
hero member
Activity: 616
Merit: 506

Fuck off.


Are you 12 years old?  

I made a snap judgement call in an IRC conversation with some random person, and I was wrong.

Are we done?  

If not, please clearly state what it is you want from me.  What are you trying to accomplish here?  

12 - yeah that would be good if I was again Smiley

Meh.

Stop replying, you just keep digging the hole deeper.

I'll reply if I feel like it.

There is no hole.  There is merely a bad assumption on my part, an apology from me, and all kinds of inappropriate responses, accusations, and general douchebaggery from you.

I don't use cgminer.  My knowledge of it is limited to a few tests and feedback from users.  It is not the default miner nor the preferred miner for use with BAMT.  The limited support BAMT has for cgminer is provided basically as a favor to a few key BAMT supporters.

In the past, I've had to waste my time helping users who found cgminer would lock up or crash any time the API was accessed.
In these situations, the tell-tale sign is that cgminer works fine if you don't run gpumon (a monitoring utility that talks to cgminer via the API).

I reduced the number and frequency of calls gpumon made to the API, and users reported improved stability, but still some issues until we found version 2.3f which seemed to have the magic mix required for stable operation.  A bit later, gigavps found that 2.3f would sometimes just exit with no clear indication of why.  He was desperate for a fix, and I believe contacted you guys, posted on the cgminer forum, etc.  When no solution was forthcoming, he asked me if I could hack mother to detect that it had exited and start it back up.  So I did.

This bit of code in mother doesn't work properly with version 2.6.0.  Frankly, it was never meant to, as 2.6.0 did not exist when it was written.  It is meant to start version 2.3f if it exits (which it does).

Now... some guy comes into the IRC channel and says "I think BAMT is restarting cgminer".  I've never heard of this before.  BAMT does have code that restarts Phoenix in certain situations, but nothing that restarts cgminer - except the code that detects when cgminer just isn't running.  He then tells me it only happens when he runs gpumon.  An exact duplicate of the problems we had in older versions.  To be clear, this was bad information, as ckolivas has found this problem will happen whether or not gpumon is running.  But that isn't the information I was given.  Because his symptoms exactly matched things we've seen before, I told him it was probably the same issue we've had before.  Make sense?

I have admitted I made a bad call.  I have apologized.  I hope you can understand why and how this happened.  I have been nothing but polite with you.  Show me the same courtesy and explain yourself.  Why are you so upset about this?








legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4

Fuck off.


Are you 12 years old? 

I made a snap judgement call in an IRC conversation with some random person, and I was wrong.

Are we done? 

If not, please clearly state what it is you want from me.  What are you trying to accomplish here? 

12 - yeah that would be good if I was again Smiley

Meh.

Stop replying, you just keep digging the hole deeper.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Calm down. There's no doubt there were dud cgminer releases along the way, and I tried to get bugfixes out asap. Move on, nothing more to see here.
hero member
Activity: 616
Merit: 506

Fuck off.


Are you 12 years old? 

I made a snap judgement call in an IRC conversation with some random person, and I was wrong.

Are we done? 

If not, please clearly state what it is you want from me.  What are you trying to accomplish here? 


legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
...

Only discussions I've ever had with you in IRC were
4-Feb you asking for a change that isn't really possible (though I did implement what was possible)
13-Feb discussing casper/cow issues
23-Feb discussing the risks of using a one-man supplied OS


Yes, the impression I got from those conversations was that you were against the very idea of BAMT, and generally uninterested in changing cgminer to let it do all the things Phoenix could do with BAMT.
Oh, so the fact that I made that change based on your request, with nothing but a request and no donation, is me being generally uninterested in changing cgminer for you.

Fuck off.


However I will also add, software is buggy, INCLUDING yours, and pretending you are some magical unicorn who doesn't write bugs but just blame someone else is mind numbingly stupid

I must have missed where I did anything like that.  If you read through the fix descriptions to find #20, surely you noticed all the places where I specifically talked about my own bugs.  I'll freely admit I jumped to a conclusion based on past experience, and this time it was not correct.  I apologized already, and I apologize again.  
... and again you have repeated it - that's the point of my whole post you quoted from - what are these past API bugs that you have directly claimed to other people are there and are your excuse for accusing the API in this issue.

As you have stated
Code:
... cgminer's buggiest part is the api that gpumon uses ...

Your response is simply to excuse yourself based on never reported (by anyone) API bugs.

Meh.
hero member
Activity: 616
Merit: 506


LOL

Are you seriously saying that cgminer hasn't been insanely buggy on nearly every release?

Do you have any idea how much of my time is wasted on cgminer bugs?  Or how many past versions of cgminer have been unusable in a remotely controlled system because simply by using the API cgminer will hang or exit?

Case in point:  The problem we are seeing now with 2.6.0 is due to a dead cgminer function in BAMT.. a function that only exists because cgminer kept crashing for Gigavps!

Yeah and he paid you 50 BTC for a crap regex that you call fix '20'

I don't recall the exact details, but Gigavps has indeed been very generous in supporting BAMT.  Many of the features are a direct result of his donations.  I believe he would back me up in saying that I generally try to discourage him from donating so much, quite the opposite of what you seem to be suggesting.


Well since you have NEVER reported any details of one of these mystical API bugs that I apparently have written so many of ...

Try doing that for once ... or is that all just total bullshit?


I have often and repeatedly directed cgminer users to the cgminer irc channel and forum thread for assistance with problems.  I do not use cgminer myself so do not have these issues or know the details other than as a 3rd party.  I typically rely on the larger farms using BAMT for reports of issues, and I believe they have followed through and worked with you on several issues.


Only discussions I've ever had with you in IRC were
4-Feb you asking for a change that isn't really possible (though I did implement what was possible)
13-Feb discussing casper/cow issues
23-Feb discussing the risks of using a one-man supplied OS


Yes, the impression I got from those conversations was that you were against the very idea of BAMT, and generally uninterested in changing cgminer to let it do all the things Phoenix could do with BAMT.


However I will also add, software is buggy, INCLUDING yours, and pretending you are some magical unicorn who doesn't write bugs but just blame someone else is mind numbingly stupid

I must have missed where I did anything like that.  If you read through the fix descriptions to find #20, surely you noticed all the places where I specifically talked about my own bugs.  I'll freely admit I jumped to a conclusion based on past experience, and this time it was not correct.  I apologized already, and I apologize again.  

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
...
You know what is strange though, I upgraded the stock cgminer to 2.5.0 some time ago and it has been very stable for me, (2) AMD GPU and (4) BFL on one rig. So is this issue just with 2.6.x versions I wonder?

Yes, that seems to be the case.   I have heard others say that 2.5.0 works OK for them as well.  All complaints are with 2.6 as far as I know.
Then go look at it rather than calling my API buggy and trying to blame cgminer.

I think your forum name is appropriate ...

LOL

Are you seriously saying that cgminer hasn't been insanely buggy on nearly every release?

Do you have any idea how much of my time is wasted on cgminer bugs?  Or how many past versions of cgminer have been unusable in a remotely controlled system because simply by using the API cgminer will hang or exit?

Case in point:  The problem we are seeing now with 2.6.0 is due to a dead cgminer function in BAMT.. a function that only exists because cgminer kept crashing for Gigavps!

Yeah and he paid you 50 BTC for a crap regex that you call fix '20'

Well since you have NEVER reported any details of one of these mystical API bugs that I apparently have written so many of ...

Try doing that for once ... or is that all just total bullshit?

Only discussions I've ever had with you in IRC were
4-Feb you asking for a change that isn't really possible (though I did implement what was possible)
13-Feb discussing casper/cow issues
23-Feb discussing the risks of using a one-man supplied OS

However I will also add, software is buggy, INCLUDING yours, and pretending you are some magical unicorn who doesn't write bugs but just blame someone else is mind numbingly stupid
hero member
Activity: 616
Merit: 506
Let me add that I do apologize for suggesting that cgminer was exiting due to API use.

You've got to understand that several times in the past this has been the case.  In fact the reason we quit putting out updates with new cgminer versions is that every time we did, all sorts of problems turned up.  When 2.3f or whatever it is we use seemed to be stable, we stuck with it and suddenly the number of "BAMT problems" drastically dropped.
  
This time it is not the case, but without any information on the problem, I just assumed it was the same type of problem we've had in the past.  I know it sucks to be blamed for a problem that isn't on your end, believe me.

hero member
Activity: 616
Merit: 506

Case in point:  The problem we are seeing now with 2.6.0 is due to a dead cgminer function in BAMT.. a function that only exists because cgminer kept crashing for Gigavps!

Thing is I proved it is NOT DEAD. You are killing it. I instrumented a clear call to the API telling it to quit and went into mother to find out why. You call /etc/init.d/mine restart inappropriately on a running cgminer.

I completely agree, that is the case with cgminer 2.6.0.  The function is only supposed to "restart" cgminer when cgminer has exited.  That function performs correctly with the included version of cgminer.  It does not work properly with 2.6.0

BAMT is not tested with 2.6.0, and does not support 2.6.0.  There may be additional problems as well, I could not guess.   We use the specific version of cgminer that BAMT provides because it has been tested and found stable in a large number of environments.  If you replace that with something else, all bets are off.  cgminer 2.5.0 seems to work fine, although that is based entirely on user feedback, I have not verified this myself.

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/

Case in point:  The problem we are seeing now with 2.6.0 is due to a dead cgminer function in BAMT.. a function that only exists because cgminer kept crashing for Gigavps!

Thing is I proved it is NOT DEAD. You are killing it. I instrumented a clear call to the API telling it to quit and went into mother to find out why. You call /etc/init.d/mine restart inappropriately on a running cgminer.

edit: Note I am NOT claiming bamt 0.4/0.5 was ever intended to run on 2.6.x cgminer, but it is not a failing cgminer issue.
hero member
Activity: 616
Merit: 506
...
You know what is strange though, I upgraded the stock cgminer to 2.5.0 some time ago and it has been very stable for me, (2) AMD GPU and (4) BFL on one rig. So is this issue just with 2.6.x versions I wonder?

Yes, that seems to be the case.   I have heard others say that 2.5.0 works OK for them as well.  All complaints are with 2.6 as far as I know.
Then go look at it rather than calling my API buggy and trying to blame cgminer.

I think your forum name is appropriate ...

LOL

Are you seriously saying that cgminer hasn't been insanely buggy on nearly every release?

Do you have any idea how much of my time is wasted on cgminer bugs?  Or how many past versions of cgminer have been unusable in a remotely controlled system because simply by using the API cgminer will hang or exit?

Case in point:  The problem we are seeing now with 2.6.0 is due to a dead cgminer function in BAMT.. a function that only exists because cgminer kept crashing for Gigavps!
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
...
You know what is strange though, I upgraded the stock cgminer to 2.5.0 some time ago and it has been very stable for me, (2) AMD GPU and (4) BFL on one rig. So is this issue just with 2.6.x versions I wonder?

Yes, that seems to be the case.   I have heard others say that 2.5.0 works OK for them as well.  All complaints are with 2.6 as far as I know.
Then go look at it rather than calling my API buggy and trying to blame cgminer.

I think your forum name is appropriate ...
hero member
Activity: 616
Merit: 506
Well after a few hours of messing around with this, I had to shoehorn shit all over the place to make it mine on a machine that did NOT have an AMD card which BAMT seems not to work with...

Anyway I instrumented the newer cgminer restart problem in bamt and it is indeed in the /opt/bamt/mother monitoring file. The perl parsing of ps axu output fails to detect cgminer is there and it then calls /etc/init.d/mine restart . So it is in fact bamt that is restarting cgminer, and if I edit the mother script to parse the output of ps axu differently, it does NOT continually restart cgminer. Alas I don't really know perl, but it does seem to need fixing.

If you copy this file on top of mother in /opt/bamt it shouldn't restart on you (note this is not the correct fix and will probably not restart cgminer should it actually really crash):
http://ck.kolivas.org/apps/cgminer/temp/mother


BAMT is only for AMD gpu mining.  It is not designed to work without one.

If you use the cgminer included in BAMT, you'll not have this problem.  Newer versions of cgminer are not supported at this time.  If we release an update, we will adjust mother to work with the updated version.
I was responding to the numerous requests from people as to why bamt keeps restarting the newer versions. We know you only support older versions but that doesn't mean that everyone out there will want to stick to them. I instrumented it because cgminer kept getting blamed, and I had no care about the AMD aspect; I was just explaining why it was hard to test it on hardware I had available to try it on (all of which have nvidia GPUs).

You know what is strange though, I upgraded the stock cgminer to 2.5.0 some time ago and it has been very stable for me, (2) AMD GPU and (4) BFL on one rig. So is this issue just with 2.6.x versions I wonder?

Yes, that seems to be the case.   I have heard others say that 2.5.0 works OK for them as well.  All complaints are with 2.6 as far as I know.


hero member
Activity: 626
Merit: 500
Mining since May 2011.
Well after a few hours of messing around with this, I had to shoehorn shit all over the place to make it mine on a machine that did NOT have an AMD card which BAMT seems not to work with...

Anyway I instrumented the newer cgminer restart problem in bamt and it is indeed in the /opt/bamt/mother monitoring file. The perl parsing of ps axu output fails to detect cgminer is there and it then calls /etc/init.d/mine restart . So it is in fact bamt that is restarting cgminer, and if I edit the mother script to parse the output of ps axu differently, it does NOT continually restart cgminer. Alas I don't really know perl, but it does seem to need fixing.

If you copy this file on top of mother in /opt/bamt it shouldn't restart on you (note this is not the correct fix and will probably not restart cgminer should it actually really crash):
http://ck.kolivas.org/apps/cgminer/temp/mother


BAMT is only for AMD gpu mining.  It is not designed to work without one.

If you use the cgminer included in BAMT, you'll not have this problem.  Newer versions of cgminer are not supported at this time.  If we release an update, we will adjust mother to work with the updated version.
I was responding to the numerous requests from people as to why bamt keeps restarting the newer versions. We know you only support older versions but that doesn't mean that everyone out there will want to stick to them. I instrumented it because cgminer kept getting blamed, and I had no care about the AMD aspect; I was just explaining why it was hard to test it on hardware I had available to try it on (all of which have nvidia GPUs).

You know what is strange though, I upgraded the stock cgminer to 2.5.0 some time ago and it has been very stable for me, (2) AMD GPU and (4) BFL on one rig. So is this issue just with 2.6.x versions I wonder?
Pages:
Jump to: