What is a "magnitude rig"?


Now I finally know what load balance means and understand why I never got balanced shares across pools/servers.  Thanks for the clarification.


What exactly is "rolltime"?

Thanks,
Sam

Still getting intensity pegging down to -10 on dynamic threads on win 7 x64.  At the same time, when it drops to -10, cgminer starts eating up a whole core of CPU power.  

This change happened sometime after 2.6.1.  Probably related to to the change in how cgminer handles dynamic intensity that was in 2.6.5, not 100% sure though since my update path was 2.6.1, 2.6.5, 2.7.0.  First saw it in 2.6.5.  Does not happen in 2.6.1.

Any GPU set to dynamic intensity will eventually peg to -10.  Sometimes very shortly after starting, sometimes after running for a while.  I have not yet been able to figure out what the trigger is.

Tested with a clean copy of 2.7.0 with no prefs file after a cold system reboot.

First time I've upgraded since 2.5.4 I think.

Everything is working as advertised.

Three things I noticed that I thought I'd mention:

- On both my miners, one with 4 GPUs, and one with 3, initially on startup the highest number one (lowest on the list) shows a massive amount of work done compared to the others, like 10x as much.  They eventually balance out, but on startup it is unbalanced.

- Failover is working much better.  I run two copies of p2pool on two different machines for backup purposes.  The backup would almost always get a very small amount of work from the miners.  Now the backup is getting zero, like its supposed to.

- Just for fun I tried changing the intensity to dynamic.  I normally run it at 8 for my 7970s.  Every GPU I tried it on, cgminer would change it to 7 and it wouldn't move from there.  Wouldn't say D, it would say 7.  I ended up changing them all to 9, which before caused problems, but now it works and increases output.  10 just jacks up CPU usage with no perceptible increase in hash rate.

As usual, great work.  I just send 2 long over due coins your way..

Regards,

M.

The nonce size in bitcoin is too small - it is 32bits (sorta like MS-DOS saying 640K will always be big enough)
Each piece of work you get from a pool allows you to attempt 2^32 (~4 billion) hashes - i.e. one for each nonce value.

For a single MiniRig, this means that you need to get over 350 pieces of work from the pool per minute.

The hack solution to this, that someone come up with in the past, was to instead edit the time field (roll it forward)
Thus if you add 1 second to the time field, you can then do another 4 billion hashes on the same piece of work you got from the pool (without having to ask for and wait for more work from the pool) since you are now hashing something different.

Thus most pools now support this.
If they don't - get a new pool.

It means you get less work from the pool to do the same amount of hashing.
The E: % value will tell you how much less.
e.g. if you have an E: of 200% that means you are rolling each piece of work you get, on average, once
Thus you are getting half as much work from the pool to do the same amount of hashing.

If a pool doesn't support roll-n-time then perfect "no rolling" E: is 100%

It doesn't reduce the number of shares you have to send back to the pool however.
The pool would have to support high difficulty shares to reduce that also.
But it does reduce the amount of work you request from the pool.

You can add up to 7200 seconds to the time field and bitcoind will still accept it as a valid block solution if you find a block
... thus why the timestamps in the bitcoin blockchain are not to be taken too seriously.

A larger nonce range in bitcoin would solve this correctly, rather than a time hack, however that would require a hard fork, and the bitcoin devs are scared of hard forks coz they do soft forks so badly.

https://bt.irlbtc.com/view/89278.0

Edit:
The other solution (that no doubt, one of which will be used) that are being bandied about are to move the pools work to the miner.
Thus pretty much all the pool will be doing is counting shares.
The miner (or some other program run by the miner) will be doing the work of dealing with longpolls, transaction selection and everything related to that.

If this were to take place, then I would suggest anyone who implements such a solution, also put a fee in the coinbase to cover the work you are doing for the pool .........

Thanks for feedback and much more for the donation

Startup GPU difference is just luck variance showing up. Perfectly normal.

Glad to hear failover works better.

Dynamic will show the "chosen" current intensity, which for an awesome 7970 works out to about 7. Perfectly normal. (shame it only works properly on linux it seems).

Bitcoind doesn't have LP in it.
It does have an option to run a command on a block change that you can configure yourself.

I have thought of this before with the API - being able to send a message to the API when a block change occurs, however there is one more thing in an LP that would be missing:
The LP includes work on the new block.

Without this work, the LP is simply telling cgminer to go and do a request for work and thus there is the network delay of waiting for work from the pool.

I will skip certain specific details, to protect the innocent , but this process would probably be worse than waiting for the LP

... except when LP's are slow ... which has been happening more frequently in the last few months ... but only if the pool would actually return work during it's LP phase (which wouldn't make much sense since it will already be trying to send you work)

However, this could also lead to stalling the miner due to requesting work from the pool and waiting for it, but then simply getting a piece of work for the same 'previous' block if the pool doesn't already know about the new block.

LP design sux and always has since Deepbit came up with the idea (as I have mentioned before as well) - it needs to be faster (e.g. a simple UDP packet TO the miner might perform a lot better)

Server being relocated.

If a pool screws up somehow (and the proxy pools are the ones most likely to) and starts rejected *all* your shares, cgminer will disable it after 3 minutes and only re-enable it when it starts accepting shares again already.

I looked into the "Switch User" hang reported originally in CGMiner.

It seems the hanging at least is the result of gpu_fanpercent (called by get_opencl_statline_before when updating the summary device status lines) is attempting to log warnings when ADL stops working (as it does in this situation). Logging warnings tries to lock the curses-UI to add it to the log, which just deadlocks since the same thread already has it locked for the general summary updates. There are a number of ways one might fix this, none of which are particularly elegant. Since this is pretty much just Con's domain, I'd appreciate it if someone could relay this information to him (he ignores me), and find out if he intends to fix it or not.

Thanks,

Luke