Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff] - page 314. (Read 837101 times)

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

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

cool....

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? ;-)

How about it? Technical difficulties or else?

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.


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.


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?


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!

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?

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.

What do you think sucks about the pool?

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.

can you make the bitminter client work with other mining pools. if no, why not?

you make a great miner.

i just think the pool sucks.

nothing personal towards you and your developers.

LOLZ.  I am curious what exactly about the pool "sucks"?