I went over from BTCGuild to Coinlabs a few days ago (last Thursday I think?) and since then my miners have been sputtering like crazy. My hashrate graph (I'm running BAMT) has turned from a Rothko to a Pollock. And I don't care what your taste in art is, that's just not on. Back to BTCGuild until Coinlabs gets a bit stabler. Great idea, dodgy execution at the moment.

Heh, yes I just did a split second before you posted. It appears it didn't work with port 50000. I changed that to port 50001 because that's what the other three servers say (I don't really understand what I'm talking about in case it isn't obvious) and it started working!

Should I change it back to 50000 or leave it at 50001?

Also the transactions in my history, my receiving addresses, and my contact addresses, don't have the labels I gave them in my Windows client. I presume it's just a matter of copying over some configuration file?

Hi Peeps, I'm having problems. The Windows version has been running fine so far so I thought I'd install Electrum on my Ubuntu Linux system too, and it's got a problem. I was given the choice to generate a new wallet or type in an existing seed. I chose the latter so I could type in the seed I generated with the Windows version. But it has been unable to create the wallet, and it seems to be because the client isn't connecting to any servers.

So could somebody tell me why the client isn't connecting to servers? The internet connection here is fine (I'm posting after all!). My client has the standard list of four servers. Oddly, I have a pair of radio buttons that notionally allow me to choose between the tcp and http protocols, but they're stuck on tcp, I cannot select http. Could this be anything to do with the main problem?

Nuh-uh. In another thread I was advised to replace network-manager with wicd.

I did.

My rigs just hate me.

Well, bollocks. 

Okay, as and when each rig next screws up, I will revert their gpus back to 725 engine and 1.05 voltage. But can I at least keep memclock at 300? Because the stock 1000 really is a stupid setting for a miner.

Thanks pehoko for recommending testing the USB sticks. That's certainly another avenue of pain.

In unrelated news, one of my other, better-behaved rigs has been down seven hours (why so long? Because I was ASLEEP, a state we humans often need to be in when the big light in the sky goes away) because all of a sudden it just COULDN'T DETECT ANY NETWORKS ANYMORE. Soon I'm just going to take these rigs to the vet and ask her to put them down humanely.

(ETA and my first draft of this post got bollixed because my router conked out. Not my old crappy router, the shiny new wireless-N one I got to replace it LAST WEEK, the one that cost 60 quid. I swear my whole house is just one big fucking Ancient Indian Burial Ground.)

Given the frequent and varied nature of the problems my rigs have been having, I'd be happy to accept 'overclocking' as the issue, but I sure hope it's not that, because for the vast majority of the time I have been UNDERclocking and UNDERvolting my cards. At one point I even had them running 600 engine, 200 memory, and full 1.05V, and they still kept screwing up. And GPU temps have generally been kept below 75C, only occasionally creeped to 82.

Now I'm running them at 800/300/1.05, and they're not locking up any *more* than they were on much lower speeds. It's incredibly frustrating.

However, I shall trying reflashing the USB stick (which is also something I've done two or three times for each rig already!). It's actually just one rig that's being a pain the last few days so maybe that'll do it, the other two seem to be behaving better.

My latest problem with BAMT - a rig doesn't mine, I can't putty in, and when I bring up a local terminal and try atitweak -s, it tells me about an 'invalid MIT-MAGIC-COOKIE'.

Having waded through pages of forum posts, a temporary fix seems to be to delete ~user/.Xauthority and ~root/.Xauthority and then reboot. But I have to keep going in manually to do this, and it only works til the next hangup maybe half a day later.

Could somebody check my understanding of this? I *think* that it basically only happens when I have to power off the system at the switch... then the problem appears when I boot it up again. But it doesn't ALWAYS seem to happen. And it doesn't happen if the system was mining successfully and I power it down the way it should be done, with a shutdown or coldreboot command.

I read the following from lodcrappo responding to another guy whose problem also seemed to lie with Xauthority somehow:


Okay I think I understand all that. And I suppose what might be happening is that 'step 7 happens before step 5'. BUT, a quick perusal of the start_mining script suggests that this *cannot* happen, as mine_start won't run 'xauth +' until it sees the X server is running.

Also, why the difference in behaviour between the two different ways of rebooting?

Basically how I do stop this shit happening all the time? Or at least shove some extra perl in to detect it and do something clever?

Thanks for the clarification lodcrappo! I look forward to downloading the 5xxx version of BAMT 0.6 when it becomes available.

I'd planned to hold off donating until these rigs had started turning a profit... unfortunately that's unlikely to ever happen now, more of a loss-minimising thing going on until those damn ASICs start flooding the network. So have 3 BTC, courtesy of 1Fhowu3xdhe8w6CaozK81TwUpyVe2Swnov.

Just to be pedantic, could you clarify what I hope is the case, namely that there won't be a performance penalty in the new release if you ONLY mine with 5xxx cards (i.e. do NOT mix them with 7xxx cards on the same rig)?

Okay, without the ever increasing string of implied and explicit negators:

Will my all-5xxx rigs mine just as well with 0.6 as with 0.5?

Well, there's not much point at the moment, because, as it turns out, it does sweet fuck all. 
But the basic idea is: every minute BAMT runs a perl script called 'mother' which is in /opt/bamt. It does various housekeeping and monitoring things, one after the another, and depending on which flags have been set in /etc/bamt/bamt.conf. My idea was just to insert those few lines you see at a suitable break in the proceedings... quite early on in the script really. But to add insult to injury, the last couple of dropped connections have involved the system retaining my router's essid, but not finding its MAC address (so my code thought everything was just peachy). It was easy enough to change my script snippet to check for that instead. But then a few moments later, the rig stopped finding ANY WIRELESS NETWORKS AT ALL.

What I'm going to do instead is work out as much as I possibly can about how to set up and configure a wireless interface using the various binaries in the wireless-tools package. This includes all those commands like iwconfig, iwlist and so on. Then I'm going to take lodcrappo's advice to nuke network-manager from orbit. Then I'll look into the networking script, twiddle that as I need to, then go back to 'mother' and try to write a bombproof way to check how the connection is doing and repair it however I can think of.

THEN, once everything is absolutely perfect as regards my wireless connections, I can start looking at the OTHER half-dozen or so ways in which my rigs screw up on a pretty much daily basis. Do you know, my mobo's cost about £150 each, and they *usually* find my USB sticks on bootup? USUALLY! Fuckers.

I added this bit of perl to mother, obviously change your router's essid as appropriate. So far it has not come up, hope it works when the time comes.

Well, AmDD, it looks like we're on our own with this one! 

Made some progress... one of my rigs had conked out for a couple of hours just now, and plugging the monitor in I can see iwconfig doesn't show the ssid, usual scenario. Notably, iwscan *did* show the ssid. Restarting the networking scripts seemed to fix it, i.e. running the commands

/etc/init.d/networking restart
/etc/init.d/network-manager restart

Running iwconfig straight away didn't show the ssid, but leaving it half a minute or so after running these did. I also examined /var/log/syslog and it showed a flurry of messages around the disconnection time which I'm going to look at in more detail.

Of course none of this helps to make a 24/7 miner, but what I'll try to do is either

a) understand the message flurry and see if there's some bug I can fix, or
b) add an extra bit of perl to mother to note when this flurry occurs, and restart the network scripts.

