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
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 216. (Read 2591920 times)
February 13, 2015, 08:55:07 AM
Yeah, it's a crazy queue setting - I'll never understand why they keep setting it at that
February 13, 2015, 07:15:41 AM
I`m using latest s3 firmware antMiner_S320150109.bin, just removed this useless 4096 queue from config.
February 13, 2015, 06:28:26 AM
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.
February 12, 2015, 11:50:52 PM
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.
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.
February 12, 2015, 11:47:03 PM
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.
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.
February 12, 2015, 11:45:19 PM
I disappeared from
payouts page while hashing with 1MH/s mid day,
stopped receiving payments for 20+ hours.
payouts page while hashing with 1MH/s mid day,
stopped receiving payments for 20+ hours.
February 12, 2015, 11:39:43 PM
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.
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.
February 12, 2015, 08:49:04 PM
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.
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
February 12, 2015, 07:57:25 PM
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.
February 12, 2015, 04:50:49 PM
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.
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.
February 12, 2015, 04:01:20 PM
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.
February 12, 2015, 03:58:58 PM
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 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...--expiry|-E
I wrote the code and I'm telling you it doesn't matter.
February 12, 2015, 03:54:42 PM
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.
Was wondering if any one played with the expire settings and did any testing to confirm or deny the claim.
February 12, 2015, 02:58:11 PM
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.
February 12, 2015, 02:39:53 PM
I could not of said that better Jonnie
Ok one question. What are other people seeing the efficiency for share on there node? Mine runs between 15-20% mostly staled shares and every once and a while a single orphaned share. Was just curious if that's the average most have been seeing lately, the longer the node is running the numbers get better. Was thinking about going to a SSD drive but that's down time and cost.
Ok one question. What are other people seeing the efficiency for share on there node? Mine runs between 15-20% mostly staled shares and every once and a while a single orphaned share. Was just curious if that's the average most have been seeing lately, the longer the node is running the numbers get better. Was thinking about going to a SSD drive but that's down time and cost.
I don't see how disk performance (within reason) can effect efficiency. What is effecting the efficiency the most, I think, is the network performance. Well, also single core performance needs to be there, since P2Pool server is single threaded. Not only bandwidth availability, but response time between your nodes is key. Look at your GetBlockTemplate latency. I think my is very low, with a current daily average of 133ms. But I have a dedicated business cable line. Anytime I had any network hiccups, or see increase is GetBlock latency, I see efficiency decline. And I'm not sure about this, but sometimes I think issues are cause by bad nodes connecting to me. Not necessarily malicious nodes, but some problem that drives the network usage much higher than with other nodes.
Back to disk performance. I look at performance reports on my host, which is Linux by the way, and the disk I/O is negligible. I'm seeing less than 10 IOPS to the devices. Full disclosure. I am running SSD (2x RAID-1), so you might think a hypocrite. :-) But I pro-actively bought them and now realize it wasn't necessary. The first thing I would look at is the I/O wait time. If you need some help gathering the data, I can help. Just let me know the OS. And also gather CPU and network stats too.
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
So what did you set your miners to. I an setting up 14 new S5 miners this weekend and am running 7 s3 and retiring 6 S1 and 5 S2 if any one wants to make me a offer on the older s1 and S2. there for sale.
February 12, 2015, 02:36:57 PM
My node is running on a Debian server and the p2pool and bitcoin all are running on all 8 cores. The server is extremely fast. My windows test server node is on a SSD drive and it is allot more efficient then the Debian box.
Has anyone Ghosted a Debian box yet, I have had mixed results with Centos in ghosting. This is my first Debian box.
Looks like it is time order a new SSD drive.
Has anyone Ghosted a Debian box yet, I have had mixed results with Centos in ghosting. This is my first Debian box.
Looks like it is time order a new SSD drive.
February 12, 2015, 02:30:01 PM
I could not of said that better Jonnie
Ok one question. What are other people seeing the efficiency for share on there node? Mine runs between 15-20% mostly staled shares and every once and a while a single orphaned share. Was just curious if that's the average most have been seeing lately, the longer the node is running the numbers get better. Was thinking about going to a SSD drive but that's down time and cost.
Ok one question. What are other people seeing the efficiency for share on there node? Mine runs between 15-20% mostly staled shares and every once and a while a single orphaned share. Was just curious if that's the average most have been seeing lately, the longer the node is running the numbers get better. Was thinking about going to a SSD drive but that's down time and cost.
I don't see how disk performance (within reason) can effect efficiency. What is effecting the efficiency the most, I think, is the network performance. Well, also single core performance needs to be there, since P2Pool server is single threaded. Not only bandwidth availability, but response time between your nodes is key. Look at your GetBlockTemplate latency. I think my is very low, with a current daily average of 133ms. But I have a dedicated business cable line. Anytime I had any network hiccups, or see increase is GetBlock latency, I see efficiency decline. And I'm not sure about this, but sometimes I think issues are cause by bad nodes connecting to me. Not necessarily malicious nodes, but some problem that drives the network usage much higher than with other nodes.
Back to disk performance. I look at performance reports on my host, which is Linux by the way, and the disk I/O is negligible. I'm seeing less than 10 IOPS to the devices. Full disclosure. I am running SSD (2x RAID-1), so you might think a hypocrite. :-) But I pro-actively bought them and now realize it wasn't necessary. The first thing I would look at is the I/O wait time. If you need some help gathering the data, I can help. Just let me know the OS. And also gather CPU and network stats too.
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
February 12, 2015, 01:57:09 PM
A good quality SSD will give you superior results. I run my system on one SSD with my wallets data directory on a separate SSD & I get ~0.5 - 4%. HDD's are pre-historic....... 
February 12, 2015, 01:48:20 PM
Greed, impatience & lust for profit can often temporarily blind people to reality, causing them to wander around from pool to pool in search of faster & greater profits, until eventually their vision has cleared & it becomes clear that not only are there no fast profits to be made in mining, but also that p2pool is the highest paying pool there is anyway.
See you soon Chupacabras
Patman, I never said this is not the best pool. It is just dry cause of the users hoping habits. I will be back when i see stability. Thanks. See you soon Chupacabras
You've been around less than a month and have no concept of how the pool works. You then go ahead and claim instability in the pool due to pool hopping - which both kano and I have explained to you is not what's going on. We've suggested you actually learn how p2pool and PPLNS pools in general work. Your response is to come back and call us stupid and that you can't be bothered "waisting" your time answering.
So go ahead... take your fictional petahash and leave. Don't let the door hit your ass on the way out.
+ ∞
I could not of said that better Jonnie
Ok one question. What are other people seeing the efficiency for share on there node? Mine runs between 15-20% mostly staled shares and every once and a while a single orphaned share. Was just curious if that's the average most have been seeing lately, the longer the node is running the numbers get better. Was thinking about going to a SSD drive but that's down time and cost.
February 12, 2015, 12:12:02 PM
Greed, impatience & lust for profit can often temporarily blind people to reality, causing them to wander around from pool to pool in search of faster & greater profits, until eventually their vision has cleared & it becomes clear that not only are there no fast profits to be made in mining, but also that p2pool is the highest paying pool there is anyway.
See you soon Chupacabras
Patman, I never said this is not the best pool. It is just dry cause of the users hoping habits. I will be back when i see stability. Thanks. See you soon Chupacabras
You've been around less than a month and have no concept of how the pool works. You then go ahead and claim instability in the pool due to pool hopping - which both kano and I have explained to you is not what's going on. We've suggested you actually learn how p2pool and PPLNS pools in general work. Your response is to come back and call us stupid and that you can't be bothered "waisting" your time answering.
So go ahead... take your fictional petahash and leave. Don't let the door hit your ass on the way out.
+ ∞
Jump to: