|
gyverlb (OP)
|
 |
June 23, 2013, 07:41:05 PM |
|
do you have to use stratum? it has some 1/2 second delay or so for me it looks like whatever you're using has 1500-2000ms latency. so we'll be optimistic and consider that 15% DOA. now, can you set up your pool so you have 5% or less orphans? probably not with 6 outgoing connections and 0 incoming i don't understand why people run pools locally when they'd be better off using a remote server. i ran mine locally for about 2 days zvs, your experience is only showing what works for you and may not apply to others, it must be compared to other results to be meaningful. Based on what we already know, the right choice depends on what your options are and is a bit difficult to find: by moving the node to a remote server you save on the bandwidth used on your local connection (miner <-> node traffic is very low compared to node <-> P2Pool network traffic) but you may add a bit of latency to your setup (miner <-> P2Pool network traffic is routed through the remote host you choose). If you don't have any local bandwidth problems, using a remote node adds latency to your setup. That said if you chose the remote node right this additional latency might be negligible and even be compensated by other gains. For example if your remote node has more CPU power available for bitcoind and P2Pool you can get an advantage there. If you have local bandwidth problems, using a remote node might be a safe bet, but using a public node will either decrease the fees P2Pool users get or add latency. The best solution then is a dedicated node (until there's a fix for the high latencies with multi-payout addresses on a single node case). |
|
|
|
|
|
|
|
|
|
|
|
|
"There should not be any signed int. If you've found a signed int
somewhere, please tell me (within the next 25 years please) and I'll
change it to unsigned int." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
gyverlb (OP)
|
|
June 23, 2013, 07:50:47 PM |
|
Guide updated for conflicting reports about BFL ASICs and one success report for ASICMINER Block Erupter blades.
Hi, I'm the newbie mentioned. Thanks for updating the guide with my findings. Hopefully more users will try their BFL ASICs on P2Pool as they get them and we can get more evidence either way. Hope so, sorry if I look paranoid, but it seems that sockpuppetting is an official bitcointalk sport now and there's big money involved: if a vendor looks bad on P2Pool even if we aren't a big pool it probably can reflect on sales. FWIW my local DOA rate is high (Local rate: 5.64GH/s (22% DOA) Expected time to share: 0.206 hours) but my efficiency has been fine (Shares: 43 total (3 orphaned, 3 dead) Efficiency: 105.6%). The only change I have done over stock cgminer is I run it with username/6000 to increase the share difficulty. This was suggested by a user on the BFL forums.
If you have any questions or want me to share anymore information I'd be happy to.
Hum, are you sure you changed your share difficulty in the screenshots you published? Your expected share interval doesn't match a 6000 difficulty with a 5.5GH/s device but matches the current ~1000 difficulty. 43 shares isn't bad for estimating efficiency, but 100 would be better (the confidence interval is still 89-115 in your screenshot). With your hashrate, waiting for one or 2 whole days instead of ~10 hours would help estimate your actual efficiency. |
|
|
|
|
gyverlb (OP)
|
|
June 23, 2013, 07:56:55 PM |
|
I'm sorry I didn't do the digging to figure it out for you. It appears it is raising the share difficulty that saves your efficiency. I just figured you were the expert and could figure it out easier. Sorry for wasting your time. I clearly keyed in on an incorrect statement, which caused you to dismiss everything I had to say.
Sorry if I look a bit harsh, but I don't spend much time on bitcointalk right now: I have a lot of work currently and I'm slowly recovering from a broken back at the same time so if I even suspect I won't find useful information I don't dig to save time. The meds I take may not help either: they are known to have several side effects on the mood and short-temper is one (I may be predisposed for this one...). Raising share difficulty may not be the solution: as I wrote in the previous post the published results match a configuration with standard share difficulty. |
|
|
|
bitpop
Legendary
 Offline