Will update this thread if I get anywhere with those.

I have 3 rigs running BAMT, each with a wireless NIC, and one wireless ADSL modem/router combo to feed them all data and waste my life on my laptop. These rigs have been a real pain since I set them up, it's a lucky day when none of them need a manual reset. There seem to be a number of different faults coming up, but here I'd like to focus on two.

When a rig boots up and starts mining, all is (usually) well. The rig sees my router and communicates with it. When I type iwconfig, it shows the router's essid.

Then, a few hours later, my pool shows me the rig hasn't submitted a share for half an hour or whatever. I can't ssh into it from my laptop, nor see things on the web status thing. So I go downstairs and plug a monitor in, bring up a terminal, iwconfig, and... now there's no bloody essid! What happened? This kind of thing only happens to one rig at a time.

The second problem affects all of them. The router drops its connection, for whatever reason. So I reboot it. The connection is reestablished. At least as far as my laptop is concerned. But the miners do not resume mining. Why not? Why can they not see that we're back online and they need to get back to work?

All help gratefully received!

You're doing roughly the right things. Well actually, GPU mining is probably going to go dodo in the next few months, but given that, you're doing okay. But specifically:

1) 182 MH/s: That seems a bit pathetic for a 7xxx Radeon. But it's one of the two entries in the usual guide (did you do that?), and the other is even lower, so maybe it's okay? Just seems a bit crap that's all.

2) Pool. Not solo. Solo has not been a good idea for 99% of miners for at least a year now. I think if you could get around 50 GH/s, at current difficulty, that might make it worthwhile. So only 300 more cards to go!

3) Don't know why guiminer can't see bitcoin-qt, but since you won't be solo mining, who cares?

4) [0-0] Capeverde is indeed your GPU, not CPU.

