So, who found it?  |
|
|
|
müssen die (bzw. alle Pools, wenn sie einen angefangen haben...) den Block fertigstellen egal wie lange das (noch) dauert? (kein Umtausch oder sonstiges möglich  ) Es ist ja nicht so, dass an "einem" Block "gearbeitet" wird. Du musst es dir im Prinzip so vorstellen: jede Share hat eine gewisse Wahrscheinlichkeit, den Block zu finden. Bei der derzeitigen Diffculty (1.564.057) heißt das: es wird im Durchschnitt alle 1.564.057 Shares ein Block gefunden. Es kann aber auch nach 1000 Shares oder 8 Millionen Shares passieren - das wird in der Statistik Varianz (Streuung) genannt. |
|
|
|
Pools generally don't track stale shares
I'm still talking about "real" stales, not reported ones. You're still missing the point 50% "real" stales would mean 50% less revenue. |
|
|
|
So what would you say about a pool where >50% of the shares are stale, but they are reported to you (the miner) as valid? Screw "proof of work"  |
|
|
|
There's a difference between accepting (stale) shares and reducing (real) stales and thereby increasing the number of valid shares. Stales are mostly occuring because a pool is giving work out to multiple workers or is too slow to respond (send out LP) after a new block is found. Of course you can optimize this by writing better, more intelligent software. If a pool just silently accepts stales as valid, then of course you're right. But this would be a scam (if it's not described as a "feature" in the pool manifesto). A pool uses proportional rewards. 1% of all shares are stale. The owner decides to change the algorithm and no longer consider any shares stale. 0% of all shares are stale. What happens to the rewards per day/hour/whatever?
That's not my point. It's not about "considering" shares stale, but really reducing the number of stales. |
|
|
|
No, not at all. Consider two mining pools. One reports 2% stale shares. The other doesn't even check if shares are stall at all and so reports all shares are valid (no stale shares). Assuming a proportional payment scheme, your returns will be (on average) precisely the same with both pools. To conclude that a proportional pay pool with fewer stale shares will pay more than one with more stale shares requires that you closely scrutinize the algorithm used by both pools to determine whether a share is stale.
Well, I'm sorry to say and I know you'll refuse to admit that you were wrong. But you are. There is no "algorithm" to determine whether a share is stale or not. Either a share has the chance to find a block (it's valid), or it's duplicate/wrong and thus doesn't have a chance to find a block (it's stale). Every valid share has the same chance to find a block. So in your scenario where a pool "doesn't even check if shares are stall at all and so reports all shares are valid (no stale shares)" this will happen: a miner submits 100 stales and 1000 valid shares, but he will be displayed 1100 valid shares. Let's say there are 10 more miners with the same numbers. The pool then has 11000 shares in total and every miner get's 1/10 of the total revenue. BUT: the pool only has 10000 valid shares so far and thus has a lower probability of finding a block than another pool, which in the same time had 11000 valid shares (and really NO stales). So the members of the pool with no stales also get 1/10 of the total revenue, but total revenue is more (on average). My english is a little limited, so I don't know how to explain this any further. But it's simple math: your hashrate is limited. the more valid shares you get out of the total amount of shares you compute, the better is your chance of finding a block. |
|
|
|
Given that information, 100 shares in any reward scheme will net you more reward than 98 shares would.
Not in a proportional scheme. 100 shares out of 100,000 will give you the same reward as 98 shares out of 98,000. you don't think this through to the end. less valid shares means you'll need more time (on average) to find a block. so of course it's important to reduce stale shares. reducing stale shares is the same as increasing your hashrate. |
|
|
|
oh, ok, must admit, i probably had the bios flashed before... forgot about that. sorry for my hasty reaction  |
|
|
|
You can do it using AMDOverdriveCtrl (it works with 11.4, I used it). Instructions follow (just to save the bounty ) 1. Install AMDOverdriveCtrl ( http://sourceforge.net/projects/amdovdrvctrl/) 2. Use the GUI Alternatively you can also use it only on the commandline, you can find the config files in your home-directory/.AMDOverdriveCtrl. Just make a new file named Yourprofile.ovdr, you can use this as a template (from my 5850): <?xml version="1.0" encoding="utf-8"?>
<OVERDRIVE_PROFILE>
<PERFORMANCE_LEVEL level="2" gpu="93000" mem="30000" voltage="1088"/>
<PERFORMANCE_LEVEL level="1" gpu="55000" mem="30000" voltage="1038"/>
<PERFORMANCE_LEVEL level="0" gpu="15700" mem="30000" voltage="950"/>
<FAN_SETTING percentage="AUTO"/>
<FAN_CTRL enabled="no"/>
<FAN_CTRL_CURVE type="0"/>
<FAN_CTRL_POINT nr="0" temperature="2000" percentage="0"/>
<FAN_CTRL_POINT nr="1" temperature="4000" percentage="2500"/>
<FAN_CTRL_POINT nr="2" temperature="5000" percentage="5000"/>
<FAN_CTRL_POINT nr="3" temperature="6000" percentage="7500"/>
<FAN_CTRL_POINT nr="4" temperature="7000" percentage="10000"/>
<MONITOR_SAMPLE_TIME interval="10"/>
<COLOR_PROFILE enabled="no" longitude="-13,500000" latitude="52,500000" color_temp_day="0" color_temp_night="0" transition="30"/>
<POWERTUNE percentage="0"/>
</OVERDRIVE_PROFILE>
This will overclock your card to 930 MHz (just an example, use any values you want). Rest should be self-explanatory, just pay attention to the format of the numbers. Then, you can use AMDOverdriveCtrl using the following commands: cd ${HOMEDIR}/.AMDOverdriveCtrl DISPLAY=:0 AMDOverdriveCtrl --adapter-index=0 -b Yourprofile.ovdr Important: you have to cd to this directory before you call AMDOverdriveCtrl. Adapter index is 0 for GPU1, 3 for GPU2, 6 for GPU3 and so on. If that works (worked for me), bounty goes to 18CA6BGnATnZYpN4aoH9FZVZvjKHyLDFRs |
|
|
|
Good to hear. The stale rate is currently about the same as BTCGuild before the DDoS.
My ratio is 98/40089 (0.24%), that's honestly better than I ever did on BTC Guild. |
|
|
|
Dann würde ich exakt die Hälfte von dem bekommen, was ich bei BTC-Guild bekommen habe. .
Das stimmt nicht, da die Difficulty nicht so stark gestiegen ist. Ansonsten hast du natürlich soweit recht, aber bit pit ist die letzten Tage bei 15-20 GH rumgedümpelt, jetzt sind sie gerade über 50 gekommen... und ich würde sagen spätestens bei rund 100 GH wird die Varianz erträglich. Nach deiner Logik könnten kleine Pools niemals groß werden, weil keiner einsteigt. Mir erscheint bit pit jedoch technisch überlegen (wie wohl die meisten anderen, die Node.js kenne), deswegen helfe ich mit, den Pool zu pushen. |
|
|
|
no, you don't get more "chances"... your daily income will approach the same value in the long run. yes, I do get more chances. in an hour I could be in search of x amount of blocks. if I was in an other pool that was half as fast I would be in maybe x/2 searches. my daily income has gone up; I get what you're saying, but the theory isn't proving itself in my case. think about everytime you start a block, you flip a coin. if its heads, your search time is low; and tail, its high. 10 flips every hour will probably get you more heads than 5 flips per hour. Except that there is no block, you aren't searching, and there isn't a coin toss. Each hash you perform has a 1 in 6*10^15 chance of being successful. The end. +1! Thanks. |
|
|
|
|
Wieso risikohaft? Das ist die Varianz, mit der man bei kleineren Pools leben muss. Letztendlich gleicht es sich wieder aus, wenn man lange genug dabei bleibt. Und das wird die nächsten Tage auch besser werden, denn das einzige was bit pit noch vom Wachstum abhält ist meiner Meinung nach eben dieser lange Block, der zur Zeit läuft.
|
|
|
|
Stimmt, ich war auch lange auf Eligius... derzeit stellt sich jedoch immer mehr heraus, dass die Betreiber ziemliche Chaoten sind Bit Pit erscheint mir technisch derzeit am stabilsten, und nähert sich langsam auch der 50 GH-Marke. Ist für mich bisher mit Abstand der stabilste Pool (kaum Stales, keine Idles) und das liegt wohl vorallem daran, dass die Jungs ihre Pool-Software in node.js umgesetzt haben, das wie geschaffen für den Einsatzzweck ist. |
|
|
|
blocks getting found fast doesn't matter in the long run... it evens out. I think it does 'cause you get more chances of 'getting lucky' (finding easy blocks) in the same time frame. my daily income is up no, you don't get more "chances"... your daily income will approach the same value in the long run. think about it: if you once "get lucky" in a small pool, your one-time-earning is much higher (you get a larger portion of the "pie") |
|
|
|
Yes, I'm saying there are some miners who are going to be *very* disappointed with their expensive toy(s).
Why do YOU care?  BTW, return on investment in 130 days + still owning the asset (the GPU), that's a really good investment. And everyone should know that Bitcoin is kind of a gamble right now. |
|
|
|
Hell no. I'd never use a pool with so high fees I was 'donating' 2.5% for the invalid blocks anyway, this 3% fee isn't so bad 'cause the blocks get found fast. I couldn't believe this (block found in 18s): 07.07 02:04:28 0h 00m 1 17493 0.00277254 07.07 02:04:10 0h 07m 33 580062 0.00275919 blocks getting found fast doesn't matter in the long run... it evens out. |
|
|
|
Seems like the bonus works... how about keeping this up until you have 50+ Gh? |
|
|
|
try triplemining, they still offer the highest payments i've ever seen in a pool so far... yeah, for the ones who create minipools and spam the forums to attract more victims |
|
|
|
|
Very satisified so far, we also should be around the 95%-percentile so it shouldn't be too long before a block is found. Stats bar looks nice. Just one question: why do you display "score" in the dashboard? are you using prop or score at the moment?
|
|
|
|
|
Show Posts
