[1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff]

[rat]

We get 20 new users every day, but hardly any of them stay. I'm assuming variance is the problem. But I'd love to hear about anything that could be improved. After almost a year of intense work this is still one of the smallest pools. I'm open to the idea that I may be "doing it wrong" in some fashion.

like i said - your miner is stellar. not quite sure what's in it that makes it so efficient and unobtrusive to a non-dedicated system, but i like it.

the pool is undesirable for the reason you listed above. just not enough peeps. and the hash rate fluxuates so much.

i feel a sense of loyalty to the pool though. i really don't plan on leaving. was just asking about backup support.

you make a better miner than anyone else. and i'm sure that many in the community don't like that it's closed source - but that doesn't bother me.

you gotta nice website too.

sorry that one of your members got butthurt about what i said.

was just askin.

[1714113768]

1714113768

[1714113768]

1714113768

[SgtMoth]

...oh i have a sneaky feeling this pool will be getting a boost soon...

[SgtMoth]

2x5870 running cgminer, intensity 11x2, gpu-engine 850-900x2, gpu memclk 1200x2,gpu memdff 0x2,powertune 0x2,vddc 0x2= 73-68 degrees, avg 802m/h with .1% reject, anyone have any better settings?

[conspirosphere.tk]

2x5870 running cgminer, intensity 11x2, gpu-engine 850-900x2, gpu memclk 1200x2,gpu memdff 0x2,powertune 0x2,vddc 0x2= 73-68 degrees, avg 802m/h with .1% reject, anyone have any better settings?

Bring down the mem clock to 290-300 Mhz. You will get lower temp, lower consumption, and higher core overclock (My 5870 runs fine at 970 Mhz at 300 mem).

[DeathAndTaxes]

You may want to experiment with memclock as low as 150.  There are "magic numbers" which vary relative to the core clock so you may want to try 150, 152, 156 etc.

300 Mhz for example is performance valley being worse than 290 Mhz and 310 Mhz if the core is 850 to 900 Mhz.

[Isokivi]

Im running 2 5870's:
#1 474Mhs @ core 1030Mhz, 1,110v, mem 296Mhz, aggression 12
#2 456Mhs @ core 990Mhz, 1,10v, mem 294Mhz and aggression 12
With Phoenix, using phatk2 kernel. It took me just about forever to find these stable settings tho.

[SgtMoth]

thanks alot, ill play around alittle

[xkrikl]

The bad luck streak is continuing ...
For the period of last five days we were expected to find 7 blocks on average but we found only 3 ...
Seems that -30% became standard for this pool now. :-(

I noted that there is again missing record (no. 729) in the blocks list.
DrHaribo are you sure thare is no flaw in the database which could cause us loosing blocks? Or some one got some back door access and gets our blocks? ;-)

This graph at Pool-X (LiteCoin pool) is really nice.  I think you have to login to see it, but I think seeing it is worth making an account.
http://pool-x.eu/blocksAuth

It is a nice graph. It is per block and not per time though, on the X-axis, so it's basically the same as ours. But the Y-axis is number of shares instead of CDF, and they have a running average for the pool shown in addition to each individual block. Might be an idea adding such an average. Not sure about shares vs. CDF though.

DrHaribo did you change anything on the server lately?

Yeah, I changed most of the database stuff in the pool backend. I put in some stuff to make parallel updates safe and added automatic retries in case a database operation fails.

1) some rows are missing from my blocks list: 657, 659-660, 662, 669, 671-687, 689-691, 693, 695-698, 701-702, 705-706, 712

That's due to parallel database transactions conflicting and one being rolled back and retried. When a database transaction is rolled back everything you did is reset to how it was before the transaction started except sequences. When a number is allocated from a sequence the same number won't be given out again, even after a rollback. Already there are many gaps in the user IDs. Now with the new database code there are gaps in the block numbers. Looks a bit ugly. I think maybe I'll switch to not showing the internal ID. The table is also sometimes too wide, so that may help with that problem. Or is a block ID of some sort useful?

2) BTC blocks and NMC blocks don't come anymore in pairs as earlier:

• when BTC block 170048 was found (row 661) NMC block 45862 is listed 1 minute earlier (row 658)
• when BTC block 170495 was found (row 688) NMC block 46281 is listed 5 minutes earlier (row 670)
• when BTC block 170638 was found (row 699) NMC block 46403 is listed 1 minute earlier (row 694)
• when BTC block 170759 was found (row 710) there is no NMC block listed mined by the same user near by
• when the last BTC block 170838 was found (row 713) there is NMC block 46572 found by the same user 5.5 hrs earlier (row 711)

170838 was stale on the NMC side unfortunately. I checked the logs and we received a new namecoin block from the namecoin P2P network 5 seconds before we attempted to create ours. Let's just be glad that was a new NMC block just ahead of ours, and not a BTC block.

170495 and 46281 were created from a single proof of work from kjakman. They were created at the same time, but one had trouble getting registered in the database. It took a full 5 minutes from it was created until it was successfully registered in the DB. I was watching and cursing as the database transactions were being retried.