5) Mining shouldn't wear out any of your components except your GPU, and as long as you keep your GPU reasonably cool, it'll be fine for a few years. Go find some tools to check your GPU temperatures, and better still, your VRM temperatures if you can. The GPU should really stay below 75ish, the VRM will get hotter but below 95 should be okay. I presume you are using Windows? That's fine, except I've forgotten all about what tools you can get in Windows. If your card is too hot you'll need to turn up the fan, or reduce the engine clock. You may also be able to reduce the voltage - experiment a bit on that, you won't hurt the card. Also check your GPU's memory clock. Stock mem speeds for GPUs tend to be in the 1000MHz area, and miners have long known you can (and should) lower that, at least to 300MHz or so. It won't reduce your hash rate and will save power and cool things down.

Yes, I'm an Ukian and I've been mining since I first heard about Bitcoin back in October 2011. Profit? Ahahaha, that's a different matter.

As far as the daily bitcoin revenue vs daily electricity costs go, that's not a problem. My trusty spreadsheet tells me I can bring in up to £14.68 per day (current exchange rates) at an electricity cost up to £6.41 per day, leaving me a nice healthy £8.27 per day better off. Sounds like a nice little earner, right? Well there's three big buts:

1) It's a lucky, lucky day when I can get all three of my rigs mining a whole 24 hours without fucking up and having to be manually reset for some reason. And it's always a different reason too. Temperamental bastards.

2) How much did I have to lay out on hardware costs to set this up? I decline to say, other than 'far too much'. But even if there weren't a block reward halving coming up, and even if ASICs don't materialise for another year, I won't break even for about another year. WITH the halving and the ASICs... well I'm clearly never going to break even, I'm now just mining while I can still recover some of my loss.

3) All this wouldn't be an issue if I was a productive member of society in full-time employment. But I'm actually a lazy slob living on rapidly dwindling savings, rapidly expanding credit card balances, and a teensy bit of income from private tutoring. Guess how much private tutoring kids want in August?

It pretty much has been solved, with lightweight clients like Electrum.

I voted no. From what I've read so far, I think they're either pulling a massive scam, or if they're sincere, they're

a) way too optimistic with their timeframe... no ASICs before the new year at least, and
b) pulling the specs out of their arse... sure, ASICs would improve on FPGAs and do great damage to the GPU and FPGA miner diehards, but their quoted speeds and powers are bullshit.

That said, I fear wishful thinking on my part. I've sunk a whole load of money into a GPU farm since first hearing about bitcoin in October last year, and it's going to take a heck of a long time to recover my costs even if ASICs don't materialise (partly my rigs being continually uncooperative, partly poor buying decisions). If they do I can pack this all in. So I'd definitely much prefer that they're pie-in-the-sky and/or scammers, so I can continue to recover costs and feel smug about all those eedjits who jumped on the bandwagon.

Also I don't know if you can change the form of a poll once you've posted it, but
a) Your poll says we can only choose up to two options. Herp derp and so on.
b) You say the poll closes Nov 2. It would make more sense to close it some time before the Oct 31 deadline. How about either 30 Sept, or sometime mid-October?

Hello, just downloaded and am trying out the Windows GUI version. It looks nice and clean, and easy to use so far... but I've run into a problem - kinda my fault but still. [never mind, it cleared itself up]

Thanks to all concerned!

I use phoenix with a phatk2 kernel. I can't really help you with any of your settings, as I use BAMT, and you use... well whatever you're using I've no idea what it can and can't do, or how to work it.

Having said all that it looks like you actually found the most important performance booster anyway...


I'm not sure what version of the phatk kernel I'm using... as I say I use BAMT which is basically a ready-to-go system on a USB stick. Having said that, the author of BAMT knows what he's doing, and setting all my cards to 800/200 gets each core 359 MH/s so I presume I have the 'best' kernel version.


A linux utility called atitweak, included as part of BAMT (though you can install it easy enough on any linux distro). It's sounding more and more like you use Windows.


My three rigs are dedicated - if I wanted to play the latest GPU intensive game (my tastes run more to very old strategy games/god-sims) I'd be doing that on a separate machine. Re crossfire, I have heard of this, and all my 5970s came with a widget for it, but I have never used it. It seems to be disabled by default on my systems, and if there were ever any need to ENable it, I wouldn't have a clue what to do.


Guess so, been a while since I used GUIMiner. 

That all looks about 'right', by which I mean, 'pretty much the same setup and results I have on my three rigs with three 5970s each'.

That said I can think of three little tweaks which should get you another 10-15 MH/s per GPU

1) Set aggression to 11 not 10. (Insert joke about Spinal Tap here)

2) You *might* find that lowering the memory clock from 300 MHz to around 220 MHz actually speeds things up a little

3) Depending on how old and battered your card is, you could probably bump the engine clock up to 805 or 810 MHz without locking it up.