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.

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


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).

    

I like to use a hammer to drive a nail. 
Sounds like you like using a pliers to drive the nail.
Use the right tool for the job.

I completely agree, it would be great if BAMT was able to evolve with the ever increasing popularity of FPGA's. I think mgpumon is the best feature of BAMT and in the present state it can work great to monitor FPGA's.  As you can see by taking a look at gigavps url, it sure is cool to see all the BFL's on a single host monitored through cgminer and contributing to the GPU farm.  The UI of mgpumon certainly looks much more polished over other solutions that's for sure. I doubt that would be easy to pull off in standard Linux to monitor the FPGA's with a UI. It seems to at least play nice with them currently via cgminer.

I also see what Inaba is going for with a GPU-less rig. I can envision the new AMD Trinity APU soon to be released with a built in Radeon 7660 would meet the need to not need a standard graphics card and be very efficient while kicking a few hashes in.  When you combine that with an 80+ Gold PSU, FPGA's, and custom cables to power them from the PSU it sounds like the perfect combination to make a very efficient "next generation rig".

If you guys are having problems with BAMT stopping mining after awhile due to network disconnect, try my fix:

http://www.bitcointrading.com/forum/index.php?topic=416.msg1235#msg1235

" ATI drivers, the SDK, the openCL libraries, atitweak, amdoverdrivectl, phoenix and cgminer"

hmmm...  which of these are useful if you are not using GPUS... 

not ATI drivers
not the SDK
not the openCL libs
not atitweak
not amdoverdrivectl
not phoenix

I'm going to assume you know that, and are just being silly.

we need a tarball with any necessary files and an optional bash script with any commands that need to run before or after the tarball is unpacked.

It's much easier just to assign it a static and non-expiring IP from the router.

is there any rhyme or reason to which machines have this issue and which don't?  I would like to resolve it but like everything else its nearly impossible to address with no way to recreate it here.  I rotated several different nics in my test rig but none exhibit this issue.

it would be preferable to recreate the problem locally... using remote access to troubleshoot a problem that is essentially the loss of networking doesn't sound like a lot of fun for hopefully obvious reasons.
can you tell me some details of a system that doesnt work correctly?  Nic and/or motherboard seem like the most likely factors.