[1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration!

[The00Dustin]

Would "a target of 13 shares per minute would keep variance most consistent with a 1gh/s connection" be a valid conclusion?  I gathered this primarily from the last chart in your blog.  I don't know if that is Inaba's goal anyway, but someone mentioned a desire for something to that effect.

[Luke-Jr]

Would "a target of 13 shares per minute would keep variance most consistent with a 1gh/s connection" be a valid conclusion?  I gathered this primarily from the last chart in your blog.  I don't know if that is Inaba's goal anyway, but someone mentioned a desire for something to that effect.

The exact number is 13.969838619232177734375 shares per minute: 60 seconds ÷ (2³² nonces-per-pdiff1-share-on-average ÷ 1,000,000,000 hashes-per-second)

[organofcorti]

Would "a target of 13 shares per minute would keep variance most consistent with a 1gh/s connection" be a valid conclusion?  I gathered this primarily from the last chart in your blog.  I don't know if that is Inaba's goal anyway, but someone mentioned a desire for something to that effect.

This probably belongs over in the Neighbourhood Pool Watch thread, but anyway your answer is no it would not be a valid conclusion. If Inaba plans on having a set difficulty per minute for all miners then the variation in average hashrate does not depend on the miner hashrate.

This case is covered in the first table in section two.

A better conclusion would be "a target of 13 shares per minute would keep variation in average average per minute hashrate to -55% to 64%, variation in average hourly hashrate to ~ +/- 7% and variation in average daily hashrate to +/- 1.4%, all with 95% confidence.

HTH.

[organofcorti]

Would "a target of 13 shares per minute would keep variance most consistent with a 1gh/s connection" be a valid conclusion?  I gathered this primarily from the last chart in your blog.  I don't know if that is Inaba's goal anyway, but someone mentioned a desire for something to that effect.

The exact number is 13.969838619232177734375 shares per minute: 60 seconds ÷ (2³² nonces-per-pdiff1-share-on-average ÷ 1,000,000,000 hashes-per-second)

OK then:

A target of 13.969838619232177734375 shares per minute would keep variation in average average per minute hashrate to -50% to 57.5%, variation in average hourly hashrate to ~ +/- 6.7% and variation in average daily hashrate to +/- 1.4%, all with 95% confidence.

[The00Dustin]

So a better conclusion (and I'm still in this thread because I am trying to understand your work only as it applies to his pool right now) would be "if one wants to use a target number of shares per minute, he can only refer to the graphs in the first section to cherry-pick a variation range."  I am assuming letting miners pick their target is a losing option based solely on my opinion of human nature.

[organofcorti]

So a better conclusion (and I'm still in this thread because I am trying to understand your work only as it applies to his pool right now) would be "if one wants to use a target number of shares per minute, he can only refer to the graphs in the first section to cherry-pick a variation range."

Yes. Or the table. Or the CSV files (can't post links here unfortunately)

I am assuming letting miners pick their target is a losing option based solely on my opinion of human nature.

Seems to work ok at HHTT.

[Inaba]

It looks like 20 - 24 is an optimal range to satisfy the 1 minute emotional need for the vast majority of people... am I reading that right?

[organofcorti]

It looks like 20 - 24 is an optimal range to satisfy the 1 minute emotional need for the vast majority of people... am I reading that right?

I think whatever you use the 1 minute variance is going to be something people will worry about. At 20 shares per minute the 95% CI for average per minute hashrate is -40% to +45%, and at 24 shares per minute the 95% CI for average per minute hashrate is -38% to +42%. At 1Ghps and difficulty 1 you're only submitting an average of 13.98 shares per minute anyway.

I'll try to find a way to compare variance miners already experience at pool D = 1 to what they'd experience at another D or number of shares per minute.

Otherwise I think the variance in share submission rates a 1Ghps miner experiences at pool D = 1 should be fine for most miners. Say 14 shares per minute to make it easier to calculate pool D. It also makes it easier for miners to know when the variable pool D begins - at 1Ghps and below pool D = 1, and above 1Ghps pool D starts to increase.

Unless you plan on making the relationship completely linear and reducing pool D to less than one? It would be a great selling point for the tinier miners.

[The00Dustin]

I am assuming letting miners pick their target is a losing option based solely on my opinion of human nature.

Seems to work ok at HHTT.

I assume ASICs don't exist yet.  I have seen a lot of posts about "the biggest miners donate the least."  IF the biggest miners are that selfish, it seems like a safe assumption that they will choose lower diff in order to decrease variance for the same reasons they donate the least.  I know this is an assumption, hence the comment: "based solely on my opinion of human nature."

[Askit2]

Hey Inaba could you check the email system. The last email I had delivered to inbox or junk mail was on Sunday.
Thank You!

[kano]

...
Unless you plan on making the relationship completely linear and reducing pool D to less than one? It would be a great selling point for the tinier miners.

Although cgminer already works with LTC mining and thus handles fractional D, it wont actually work in any BTC miner (or cgminer) since they all check for H=0 thus you'd lose valid shares if D < 1

Seriously, that's a hard limit in all BTC mining since all BTC devices only return 1 Diff shares (H=0)

That's a big part of the 6.25% performance optimisation in GPU mining ... and anyone who reads this, and is thinking of suggesting all the mining devices and GPU OCL code be rewritten, simply doesn't understand the negative implications or the time wasted in trying to do that

[organofcorti]

I am assuming letting miners pick their target is a losing option based solely on my opinion of human nature.

Seems to work ok at HHTT.

I assume ASICs don't exist yet.  I have seen a lot of posts about "the biggest miners donate the least."  IF the biggest miners are that selfish, it seems like a safe assumption that they will choose lower diff in order to decrease variance for the same reasons they donate the least.  I know this is an assumption, hence the comment: "based solely on my opinion of human nature."

I don't know about "the biggest miners donate the least." I haven't seen any data on the subject. I have however seen lots of smaller miners complain when Ozcoin introduced fees a little while back. Shock! Horror! Paying for a pool? Inconceivable!

Anyway, this is now sufficiently OT. I return you to your regularly scheduled programming.

[organofcorti]

...
Unless you plan on making the relationship completely linear and reducing pool D to less than one? It would be a great selling point for the tinier miners.

Although cgminer already works with LTC mining and thus handles fractional D, it wont actually work in any BTC miner (or cgminer) since they all check for H=0 thus you'd lose valid shares if D < 1

Seriously, that's a hard limit in all BTC mining since all BTC devices only return 1 Diff shares (H=0)

That's a big part of the 6.25% performance optimisation in GPU mining ... and anyone who reads this, and is thinking of suggesting all the mining devices and GPU OCL code be rewritten, simply doesn't understand the negative implications or the time wasted in trying to do that

Thanks for that explanation kano - I'd wondered about D < 1 ever since var diff was first proposed.

[poon-TANG]

Sweet Baby Jesus I just scored my first block today !!!!!!! WHOO HOOO

[ChipGeek]

Sweet Baby Jesus I just scored my first block today !!!!!!! WHOO HOOO

Yeah, I've only been mining for 3 weeks on a BFL single and I've found 2 (yes TWO!) blocks in the last week.  With good luck like that, I'm probably doomed to NEVER find another one in my life! 

[dave3]

Hey Inaba could you check the email system. The last email I had delivered to inbox or junk mail was on Sunday.
Thank You!

The last email notice I received from EMC was timestamped:

Sun, 7 Oct 2012 14:54:14 -0500

I just logged in and noticed we've been solving blocks after all!  For awhile I thought we were having a period of really bad luck.

[Askit2]

I have been mining on eclipseMC since may 7th with a BFL single and just got my third block today so that is YAY!
I still don't get emails at BTC block solves. Last one I got was 2012-10-7, 13:50:04.
I have tried unchecking the btc block solve emails, then change, then Recheck btc block solve emals then change.
That didn't do anything. I suppose I could try setting up either a miner fail email or name coin block email but I was realy not interested in them.
I am on hotmail but until sunday afternoon I recieved the emails properly or at least most of them. I know Inaba will look into it and I appreciate all he does.

[Inaba]

If you don't mind posting, what is your domain name for your email?  I can look into why it's not being delivered.

Also - Vardiff has been disabled, since it's redundant and hardly anyone was using it. If you were one of the 800 MH/s that was mining on it, you might want to repoint your miner to US1. 

I am going to be upping the share targets on the servers as follows:

US1: 20
US2: 24
US3: 28

[Inaba]

Someone please call an ambulance, I think I am having a heart attack. 

In the meantime, while I'm in limbo, before the paramedics revive me, I am going to check that the temperature in hell hasn't dropped below zero.

I submitted a block removal request to Comcast about an hour ago and just got an email back from them telling me they have removed the block on the new IPs.    So not only did Comcast actually respond (a hell freezing over worthy response), but they responded appropriately and positively... WITHIN AN HOUR.

Someone call the $#@#$%@ new stations, because this is a @#$@ banner day in Internet History right here.  Comcast actually responded, responded in a timely fashion, and responded appropriately.  Holy crap.  Maybe I really am dead.

(Comcast email addresses should now be able to receive email)

[jamesg]

Someone please call an ambulance, I think I am having a heart attack. 

In the meantime, while I'm in limbo, before the paramedics revive me, I am going to check that the temperature in hell hasn't dropped below zero.

I submitted a block removal request to Comcast about an hour ago and just got an email back from them telling me they have removed the block on the new IPs.    So not only did Comcast actually respond (a hell freezing over worthy response), but they responded appropriately and positively... WITHIN AN HOUR.

Someone call the $#@#$%@ new stations, because this is a @#$@ banner day in Internet History right here.  Comcast actually responded, responded in a timely fashion, and responded appropriately.  Holy crap.  Maybe I really am dead.

(Comcast email addresses should now be able to receive email)

Quoted for when comcast inevitably effs up again....