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

[DrHaribo]

Turbor, your explanation is as good as any I can come up with.

Looks like all I/O got slower and slower. After a while some getwork requests took 5 minutes. The database connections terminated with "end of file" and it was impossible to establish new ones. syslog tells me the web server got stuck for over 120 seconds waiting for a page from disk. But there is nothing wrong with the disks. The pool server had several hundred thousand closed connections that somehow the kernel stopped clearing away. The load was 25-30 with almost no cpu usage. Apparently all these processes were waiting on IO. I could still send a request to bitcoind or namecoind and it would register in their logs but no response would come out. After restarting each process everything is fine. It's like the kernel just wouldn't honor IO requests from the "old" processes. I've never seen anything like it.

So yes, maybe it was the ghost in the machine.

I'll be working on robustness and automatic recovery, although I hope not to see this type of behavior again.

[lenny_]

DrHaribo, what you think about implementing Hall of Fame (users who found most amount of blocks) like in Slush pool?

http://mining.bitcoin.cz/stats/hall-of-fame/

[loshia]

Turbor, your explanation is as good as any I can come up with.

Any recent kernel upgrade of the pool? If yes just go back to old one

[organofcorti]

.... although I hope not to see this type of behavior again.

Everyone says this about their child at some point

[LazyOtto]

So you did something to resume 'normal' / getwork processing?

I had eight shifts with zero or near zero scores.

[DrHaribo]

Hall of fame is on my list.

I had eight shifts with zero or near zero scores.

Could be because your miner stayed at a backup pool or that it crashed when it was disconnected by the server. Some miner programs have been having those issues lately.

[MrTeal]

.... although I hope not to see this type of behavior again.

Everyone says this about their child at some point

I think I say this every day for my 2 year old.

[DrHaribo]

Need to restart bitcoind and namecoind. They take a while to get up and running again, sorry for the delay..

[lenny_]

Stratum port 5050 seems to be down. Port 3333 working OK.

[DrHaribo]

Stratum port 5050 seems to be down. Port 3333 working OK.

It's working for me. It's just a redirect, so 5050 and 3333 should be up/down at the same time.

[juhakall]

I noticed an odd rejected share, using cgminer 2.10.2 & stratum:

Rejected 3fd895f5 Diff 4/4 GPU 1 pool 0 (Work below difficulty)

I only barely understand how share difficulties work, but I was told in #cgminer IRC channel that the target hash for diff4 should be 0x000000003fffc000. My rejected share hash was 0x000000003fd895f5, which is smaller than the target, so shouldn't it be accepted? I'm also aware of the discrepancy between "real" and actually used diff1 shares, which is explained here by kanoi. Could this be a similar problem, meaning that there's a disagreement between cgminer and BitMinter as to what actually is the target for a diff4 share?

[miter_myles]

down?

[juhakall]

Yeah, seems to be down.

[Equilux]

Website itself is up, but my client can't connect ...

[DrHaribo]

bitcoind and namecoind both slowed down at the same time. There's some sort of issue there. Pool recovered after a couple of minutes though.

juhakall, a 4/4 difficulty proof being rejected sounds strange.. I'll have a look at it. This was with Stratum?

[juhakall]

juhakall, a 4/4 difficulty proof being rejected sounds strange.. I'll have a look at it. This was with Stratum?

Yes, that's with stratum.

[DrHaribo]

juhakall, a 4/4 difficulty proof being rejected sounds strange.. I'll have a look at it. This was with Stratum?

Yes, that's with stratum.

The target is the exact same you mentioned previously, so the share should be accepted. Do you have the time when this happened? If so I'll have a look at the logs if there are any errors.

Maybe the data is mangled somehow, so when the server hashes it the share doesn't even meet diff 1.

[juhakall]

juhakall, a 4/4 difficulty proof being rejected sounds strange.. I'll have a look at it. This was with Stratum?

Yes, that's with stratum.

The target is the exact same you mentioned previously, so the share should be accepted. Do you have the time when this happened? If so I'll have a look at the logs if there are any errors.

Maybe the data is mangled somehow, so when the server hashes it the share doesn't even meet diff 1.

Date was 2012-12-20 17:29:06 UTC.

[DrHaribo]

Date was 2012-12-20 17:29:06 UTC.

Nothing logged at that time. I don't really have any data to go on. Have you seen this multiple times or just that once? If it happens repeatedly I could add more logging to try and figure out what's going on.

[juhakall]

Nope, I just happened to catch that one as it happened. I'll try using cgminer's sharelog function, but if that rejection only occurs with shares very close to the target, it might be rare and take a while to see again.