How accurate are bitcoin calculators?

[mcattack86]

Hi all,

I used this calculator to see how many BTC per day I should be mining:
http://www.alloscomp.com/bitcoin/calculator.php

I am running at 565 Mhash/s, consistently, while connected to Slush's pool (HD5770 + HD5850).  Over the last few hours, I've checked my account at mining.bitcoin.cz to see how my "Total reward" changes every hour. 
I've only been averaging 0.009 BTC/hour, which translates into 0.23 BTC/day. 
The calculator estimates that I should be getting 0.36 BTC/day.

My rejected count stays between 2% and 3%...and my phoenix software has not disconnected from the server once.

Any ideas?

My phoenix command line is as follows:

C:\...\phoenix.exe -u http://username.worker:password@api2.bitcoin.cz:8332/ DEVICE=0 -k phatk VECTORS BFI_INT FASTLOOP=false AGGRESSION=11 WORKSIZE=256

Thanks!

i7 930, 12gb RAM, MSI Hawk R5770, Sapphire Xtreme HD5850

[MiningBuddy]

Hi all,

I used this calculator to see how many BTC per day I should be mining:
http://www.alloscomp.com/bitcoin/calculator.php

I am running at 565 Mhash/s, consistently, while connected to Slush's pool (HD5770 + HD5850).  Over the last few hours, I've checked my account at mining.bitcoin.cz to see how my "Total reward" changes every hour. 
I've only been averaging 0.009 BTC/hour, which translates into 0.23 BTC/day. 
The calculator estimates that I should be getting 0.36 BTC/day.

My rejected count stays between 2% and 3%...and my phoenix software has not disconnected from the server once.

Any ideas?

My phoenix command line is as follows:

C:\...\phoenix.exe -u http://username.worker:password@api2.bitcoin.cz:8332/ DEVICE=0 -k phatk VECTORS BFI_INT FASTLOOP=false AGGRESSION=11 WORKSIZE=256

Thanks!

i7 930, 12gb RAM, MSI Hawk R5770, Sapphire Xtreme HD5850

[mcattack86]

.....Okay and that means...what?

That because my rejected count is 2 to 3 percent...it makes sense that I'm averaging 33% less than the estimate?  Hmm...

I'm just wondering what other people are experiencing

[ruski]

Increase the number of threads you're mining with. Every time you find and send a proof of work it has to halt that thread until it receives a response.

[MiningBuddy]

.....Okay and that means...what?

That because my rejected count is 2 to 3 percent...it makes sense that I'm averaging 33% less than the estimate?  Hmm...

I'm just wondering what other people are experiencing

Sorry, I was being lazy.
What I was trying to say is the calculators are estimates for 100% uptime, perfect conditions, no variance etc.
What you are experiencing is pretty normal variance, some days will be higher, some lower.

[mcattack86]

Increase the number of threads you're mining with. Every time you find and send a proof of work it has to halt that thread until it receives a response.

Thanks for the suggestion -- I've tried googling how to do this (and what the number of threads actually does) but the word "thread" throws off my search results since people use it to describe forum posts instead.

Could you point me to somewhere that describes how btc miners use threads?  Or let me know how I could edit my phoenix command line to use your suggestion?

[mcattack86]

What you are experiencing is pretty normal variance, some days will be higher, some lower.

Really?  Wow...33% is a pretty big dropoff -- when calculating if it'd be worth it to dive into mining I was not expecting the estimate to be that off.

Edit: Over the last 2.5 hours (10% of one day) I've accumulated 0.0148 BTC -- 0.15 BTC/day on average now...and no instances of disconnects from server in that timeframe

[MiningBuddy]

What you are experiencing is pretty normal variance, some days will be higher, some lower.

Really?  Wow...33% is a pretty big dropoff -- when calculating if it'd be worth it to dive into mining I was not expecting the estimate to be that off.

Edit: Over the last 2.5 hours (10% of one day) I've accumulated 0.0148 BTC -- 0.15 BTC/day on average now...and no instances of disconnects from server in that timeframe

2.5 hours is simply too short of a time frame to make assumptions on imho.
Remember your pool could get lucky or unlucky causing a huge amount of variance for that day too.

[ruski]

Increase the number of threads you're mining with. Every time you find and send a proof of work it has to halt that thread until it receives a response.

Thanks for the suggestion -- I've tried googling how to do this (and what the number of threads actually does) but the word "thread" throws off my search results since people use it to describe forum posts instead.

Could you point me to somewhere that describes how btc miners use threads?  Or let me know how I could edit my phoenix command line to use your suggestion?

Accidental example for you. Mistyped threads paramater, got zero threads.

[mcattack86]

Accidental example for you. Mistyped threads paramater, got zero threads.

Ohhh okay....well the thing is that phoenix is showing that I'm running at 207 and 357 Mhash/s on my cards (which is about right when I've looked for other people's benchmarks elsewhere) -- while your "did it wrong" example shows that the Mhash/s rate is lower.  I'm using GPUs too -- do they have threads like CPUs?

And just a random question out of curiosity -- what does the queue flag -q adjust?  Anything to do with my connection to the server?

[mcattack86]

What you are experiencing is pretty normal variance, some days will be higher, some lower.

Really?  Wow...33% is a pretty big dropoff -- when calculating if it'd be worth it to dive into mining I was not expecting the estimate to be that off.

Edit: Over the last 2.5 hours (10% of one day) I've accumulated 0.0148 BTC -- 0.15 BTC/day on average now...and no instances of disconnects from server in that timeframe

2.5 hours is simply too short of a time frame to make assumptions on imho.
Remember your pool could get lucky or unlucky causing a huge amount of variance for that day too.

That makes perfect sense, thanks for your explanations

[ruski]

Accidental example for you. Mistyped threads paramater, got zero threads.

Ohhh okay....well the thing is that phoenix is showing that I'm running at 207 and 357 Mhash/s on my cards (which is about right when I've looked for other people's benchmarks elsewhere) -- while your "did it wrong" example shows that the Mhash/s rate is lower.  I'm using GPUs too -- do they have threads like CPUs?

And just a random question out of curiosity -- what does the queue flag -q adjust?  Anything to do with my connection to the server?

It was lower because it was zero - there were no threads, so the cpu wasn't working. Threads are like instances of your program. Every time a thread finds a proof of work, it submits it. That instance of the program is then busy waiting for a response before it resumes mining again. With more threads, the other threads are free to continue working while one is submitting. Hence you may have been about to find four POWs in the space of a few seconds, but you only found one because it stopped to send.

[mcattack86]

there were no threads, so the cpu wasn't working.

Sorry I'm still a bit confused -- in your example you only had one device for mining, the CPU?  The -t <cores> flag only pertains to people who are using their CPU for mining, right?

And I understood your example -- you showed that with the correct number of threads you got 1.17 MH/s and with the incorrect number of threads you got 0.00 MH/s. 
My point was that: if my # of threads is incorrect, I should have a much lower hash rate than 208 MH/s and 357 MH/s (the respective averages for an HD5770 and HD5850 at the speeds I've set them at...from what I've found from other people's posts online).  So I'm thinking it's not that.

But based on MiningBuddy's intuition, I think he/she is right -- it's just the case that a few hours passed when the pool didn't get that lucky with mining new blocks.