so i just re-installed windows fresh the other day and am getting everything reset up. guiminer, radeon 6870 dedicated miner (a secondary card) that's worked fine as long as i've had it. now, when i turn off the tv screen i use as a monitor (it's an hdmi connection) about ten minutes or so later it seemingly stops mining. fan speed drops, no more submitted shares, guiminer console only reporting new long polls, but still showing a nonchanging hash rate. once i click stop/start, it gets going again, no problems.

i have a screensaver that comes on after 5 minutes idle, but all sleep and hibernate settings are off. using latest drivers. been trying to fix this for a day and a half now, and i'm out of settings to check. does anyone have any ideas?

You could do it with cgminer and setup as a rotate after x minutes or load balance

see https://bitcointalk.org/index.php?topic=28402.0

use 10 pools

50btc
deepbit
deepbit
deepbit
eclipse
eclipse
eclipse
eclipse
eclipse
bitparking

that's the simplest way to go.

With a low hash rate GPU your not as likely to get many shares in a short round.  With PPS you get a flat rate for every share.  But with DGM it tends to come out OK over time so as long as you mine consistently for a long period of time that should work out well too.

Sounds like you made your choice of payout method.
Have fun,
Sam

Well I am not a small time miner.. well with the new diff yeah i guess i am.. hahaha

honestly i haven't upgraded anything yet.. no pre orders in place.. show me the hardware before i lay down the money.

Will i be left behind in mining? Probably.. so will many others.. I will just buy and sell Bitcoin.. i seem to make more that way anyways..

Check if the hash rate on the pool side fluctuates.  If it stays the same over 1 week period, I would not worry about what cgminer is reporting.

Will give it a try, was an obvious oversight on my end -.- however, if it works, it works.. Will report back shortly!

At that low of a has rate I would recommend using PPS.

HttpTransport.py:getwork() or StratumTransport.py:queue_message


BitcoinMiner.py:mining_thread(), coinbase can be modified only on Stratum, it is StratumTransport.py:increment_nonce()


BitcoinMiner.py:diff1_found() or Servers.py:send()


Servers.py:send() or HttpTransport.py:send_internal() or StratumTransport.py:send_internal()

The generation (block reward) tx has a single input.  Normally the input of any tx is the unspent output of a prior tx however generated coins are produced from "thin air".  The input is a special type of tx called the coinbase.   The Bitcoin network doesn't use the value in here for anything (although it is now used by subordinate chain in merged mining).   Miners can modify this to produce more possible block headers for the same set of inputs.

So say for a given set of transactions, time, prior block, and difficulty you try all nonces 0 to 2^32-1.  What can you hash next if you don't want to wait for any of the other values to change.  You simply change the value in the coinbase field to another value.  That will produce a new merkle tree and thus a new markle root hash.  Technically it doesn't need to be incremented any new value is fine but for simplicity and record keeping (pools) it makes sense to just increment the value.   Pools do this to issue work to multiple workers that are otherwise the same.   solo miners will need to increment this if they have a hashing rate greater than ~4GH/s.

Hmm.  Never thought about that angle before.  I mean for 99% of programmers all these endian conversions just make the code more confusion to understand however for some programmers it might be second nature.

Then again there are a lot of other "quirks" which are equally hard to explain.

Why use 32 bit nonce + extra nonce?  Why not just use a 64 bit nonce?

Why a double SHA-256?  If the fear was that SHA-256 would be partially compromised one would gain some security by using two algorithms but you don't really gain much performing the same algorithm twice.