The efficiency on my system has gone from about 88% to 98%... I only have a ATI 6870 though, no FPGA here

[EDIT]
Now up to 172% efficiency

Every once in a while something weird happens with the new server version causing some requests to get processed very slowly. This was causing rejects above 1% for many users.

I have reverted back to the old server version to ensure trouble-free mining. I will work on fixing this and rollntime will be back soon.

Sorry for the inconvenience.

ill be shutting my gpu's down sometime this week, after i get one more Jalapeno ordered.  it will be nice to get a small power bill again    i think ill leave one rig running and set the donation to 100% though or the good Dr could set up another worker and ill let it mine for him 

Thanks - much appreciated

You can just set 100% donation and leave the last one mining. Remember to change the setting when the Jalapenos arrive.  Alternatively the test account used by the test edition of the BitMinter client (http://bitminter.com/test) will donate everything to the pool. Username Test, workername Test, password Test (note the capital letter everywhere).


Happy to hear this works better for you. Fefox requested this feature because of the issue you describe. Not sure why it would be so messy starting all devices at the same time. But as long as this works better...

Also note that automatic rescanning for FPGAs is back in the options. This in combination with automatically starting devices when they connect (also in options) will help keep things running smoothly even if a device should drop off and come back.

Quick question: I just changed the name/pass of my workers (deleted and created new), how much time does the server need to actually recognize my new miners?
CGMiner 2.7.5 is saying:
My start cmd is the exact same as before.

tcping is not helping much:
Am I alone to have this problem?

Edit: There's definitely a problem. I just tried with -u Test -p Test, either with CGMiner 2.6.6 or 2.7.5 on port 80, it still doesn't work.
Edit2: With the Java BitMinter client there's no problem, but I lose 100 MH/s by mining with it ;(

Until I deleted and created the new workers this worked fine:
I don't get it.

Edit3: The port 8332 doesn't work either through Tor (Deepbit works).
Edit4: BFGMiner doesn't work either.

Fixed: <username>_<workername> is the login not just <workername>

Could someone create a new worker, test it if it works on their side, then give me the user/pass of the worker?
So I can see if the problem comes from the server or from me.

In getblocktemplate, pretty much all the pool does is count shares - the miner must handle all the txn decisions, txn orphans, block changes (and orphans as well) i.e. pretty much implement a large portion of the txn handling that the pool (or bitcoind) does for you.
As a result of this, your bitcoin network connection will also affect your mining.
At the moment a pool's job is to ensure that it has enough connectivity and performance to handle the miners.
With getblocktemplate, it becomes the miner's problem.
(which is also why I've said that any implementation of getblocktemplate in a miner should also put a fee paid to the miner in the coinbase txn)

Stratum, on the other hand, restricts you to interacting with the pools in a similar manner to how you do already, but you have a somewhat unlimited amount of work per getwork from the pool.
You produce the coinbase transaction also thus you can change the coinbase and thus roll a 'secondary-nonce' and not have to roll the time.
Also, the rolling is of course unlimited since the coinbase field in the coinbase transaction can contain anything you like.
Thus it supports larger hashing power.
The aim is not to hash forever and never talk to the pool, but rather provide each miner work that they can use for a period of time independent of their hashing power.

As I keep saying in other threads, this is all caused by the fact that the block header nonce is only 32bits - the good old MSDOS problem where the design was too small - and to fix it properly requires a hard fork to increase it's size (that the bitcoin devs are afraid to do)

20h left before 3xxxxxx difficulty...

Next Difficulty
in 188 blocks
2,913,501

give or take