Activity: 2912
Merit: 1060
|
|
June 24, 2013, 03:23:50 AM |
|
|
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
June 24, 2013, 07:58:31 AM |
|
I'm sorry I didn't do the digging to figure it out for you. It appears it is raising the share difficulty that saves your efficiency. I just figured you were the expert and could figure it out easier. Sorry for wasting your time. I clearly keyed in on an incorrect statement, which caused you to dismiss everything I had to say.
Sorry if I look a bit harsh, but I don't spend much time on bitcointalk right now: I have a lot of work currently and I'm slowly recovering from a broken back at the same time so if I even suspect I won't find useful information I don't dig to save time. The meds I take may not help either: they are known to have several side effects on the mood and short-temper is one (I may be predisposed for this one...). Raising share difficulty may not be the solution: as I wrote in the previous post the published results match a configuration with standard share difficulty. I'm sorry to hear that. I truly wish you have a speedy recovery. Thank you for updating the guide to be less discouraging for BFL owners. P2Pool is experiencing very long block times and if BFL hardware can potentially help with that we should certainly admit it is complicated, but not actively discourage them from trying. |
|
|
|
|
|
|
gyverlb (OP)
|
|
June 24, 2013, 06:47:33 PM |
|
Future changes will indeed be a game-changer for miners with high latencies (mainly Avalon and BFL ASICs). If you read this and are/were discouraged by low Avalon or BFL efficiency, please watch this thread and/or the main P2Pool thread to be notified when the fork becomes active, testing P2Pool after that will probably change your results for the better. |
|
|
|
|
gyverlb (OP)
|
|
June 24, 2013, 06:53:08 PM |
|
Re: p2pool and BFL SCs There appears to have been a recent change to the firmware from one job per board to one job per chip https://forums.butterflylabs.com/announcements/692-bfl-asic-status-3.html#post43041They claim, "This has fixed a lot of the latency issues we were experiencing with the early firmware." jalepenos only have 2 chips, so at best this is a factor of 2... Anyways, the new p2pool release should help a bit too. Does not compute in our case. If you suppose you can't interrupt a job, having one per board is better as it finishes faster. So either Josh didn't understand at all and the switch was from one per chip to one per board (which would be good for P2Pool) or they solved a problem completely different from what was spotted by ckolivas (and it's probably bad for P2Pool, you might not want to update your firmware unless you can downgrade it later). |
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
June 25, 2013, 07:53:06 PM |
|
Re: p2pool and BFL SCs There appears to have been a recent change to the firmware from one job per board to one job per chip https://forums.butterflylabs.com/announcements/692-bfl-asic-status-3.html#post43041They claim, "This has fixed a lot of the latency issues we were experiencing with the early firmware." jalepenos only have 2 chips, so at best this is a factor of 2... Anyways, the new p2pool release should help a bit too. Does not compute in our case. If you suppose you can't interrupt a job, having one per board is better as it finishes faster. So either Josh didn't understand at all and the switch was from one per chip to one per board (which would be good for P2Pool) or they solved a problem completely different from what was spotted by ckolivas (and it's probably bad for P2Pool, you might not want to update your firmware unless you can downgrade it later). EDIT: Come to think of it, you are probably right since the chips should compute nonce ranges in very close to the same amount of time, so I'm happy if you ignore this. I'll just post in case anyone else has a similar objection. Are you sure about that? Needing to reset work is a stochastic event and thus each chip will be somewhere in the range from just starting to almost done. You are very clearly right if all chips are synchronized, but I'm not sure they are. I'm a bit weak on stats, so I'm not sure here. I could probably review a proof, but if I had to prove it either way myself, I would probably just do a monte carlo simulation. |
|
|
|
|
daemondazz
|
|
June 26, 2013, 12:58:44 AM |
|
It would be a maximum of twice as responsive for the jallies, assuming each chip starts work 180 degrees from each other.
|
Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
June 26, 2013, 01:35:40 AM |
|
It would be a maximum of twice as responsive for the jallies, assuming each chip starts work 180 degrees from each other.
And potentially much better with the rigs with higher chip counts, but in practice they would likely be fairly close to synced, so the improvement would be small if it even surpassed the extra overhead. |
|
|
|
Mr. Jinx
Member
Offline
Activity: 112
Merit: 10
|
|
June 29, 2013, 10:11:29 AM
Last edit: June 29, 2013, 12:46:31 PM by Mr. Jinx |
|
I have a question about DOA's and efficiency.
With p2pool scrypt-mining (ltc) I get a local rate of 2MH/s with 20% DOA. This is with intensity in cgminer set at 20.
If I lower intensity to 17, the local rate drops to 1.8MH/s with DOA 3%.
In both cases, efficiency is 100%+
Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?
|
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
June 29, 2013, 11:49:44 AM |
|
1.8MH/s with 3% DOA
|
|
|
|
|
daemondazz
|
|
June 30, 2013, 04:22:50 AM |
|
Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?
The math is pretty simple: 2MH/s - 20% = 1.6MH/s effective 1.8MH/s - 3% = 1.747MH/s effective |
Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
|
|
|
|
gyverlb (OP)
|
|
June 30, 2013, 08:55:30 AM |
|
Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?
The math is pretty simple: 2MH/s - 20% = 1.6MH/s effective 1.8MH/s - 3% = 1.747MH/s effective The OP on this particular subject should do the math for intensity 18 and 19 too. I'll guesstimate that 19 should be the right spot. Edit: BTW, as soon as the P2Pool network you are on switch to a 30s block interval (BTC and LTC will) all these computations will have to be done again. |
|
|
|
Mr. Jinx
Member
Offline
Activity: 112
Merit: 10
|
|
June 30, 2013, 09:17:38 AM |
|
Thanks for clarifying! There was some confusion in this thread where someone said DOA's are not wasted work and can still payout. |
|
|
|
|
|
maqifrnswa
|
|
June 30, 2013, 01:39:15 PM |
|
I have a question about DOA's and efficiency.
With p2pool scrypt-mining (ltc) I get a local rate of 2MH/s with 20% DOA. This is with intensity in cgminer set at 20.
If I lower intensity to 17, the local rate drops to 1.8MH/s with DOA 3%.
In both cases, efficiency is 100%+
Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?
DOA shares do payout and don't necessarily negatively affect payout (as long as you have < average DOA) but in the case of a difference of 3% and 20% - that should affect payout. In both cases efficiency is > 100%, but were they the same? Please correct me if I'm wrong, but shouldn't the real calculation be: 2MH/s x efficiency = effective rate 1.8MH/s x efficiency = effective rate Not MH/s - doa% = effective rate |
|
|
|
|
|
gyverlb (OP)
|
|
June 30, 2013, 05:13:56 PM |
|
Thanks for clarifying! There was some confusion in this thread where someone said DOA's are not wasted work and can still payout. DOAs aren't wasted work and can still generate a valid block which would pay everyone. However DOAs aren't used to compute the share of a miner in the payouts, only shared accepted in the sharechain. This is explained in more details in the original post of this thread. |
|
|
|
|
abbeytim
|
|
June 30, 2013, 09:15:38 PM |
|
hi I have a question p2pool is sending my miner diff 1 shares and I want it to send the p2pool diff
now somewhere I read you could put /1000 next to the miners name so I tried user/1000 and its still getting diff 1 shares from p2pool
|
|
|
|
|
|
gyverlb (OP)
|
|
July 02, 2013, 10:51:55 PM |
|
hi I have a question p2pool is sending my miner diff 1 shares and I want it to send the p2pool diff
now somewhere I read you could put /1000 next to the miners name so I tried user/1000 and its still getting diff 1 shares from p2pool
This is a question better asked in the main P2Pool thread (see first post for a link). |
|
|
|
|