Also this database code is putting 10x to 20x the load on the database, compared to earlier. While that's not a problem for the server, I don't like it. I am already working on a new solution that should run much smoother. On my test server the load was much lower and conflicting transactions happened very rarely. Back to the drawing board!

[DrHaribo]

I noted that there is again missing record (no. 729) in the blocks list.
DrHaribo are you sure thare is no flaw in the database which could cause us loosing blocks? Or some one got some back door access and gets our blocks? ;-)

Yeah, I didn't update the database code yet. Things suddenly got a lot better. I think it was just an index in the database that wasn't quite done being generated that made things slow. But it still creates gaps once in a while. I'm working on a new version with donations, where a lot of the database access has been changed. Coming soon!

Even if there was a flaw with the database code or block generation I'd still see it when the server receives a proof of work that is good enough to build a block. It looks like this in my logs:

Code:

2012-03-15 12:05:47,004 INFO  [I/O dispatcher 4] com.bitminter.server.GetWorkServer$ - Passing good proof-of-work on to NMC backend!
2012-03-15 12:05:50,052 INFO  [Thread-11] com.bitminter.server.BitcoinBackend - [NMC] *** GENERATED BLOCK no. 47027 ***

The first message is logged immediately upon seeing a good proof of work. Checking all those "passing" messages it is easy for me to see if something goes wrong. And trust me, I check the logs often when we have bad luck.

How about it? Technical difficulties or else?

Reducing variance by mining with others is a good idea. It will take a lot of changes in the pool back end. But I'm starting on that very soon.

I might go for having multiple options for miners to choose from. So you could choose whether your hash power is used in p2pool (with 10 second block changes) or GPUmax, or something else. Maybe a prioritized list.

Not sure whether work on all these different projects (or work sources or whatever) should go into a common shift. The alternative would be different sets of shifts, but that would kind of split the pool into multiple pools.

[DrHaribo]

Am I seeing double? Touchdown !

Nice work kjd and Chris.

[xkrikl]

Wow, this is much better maybe we are out of the tunnel!
Although we just barely keep up to the expected average for the last few days ... to offset the 5 weeks of bad luck we will need much more ... but this is definitelly good start!

[SgtMoth]

http://steamcommunity.com/groups/bitminter/members

cool....

[ZodiacDragon84]

http://steamcommunity.com/groups/bitminter/members

cool....

cool

[ZodiacDragon84]

BTW. Great job on the solved blocks today guys!

[jake262144]

I couldn't help but notice the Personal Assets table shuffle a lot lately on BitMinter.com/members
In case you're interested in feedback, I do prefer Namecoins on top. I find this layout makes it easier for me to read the Bitcoin stats at first glance - they're the ones on the bottom of the table, followed by empty space.

[DrHaribo]

Updates today:

• Automatic donations added. You find them under "my account" -> "donations and perks". Default for new users 2%, default for existing users 0%. You can set it to anything you'd like. Please donate to support the continued development of BitMinter.
• Database code revamped. Hopefully will run a bit smoother.
• New rounding method when block income is split between miners, using the Huntington-Hill apportionment method. You may have noticed the old rounding caused the server to sometimes give out a little too much, and sometimes keep a little of the "bit dust". Now it always shares out the exact income from the block as fairly as possible.

One-time donations (where you type in a sum and donate it) and perks (extra features you get for your auto donations) will be coming soon.

I couldn't help but notice the Personal Assets table shuffle a lot lately on BitMinter.com/members

Sorry I forgot about this - will keep it in mind for the next update! I feel it may be more natural to list bitcoins first, though.

[nathanghart]

• Automatic donations added. You find them under "my account" -> "donations and perks". Default for new users 2%, default for existing users 0%. You can set it to anything you'd like. Please donate to support the continued development of BitMinter.

This is great! Thanks DrH!

Everyone, please donate and boost our pool karma. 

[DrHaribo]

Sorry, there was an issue with the signup page after the update. The problem has been fixed, so if you tried to join last night please try again.

And thanks for turning on donations, guys, it is a good motivational boost to keep developing new features.

[SgtMoth]

i had the fans blow up on one of my 5870 gigabyte cards, anyone know if a universal water block fits it....or which one of these??
http://www.frozencpu.com/cat/l3/g30/c309/s1049/list/p1/Liquid_Cooling-Water_Blocks_VGA_-_Card_-_ATI-HD_5870_Water_Blocks_-Page1.html

[DeathAndTaxes]

You don't want a universal waterblock as that won't cool the VRM and VRM temps are the real bottlenecks.

I use DangerDen blocks for 5970s.  They are solid.  They one at the link is designed for a "reference" style 5870.

The EK-FC5870 is the EK model which fits reference style 5870s.  EK is pretty much the cadillac of waterblocks.  

If you have a non-reference card well likely you should seek help from a watercooling forum like overclockers.  Non-reference can be very very very tricky.  Since the PCB can be different you need to pay close attention to make sure the waterblock will fit and there might not be any waterblock which does fit.