Author

Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 173. (Read 499592 times)

donator
Activity: 2058
Merit: 1007
Poor impulse control.
I'm not sure this is any better, but I've used -log(N/D) in the past. This will give you a number between about +/- 2.5 for most rounds, but it overemphasises lucky rounds.
legendary
Activity: 1260
Merit: 1000
So I made some adjustments as you mentioned, Meni... I'm not sure that clears up any confusion, just seems to be trading it for different confusion.

So we have a 95% block, which is good luck, but a 13% block which is bad luck.  Seems like we should still have some sort of positive/negative list as to if we are under or over expected shares (difficulty). 
donator
Activity: 2058
Merit: 1054
One of the problems with the luck column is that there is no upward bound on "bad" luck, whereas there is a negative bound of 1% (or 0% if it takes exactly one share to find a block) - you can only have a -99% luck factor, but you can have a theoretically infinite + luck factor.  So the color visualization is kind of misleading... if anyone has any ideas on how to improve the luck factor display, I'm all ears.
Depends on what exactly you want to achieve with the luck factor display, but one obvious way to have a balanced view is to use percentiles. If the round length is N and the difficulty is D, then exp(-N/D) is the (opposite of the) percentile, which is uniformly distributed from 0% to 100% - higher is better and 50% is in some sense average luck (unlike the current luck factor which is green more often than red). Then you can color-code that, maybe even with a continuous gradation from red to green.
legendary
Activity: 1260
Merit: 1000
Sure thing, come on in!  We would be glad to have you!
sr. member
Activity: 476
Merit: 500
It's time to try a new pool. Can I still get in on merged mining here?
legendary
Activity: 1260
Merit: 1000
Yeah, it was a mistake.  We solved 153863 a bit earlier and the system thought we solved 153862 for some reason later.  I changed the way new blocks are discovered to prevent that from happening in the future.  I thought I had it the proper unique keys set on the DB, but apparently I didn't have it set to the TXID like it should have been and it was keying off of the block number.  Doh.

full member
Activity: 150
Merit: 100
I got an email notification that we solved block 153862 this morning.  It's not showing up in the block stats though. 
legendary
Activity: 1260
Merit: 1000
Ah... yeah they seem to be backwards now huh.  I limited the graphs to the last 100 blocks, since they were getting pretty crowded.  I didn't consider that it would start graphing them from the other way, doh.  I need to fix the labels.

member
Activity: 70
Merit: 10
The Shares per block Graph seems to have flipped.
member
Activity: 78
Merit: 10
One of the problems with the luck column is that there is no upward bound on "bad" luck, whereas there is a negative bound of 1% (or 0% if it takes exactly one share to find a block) - you can only have a -99% luck factor, but you can have a theoretically infinite + luck factor.  So the color visualization is kind of misleading... if anyone has any ideas on how to improve the luck factor display, I'm all ears.
You could make it so that every +50% or +100% is a new darker shade of red. Then at some point (maybe like +400%) the dark red just turns into a small nuclear explosion.
legendary
Activity: 1260
Merit: 1000
Let me get this straight: "(+9.24%)" under "Prop diff." means payout is 9% greater compared to what the payout would have been using proportional method? If so, a positive amount means "good". In the "luck" column, positive amounts mean "bad".

So, it would be my suggestion you should color this column accordingly (orange for "bad", green for "good" - this has to be the miners view, of course Smiley)

That's correct, you received 9.24% more than you would have under Proportional.  

That's a fine idea with the colors and I've added that to the block display!

One of the problems with the luck column is that there is no upward bound on "bad" luck, whereas there is a negative bound of 1% (or 0% if it takes exactly one share to find a block) - you can only have a -99% luck factor, but you can have a theoretically infinite + luck factor.  So the color visualization is kind of misleading... if anyone has any ideas on how to improve the luck factor display, I'm all ears.

newbie
Activity: 53
Merit: 0
Let me get this straight: "(+9.24%)" under "Prop diff." means payout is 9% greater compared to what the payout would have been using proportional method? If so, a positive amount means "good". In the "luck" column, positive amounts mean "bad".

So, it would be my suggestion you should color this column accordingly (orange for "bad", green for "good" - this has to be the miners view, of course Smiley)
legendary
Activity: 1260
Merit: 1000
I'm glad everything is working for you guys.  Sometimes it's hard to tell what the miner experience is just by looking at the numbers. Smiley

How does the prop differential and payout look for this block for everyone?  It looks ok from the numbers here, but I want to check with the actual miners to make sure you guys are happy with things or if I need to make adjustments.


Looks fine here. There was a round where the Top20 miner list looked off, everyone's hashrates were cut by half approximately. I don't think it affected the payout or anything.
Thanks for the work you put into the pool.

