[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[jcumins]

Yes I am doing that on all Ant miners.

Was wondering if any one played with the expire settings and did any testing to confirm or deny the claim.

[-ck]

The other thing I want to point out is the -expiry option.  A lot of people have said the setting doesn't matter anymore, but I can't see why.  I've never looked at the code, but the cgminer readme has the info below.  I always change my miners to 1 (all currently Antminer).  When I left it as the default of 120, I got more stales.  I did not run an extensive test though.

--expiry|-E <arg>   Upper bound on how many seconds after getting work we consider a share from it stale (default: 120)

You've never looked at the code but can't see why it doesn't matter...

I wrote the code and I'm telling you it doesn't matter.

[MissouriMiner]

The other thing I want to point out is the -expiry option.  A lot of people have said the setting doesn't matter anymore, but I can't see why.

Please stop telling people  to do anything but change the queue. Artificially lowering the discarded value serves no purpose whatsoever. Decreasing scan time and expiry are for the dark ages of CPU mining - paying any attention to the "discarded work" value is completely pointless and actually harmful. The only thing here that's making a difference to CPU load is decreasing the queue which they have set far too high by default. Please do not decrease it below 1 though.

Although, as IYFTech demonstrated, using a queue setting of 0 gave better results with Antminers on p2pool, but it depends on your set up of course.

OK.  My bad on the expiry param.  I won't mention that again.  And my decision to add that note diluted my message about disk I/O, which I still stand by.  SSD's are certainly great, but there is no disk I/O requirement coming from p2pool or bitcoind to make the SSD a necessity.  Most modern filesystems use system ram as buffer cache and the I/O load is so low, it's all cache hit performance.

[jcumins]

Ya the jury is still out on  SSD drive,  I have setup one of the 14 S5 going in next week will run them for the next 4-5 days them ship them to the data center.  Then fly down and install the S5 and remove the older s1 and s2.


So far the S5 is running at spec no issues at all, but did change the queue to 0.  They have created a user config file now they refer to for the queue settings.

Not to bad.

[yslyung]

The other thing I want to point out is the -expiry option.  A lot of people have said the setting doesn't matter anymore, but I can't see why.

Please stop telling people  to do anything but change the queue. Artificially lowering the discarded value serves no purpose whatsoever. Decreasing scan time and expiry are for the dark ages of CPU mining - paying any attention to the "discarded work" value is completely pointless and actually harmful. The only thing here that's making a difference to CPU load is decreasing the queue which they have set far too high by default. Please do not decrease it below 1 though.

Although, as IYFTech demonstrated, using a queue setting of 0 gave better results with Antminers on p2pool, but it depends on your set up of course.

OK.  My bad on the expiry param.  I won't mention that again.  And my decision to add that note diluted my message about disk I/O, which I still stand by.  SSD's are certainly great, but there is no disk I/O requirement coming from p2pool or bitcoind to make the SSD a necessity.  Most modern filesystems use system ram as buffer cache and the I/O load is so low, it's all cache hit performance.

SSD or a faster drive does play a role. But not VERY significant after everything boots up and settles down. EG loading bitcoin wallet loading blocks, loading p2pool shares, merged wallets, etc. Of course network connections too.

If you still disagree  run the entire p2pool on a regular laptop with 4gb ram.  Dual core cpu & a 5200rpm hdd.

Every little bit helps. ssd are affordable now.

[mdude77]

Ya the jury is still out on  SSD drive,  I have setup one of the 14 S5 going in next week will run them for the next 4-5 days them ship them to the data center.  Then fly down and install the S5 and remove the older s1 and s2.


So far the S5 is running at spec no issues at all, but did change the queue to 0.  They have created a user config file now they refer to for the queue settings.

Not to bad.

I'd be interested to know how well the group of S5s hash over time. As it stands right now, I have to power cycle my S3s every week or so, otherwise they slow down as a group by more than 10% after about two weeks. A soft reboot won't fix it either, it has to be a hard power cut. Makes me wish I had gotten switch duty circuit breakers.

I know my GetBlockTemplate latency went way down once I switched to SSD, but that was multiple bitcoin versions ago, so maybe the newer versions don't have that problem.

You know, this must be a Bitmain firmware problem.  I was running my S4s on p2pool for quite a few days, and I noticed a disturbing trend.  The hash rate starts to drop and drop, until running at 1.5 TH/s or less.  Today it came on quite suddenly.  I'm pretty sure this morning they were running at 2 TH/s, and when I came home from work, one was at 1.3 TH/s and one was at 1.5 TH/s.  Soft reboots usually fix them.  But I can't have them running that low when I'm not around to baby sit them, so they are back to ckpool.

I remember my S2s used to do this as well.  They just didn't like running on p2pool, and would eventually start to behave erratically.

I could never get my S3s to work properly on p2pool.

M

[Prelude]

Ya the jury is still out on  SSD drive,  I have setup one of the 14 S5 going in next week will run them for the next 4-5 days them ship them to the data center.  Then fly down and install the S5 and remove the older s1 and s2.


So far the S5 is running at spec no issues at all, but did change the queue to 0.  They have created a user config file now they refer to for the queue settings.

Not to bad.

I'd be interested to know how well the group of S5s hash over time. As it stands right now, I have to power cycle my S3s every week or so, otherwise they slow down as a group by more than 10% after about two weeks. A soft reboot won't fix it either, it has to be a hard power cut. Makes me wish I had gotten switch duty circuit breakers.

I know my GetBlockTemplate latency went way down once I switched to SSD, but that was multiple bitcoin versions ago, so maybe the newer versions don't have that problem.

You know, this must be a Bitmain firmware problem.  I was running my S4s on p2pool for quite a few days, and I noticed a disturbing trend.  The hash rate starts to drop and drop, until running at 1.5 TH/s or less.  Today it came on quite suddenly.  I'm pretty sure this morning they were running at 2 TH/s, and when I came home from work, one was at 1.3 TH/s and one was at 1.5 TH/s.  Soft reboots usually fix them.  But I can't have them running that low when I'm not around to baby sit them, so they are back to ckpool.

I remember my S2s used to do this as well.  They just didn't like running on p2pool, and would eventually start to behave erratically.

I could never get my S3s to work properly on p2pool.

M

When that happens s, it means 1 of the 4 hash boards has locked up. Used to happen to me every day or 2 with the old firmware. The newly released firmware has completely solved that, all my S4s are working great now. The only issue is 225mhz doesn't work properly on p2pool for some reason, have to drop to 218.

The new firmware will also lower your power consumption as there was previously a bug with 1 of the hash boards being locked at 0750 no matter what you set. Now they're all at 0725.

[Arnab biswas]

 I disappeared from
payouts page while hashing with 1MH/s mid day,
stopped receiving payments for 20+ hours.

[Arnab biswas]

I'm wondering that as well, see the "GetBlockTemplate
Latency" graph (2nd last graph at the bottom) of these
two nodes:
http://doge.jir.dk:22550/static/graphs.html?Week
http://doge.st/stats/graphs?Week
And these are not the only nodes experiencing this, it
doesn't seem to have resulted in a big spike in dead
hash though, wondering if it's just a fluke or something
is up with p2pool or dogecoind settings.

[organofcorti]

I'm wondering that as well, see the "GetBlockTemplate
Latency" graph (2nd last graph at the bottom) of these
two nodes:
http://doge.jir.dk:22550/static/graphs.html?Week
http://doge.st/stats/graphs?Week
And these are not the only nodes experiencing this, it
doesn't seem to have resulted in a big spike in dead
hash though, wondering if it's just a fluke or something
is up with p2pool or dogecoind settings.

Arnab, this is p2pool for Bitcoin mining pools. You might want to repeat your question somewhere more alt-coiny.

[IYFTech]

I could never get my S3s to work properly on p2pool.

M

I still have a few S3's on my node & they are the most stable out of all the Bitmain hardware I've had. S3's run perfect on p2pool if you use the August 26th firmware (antMiner_S320140826.bin) using queue 0. Every other firmware release is borked in one way or another.

[rav3n_pl]

I`m using latest s3 firmware antMiner_S320150109.bin, just removed this useless 4096 queue from config.

[PatMan]

I`m using latest s3 firmware antMiner_S320150109.bin, just removed this useless 4096 queue from config.

Yeah, it's a crazy queue setting - I'll never understand why they keep setting it at that 

[aurel57]

I could never get my S3s to work properly on p2pool.

M

I still have a few S3's on my node & they are the most stable out of all the Bitmain hardware I've had. S3's run perfect on p2pool if you use the August 26th firmware (antMiner_S320140826.bin) using queue 0. Every other firmware release is borked in one way or another.

My S3's find a lot of shares. My one that was a batch 2 which never wants to run above 420GH does well on getting shares on p2pool.

[IYFTech]

@ aurel57: WTF?

https://bitcointalk.org/index.php?topic=854368.msg10449756#msg10449756

[PatMan]

@ aurel57: WTF?

https://bitcointalk.org/index.php?topic=854368.msg10449756#msg10449756

Ouch!  There's gratitude for ya. Next time aurel57 has a question about p2pool you should be the first to offer not to help him.

What is it with BAN or exBAN miners? First it was fire000 (remember him?  ), since then it seems there's been a steady stream of them trying to implicate things with either p2pool or it's users. It's about time that dodgy pool was put to bed, maybe then it'll stop......

[jedimstr]

Ahem...

[IYFTech]

 

Lemmie see what I canz do........

[windpath]

Ahem...

Lol

[mdude77]

When that happens s, it means 1 of the 4 hash boards has locked up. Used to happen to me every day or 2 with the old firmware. The newly released firmware has completely solved that, all my S4s are working great now. The only issue is 225mhz doesn't work properly on p2pool for some reason, have to drop to 218.

The new firmware will also lower your power consumption as there was previously a bug with 1 of the hash boards being locked at 0750 no matter what you set. Now they're all at 0725.

I'm using the latest firmware...

M