It's the actual hashing process which I can't find very much about. I'm surprised there isn't a good page on the wiki.

Yeah my betting thread has got lost in all the Russian pyramids.

Are you on SDK 2.1 or 2.4? If you're on 2.1 modify back to poclbm kernel instead of phatk.

I'll fix .screenrc for the next release, thanks.

This is a question I get asked relatively often, so I'm going to explain it here and hopefully this can be a useful reference to help people understand two things:

1. Why other people pool hopping is a problem for you (a 24/7 single pool miner).
2. Why proportional pools, not pool hoppers, are the fundamental issue.

First of all, we're going to assume that there is a proportional pool called Pool A, which mines at 90GH/sec without our miner.

Now, we have a miner, let's call him Bob, he runs a 10GH mining operation and he's trying to work out why hopping is an issue. To do this, we're going to make the numbers easy to work with. One block's regular length will be defined as 10 difficulty, which under normal circumstances (zero hopping) will equate to 10 units of time.

So, if Bob statically mines on Pool A, and nobody else is hopping, he should make approximately 5BTC (10% of 50BTC, as he's 10% of the hash rate) every 10 units of time.

0.5 BTC per time unit is Bob's expected yield.

Now let's see what happens to Bob if 50% of the pool hops after 5 time units (this is circa optimal). This means the pool will do the first half of the block at 100GH/sec, and the second half at 50GH/sec. In this scenario, Bob will be 10% of the pool for half of an average block, and 20% of it for the other half.

This means that in the first half he will earn 2.5 BTC, and in the second half, he will earn 5 BTC (20% of 25 BTC). On an average-length block, we can see that Bob is not negatively affected by hopping as the block will take 15 units of time, but he will get 7.5 BTC, still 5 BTC every 10 units.

From here, it's hard to see where the issue with hopping is, but we have to explore different length blocks to better understand the issue. Let's say, as happens in real mining, that instead of all 10 difficulty-unit blocks, we have a 5 unit block, and then a 15 unit block.

Without hopping, Bob will be 10% of the pool for 20 time units, and will make 10 BTC, or 0.5 BTC per time unit.

With hopping, Bob will earn 5 BTC from the 5 difficulty block, as the hoppers won't hop and he'll keep being 10% of the pool for the whole thing, this will be 1 BTC per time unit.

From the second block, he will earn 1.66 BTC from the first third of the block (1/3 of his 5 BTC for the block), and then 3.33 BTC for each of the second difficulty-thirds of the block. This totals out at 8.33 BTC, but this block will have taken 25 units of time to complete.

In case you didn't follow the maths.

First third - 5 difficulty - 100 GH - 1 diff:1 unit time - 5 units time
Second third (after 5 time units) - 5 difficulty - 50 GH - 1 diff:2 unit time - 10 units time
Third third - 5 difficulty - 50GH - 1 diff:2 unit time - 10 units time

This means that he's made 13.33 BTC in a total of 30 units of time for the short block and the long block, which is significantly lower than his expected BTC/time unit yield.

This return is only 0.44 BTC per time unit. This is 12% lower than he'd normally get!

On a longer block, it's even worse returns than this, and deviates even further from his expected yield, but a shorter block doesn't make up for it as the hoppers won't hop on those. Doing the maths for a 25 difficulty block, a 2 difficulty block and a 3 difficulty block, Bob would make 19 BTC in a staggering 50 units of time, which would be more than 20% below his expected 25 BTC.

If there was no hopping, these 3 blocks would have earned him 15 BTC in 30 units of time.

Obviously this is based on a huge proportion (50% of the MH/sec) jumping, which isn't likely right now, but the number of people using hopping techniques is only going to rise, and any loss due to this should be unacceptable to a miner.

But don't complain at other people for screwing you because they're pool hopping. You facilitate them doing it, it's their right to do it, you're screwing yourself. If you offered someone $10 an hour for a 5 hour shift or $7 an hour for a 10 hour shift, they'd take the 5 hour shift. This is what the hoppers are doing by maximising their own returns.

The answer is better pools, not calling people out for doing something they have a right to do.

tl;dr: By using a proportional pool 24/7, you may as well be paying a significant (up to 12%) fee.

Still taking bets.

0.05 per MH/sec? That's very expensive.

Ctrl-A then release and press the number.

Ctrl-A then number should work flawlessly. :/

You have to press Ctrl-A every time you want to press a number.

Try ctrl-a, then the screen number (will be 0,1,2,3 etc).

The next release will really help you as it has a dedicated Phoenix diagnostic tool, but Dropbox is being a nightmare.

try sudo screen -x amm -p 0

I'm not an expert on sudo but I think it would attach the screen to root's session so you might have to be root to use it.

Do screen -ls

Oh, that's an issue with screen, I get the same sometimes when on my 3 GPU machine, the only fix I've found is restarting startmining.sh but it's in my bugs to fix list.

Should do after some failed attempts.

Can you show me what it looks like when it doesn't show all GPUs? Is it because your xterm is too small?

If so, try stopmining.sh, then change common.lib and set autoOpenXterm=0, then startmining.sh, then open a terminal, make it big and do screen -x amm -p 0.

Have you successfully connected via ssh, or are you in a local terminal?

Try doing 'screen -x amm -p 0' on your local machine (the one running the miner), as that's the exact command that's being run on the terminal which you say works by this code:

# Load Xterm if not running headless
if [ "$autoOpenXterm" -eq "1" ]; then
        xterm -T "Autominer" -e screen -x amm -p 0 &
fi

As long as this works, your ssh is probably not connected.

If by the information row you mean where it shows the hashes on my screenshot, you have to enable xmlRPC to make that work. See first post for details.

I'd sorely like to, but I don't have anywhere to ftp dump it to right now. Check back in 30 mins or so and Dropbox should be back up (they're migrating to another datacentre).

Re: stopmining.sh not killing, try running the following:

killall screen
killall phoenix.py

It could be that when you changed a card identifier, it lost one or something. Usually it kills everything.

On ssh, you should get the exact same screen, when you do 'screen -x amm -p 0'. The screenshot in the first post (which is down thanks to Dropbox) was taken in ssh.

I can't take Moneybookers for payment, I don't like to take anything with chargebacks because they offer no protection to sellers with huge upfront costs, and tend to look badly on Bitcoin in general.

As for a 'supporting role', these contracts run 24/7 over 13 weeks on the pool and username/password of your choice, so they can support your existing mining capabilities. They can't work only part-time, however, they are full-time miners.

Your PC looks like a nice spec, I've got something similar on my gaming machine but with a bit more RAM and a bit less Windows.

Your GPU load is 0 apparently.

Can you grab the latest version and run the new checkphoenix.sh script?

Edit: Issue with Dropbox's server right now apparently. Joy.

Edit2: Apparently they're migrating data and should be about 1 hour of downtime. This is where I really need a mirror.

Can you try Phoenix with the following options from the command line? (you need to be in phoenix dir)

./phoenix.py -q 1 -v  -u http://CYPER_GPU1:password@nl.btcguild.com:8332 -k phatk PLATFORM=0 DEVICE=1 WORKSIZE=256 AGGRESSION=11 BFI_INT FASTLOOP=false VECTORS

If this works, double check your phoenix directory (in common.lib) is correct, as that's the exact command the script is sending.

Try changing it to 1 and retry. That bit was an issue with the code which I will fix now and upload a new version, thanks.

Edit: Fixed in 0.3.2.4.

Running stopmining.sh is the only way to get them to stop, this is by design intent, because it means if you're remote monitoring and your ssh session dies, your miners keep working.

You might find it easier to control it with screen. Just install sshd on Ubuntu, then download Putty on Windows and open a terminal session. Type:

ssh username@ipaddressofminer

Once you're logged in, you can just do screen -x amm -p 0 to open up your screen session.

The reason why I say this is because Phoenix really reduces your computer's graphical responsiveness, and this can make it very slow over VNC. However, if you want to use VNC, you probably want Xterm to keep opening. It won't prevent you working headlessly if xterm does open, but it makes the screens look a bit uglier (they're restricted to the size of your xterm in terms of amount of space they can take up).

If you want to donate, feel free to test donateMode. It gives me 0.5% of your mining capability.

On the device, if Phoenix sees your GPUs as 1/2/3/4 you should choose 1/2/3/4. My phoenix sees my CPU as 3, GPUs as 0/1/2.