Yeah, the top miners is calculated by dividing the time and shares submitted over the life of the block.  Due to some of the changes, the calculation got screwed up.  But in either case, the calculation doesn't have any relation to the payout tables, so it doesn't have any reflection on payouts, as you surmised.
member
Activity: 70
Merit: 10
Lookin' good here.   Cool
Thanks for all the hard work that goes into Eclipse!
full member
Activity: 226
Merit: 100
How does the prop differential and payout look for this block for everyone?  It looks ok from the numbers here, but I want to check with the actual miners to make sure you guys are happy with things or if I need to make adjustments.


Looks fine here. There was a round where the Top20 miner list looked off, everyone's hashrates were cut by half approximately. I don't think it affected the payout or anything.
Thanks for the work you put into the pool.
brand new
Activity: 0
Merit: 250
Blimey, that rebuild took all night (5:48 am and I should be getting some sleep)... anyone considering cheap XFX cards from a certain UK online 'video card shop' - think long and hard. I've had 50% failure rate due to XFX making utter junk.

A chance acquisition of a few of my favourite card ever has allowed me to remove 4 5830s from the main Shelf Rig (replaced with decent 5850s), and build a 'test' 4-card rig. This eats 780W at the wall, and is delivering 1520 MH/sec according to Phoenix, and 1,625 according to EMC dashboard.

I'll try to get refunds for the crap XFX stuff but apart from a few remaining cards (the 5830s swapped out from the main Shelf Rig) that need a home, this is the end of the road for my GPU mining endeavours. I think I'll end up maxing out around 8 GH/sec.

Future hash expansion will be FPGAs. I'm interested in building a multi-card setup as 'tech art' - controlled by my G4 Cube and living in a transparent acrylic 'case' - industrial design will have to be good... capital cost is high but it'll look wildly cool, won't use much power, won't need extreme cooling solutions, and of course 'for teh lulz'. It's looking like ZTEX will be the supplier, but this isn't going to happen immediately.

Got to be done though!

Really impressed with the pool though. If anyone is interested in my lightweight Linux 'multiple GPU miner in a box' install, let me know - it's pretty much complete and delivers a working pool-based Linux mining setup in half an hour (or more, depending primarily on I/O performance) with very little in the way of 'tweaking' required either before or after the main script runs. The manual tasks are (a) set up the logic board BIOS correctly, and (b) alter the numbers in the overclock script. I can't really automate overclocking that easily - it's so dependent on temperature, individual card variability, PSU quality and OEM card build (heatsink / fan / etc.) that you really need to test each card step-by-step - and is the single largest investment of time required to optimise the mining rig.
donator
Activity: 798
Merit: 500
Everything looks good for me. Thanks for all the work. This is the only pool I've found with constant improvements and great stability.
legendary
Activity: 1260
Merit: 1000
How does the prop differential and payout look for this block for everyone?  It looks ok from the numbers here, but I want to check with the actual miners to make sure you guys are happy with things or if I need to make adjustments.
legendary
Activity: 1260
Merit: 1000
Previous blocks should be correct now and your accounts are updated with the correct unconfirmed and confirmed BTC. 

I paid a little bit extra in the last three blocks for the trouble.  So your confirmed balance increased a bit as did your unconfirmed balance compared to previous.  If there are any problems with your balances, let me know.

I think the issues are worked out with block solves, but should a problem arise next solve I will get it taken care of immediately.  Sorry for the troubles.

I've also added NMC quick stats info to the quick stats box at the top of the page.

Additionally, your estimated payout on every page is now calculated against your DG score instead of prop (previously, it was calculated against prop on all but the My Accounts page). 
legendary
Activity: 1260
Merit: 1000
I broke the prop differential display.

Two blocks ago, I made some changes to the getwork server which eliminated a really slow table in the database.  As such, I had to make a bunch of changes to the share counting and tracking code and in the process I apparently broke something and it's only now becoming apparent.  Your payouts should be accurate even though it's listing it as substantially lower compared to prop.

I think the problem lies in the code counting shares it shouldn't be counting (stales, duplicates, etc...) when it's calculating prop, but I can't seem to find where that's getting injected into the DB improperly.  I need to go over the getwork server code and the website code and see where they aren't matching up.

I just wanted to let everyone know that it is only a display bug and not a payout bug.  If anyone notices that their payout is less than it should be, let me know asap, but the math is adding up everywhere else and payouts are paying out to the correct amount from the spot checks I've done as well as the total payout being right on the money, so to speak. 

So... just letting everyone know since we've solved a couple blocks in rapid succession and the bug appears to be present in more than just my view of the block history.  I didn't want anyone to worry. 

Let me know if you have any questions.
Jump to: