Richy_T
Legendary
Offline
Activity: 2646
Merit: 2349
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
|
October 02, 2013, 04:44:28 AM |
|
Guys, I don't know what's going on but I haven't had a payout in a long time. I think P2Pool version has moved on and I'm sitting mining on my own. I haven't had the time to pay attention recently but every time I've looked at the p2pool screen, it's been happily scrolling along with no apparent warnings. I have no problem with upgrades, I have no problem with obsoleting versions but when we do it, could we make it a bit more obvious, please? It's one thing to pay out more or less than other pools but if you're not paying out at all, that's going to put a dent in things pretty quickly. This is not a demand, just a courteous request. I don't have --give-author set to 0 so you're sharing the love.
|
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
|
|
forrestv (OP)
|
|
October 02, 2013, 04:48:05 AM |
|
Guys, I don't know what's going on but I haven't had a payout in a long time. I think P2Pool version has moved on and I'm sitting mining on my own. I haven't had the time to pay attention recently but every time I've looked at the p2pool screen, it's been happily scrolling along with no apparent warnings. I have no problem with upgrades, I have no problem with obsoleting versions but when we do it, could we make it a bit more obvious, please? It's one thing to pay out more or less than other pools but if you're not paying out at all, that's going to put a dent in things pretty quickly. This is not a demand, just a courteous request. I don't have --give-author set to 0 so you're sharing the love.
In the days before the switch, your P2Pool instance would have been displaying a lot of messages and warnings about the impending change, but once it's happened, your instance is alone with only the other nodes that didn't upgrade and there's no easy way for it to know that it should have upgraded. (I suppose it could see that there are lots of peers with higher version numbers that refuse to talk to it...) You should subscribe to the mailing list mentioned in the first post if you don't obsessively monitor your P2Pool daemon.
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
zkfq12345
Newbie
Offline
Activity: 5
Merit: 0
|
|
October 02, 2013, 06:35:04 AM |
|
” Graphs
Version: 13.3
Pool rate: 15.9TH/s (12% DOA+orphan) Share difficulty: 70300
Node uptime: 39.446 days Peers: 6 out, 0 in
Local rate: 389GH/s (14% DOA) Expected time to share: 0.216 hours
Shares: 1246 total (183 orphaned, 184 dead) Efficiency: 80.54% “
my speed is 82g,but in p2pool.info it show my speed is 66g !
does everyone knows about my speed is slower?
why it show : Efficiency: 80.54% and 66g ?
|
|
|
|
rav3n_pl
Legendary
Offline
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
|
October 02, 2013, 08:55:32 AM |
|
80% of 82G is ~66G...
|
|
|
|
nibor
|
|
October 02, 2013, 09:12:11 PM |
|
Mining with 60Ghash so fine at moment.
At what point would it better for my variance if the pool split into 2?
Currently 2hrs to get a share and 8 for pool to get a block.
Once the pool is getting blocks 3 times more often than I get a share (so I miss out on some payments) would it at that point be benifical for me for the pool to split into 2?
|
|
|
|
maqifrnswa
|
|
October 07, 2013, 02:42:01 PM |
|
Mining with 60Ghash so fine at moment.
At what point would it better for my variance if the pool split into 2?
Currently 2hrs to get a share and 8 for pool to get a block.
Once the pool is getting blocks 3 times more often than I get a share (so I miss out on some payments) would it at that point be benifical for me for the pool to split into 2?
ok, i'll take a shot - this is an approximation, I'm not 100% sure it's analytically correct but it may be close at least... assuming each share solved a day has the same value (i.e., constant pool rate, constant difficulty across the day) Payout events per day = the number of shares you find times the number of shares the pool finds, per day. number of shares you find = your_rate/pool_rate*2880 +/- sqrt(your_rate/pool_rate*2880) number of blocks pool solves = pool_rate/network_rate*144 +/- sqrt(pool_rate/network_rate*144) number of payout events in a day=your_rate/network_rate*414720 variance in payout events = sqrt(your_rate/pool_rate*2880+pool_rate/network_rate*144) variance has a minimum when pool_rate=20*sqrt(your_rate*pool_rate) for a 5 GH/s miner, optimal p2pool hash rate is around 50 TH/s 60 Gh/s, optimal p2pool hashrate is around 175 TH/s i did this on a cell phone, so there probably are errors, but I think it's all there I know of one: payout events per day is actually (# of shares found in a window = 3x the work needed for one block)/(length of a window) However, our window is now 1 day long, approximately on average, so the above approximation holds for the time being
|
|
|
|
gnar1ta$
Donator
Hero Member
Offline
Activity: 798
Merit: 500
|
|
October 07, 2013, 03:32:14 PM |
|
Well Jupiters don't play well with p2pool. They remind me of the early BFL FPGAs, they are extremely slow to recover when they get new work. Anyone have any settings to to try out?
|
Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
|
|
|
lenny_
Legendary
Offline
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
|
|
October 07, 2013, 05:21:57 PM |
|
Well Jupiters don't play well with p2pool. They remind me of the early BFL FPGAs, they are extremely slow to recover when they get new work. Anyone have any settings to to try out?
What's exact stats you're getting? How many DOA?
|
|
|
|
jamesg
VIP
Legendary
Offline
Activity: 1358
Merit: 1000
AKA: gigavps
|
|
October 07, 2013, 05:39:55 PM |
|
Well Jupiters don't play well with p2pool. They remind me of the early BFL FPGAs, they are extremely slow to recover when they get new work. Anyone have any settings to to try out?
What's exact stats you're getting? How many DOA? I am seeing higher stale rates from KNC equipment so it looks like they are not flushing work when the stratum server requests but are instead finishing old work and submitting it.
|
|
|
|
gnar1ta$
Donator
Hero Member
Offline
Activity: 798
Merit: 500
|
|
October 07, 2013, 06:50:17 PM |
|
Right it's not DOA and stales, when it's pushed new work it takes 10 seconds or more to flush and come back up to speed. The miner reports 300 Ghash and the pool reports 350. Not a huge issue on 10 min blocks, but not very good on 30 sec work.
|
Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
|
|
|
lenny_
Legendary
Offline
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
|
|
October 07, 2013, 07:09:36 PM |
|
Christ.... we have another BE BLADE situation here? Can't they do proper LP/work restart implementation?
|
|
|
|
Richy_T
Legendary
Offline
Activity: 2646
Merit: 2349
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
|
October 07, 2013, 09:56:05 PM |
|
You should subscribe to the mailing list mentioned in the first post if you don't obsessively monitor your P2Pool daemon.
Thanks. I'll do that. I've just dropped to another pool until I can get it sorted but I'm a fan of the p2pool concept.
|
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
|
|
-ck
Legendary
Offline
Activity: 4312
Merit: 1649
Ruu \o/
|
|
October 07, 2013, 11:15:11 PM |
|
Christ.... we have another BE BLADE situation here? Can't they do proper LP/work restart implementation? That's what happens when... ah fuck it I'm sick of saying the same shit every time. You all know the drill by now.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
gnar1ta$
Donator
Hero Member
Offline
Activity: 798
Merit: 500
|
|
October 07, 2013, 11:35:56 PM |
|
lol...but we just love to hear you say it Con
|
Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
|
|
|
jamesg
VIP
Legendary
Offline
Activity: 1358
Merit: 1000
AKA: gigavps
|
|
October 07, 2013, 11:48:37 PM |
|
lol...but we just love to hear you say it Con Worst thing KNC has done was to not include Con in their efforts. Such a shame.
|
|
|
|
kano
Legendary
Offline
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 08, 2013, 01:18:30 AM |
|
lol...but we just love to hear you say it Con Anyone seen any GPL3 source code yet?
|
|
|
|
gnar1ta$
Donator
Hero Member
Offline
Activity: 798
Merit: 500
|
|
October 09, 2013, 05:07:51 PM |
|
|
Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
|
|
|
HellDiverUK
|
|
October 09, 2013, 05:12:02 PM |
|
Nice to see that totally unproductive 0.3BTC in your payout queue.
|
|
|
|
kano
Legendary
Offline
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 09, 2013, 10:17:22 PM |
|
Hmm calculation time on your picture Elapsed = 96511s Accepted = 7963136 1diff shares Rejected = 166912 1diff shares Hardware errors = 657472 1diff nonces So Accepted hash rate is 2^32 * Accepted / Elapsed 354.4GH/s Full hash rate (Accepted + Rejected) is 2^32 * (Accepted + Rejected) / Elapsed 361.8GH/s Only one minor comment on those - you can only count the Rejected in the device GH/s if KnC hasn't fucked with the submit_nonce() code and also you can verify that by seeing why the shares were Rejected. As far as I know there's been no sign of the GPL3 code as should have been given to anyone with a KnC who asks for it ... and it must have all versions of the code asked for. Gee ... I wonder if I'll have another Kano vs GitSyncom ... what'll it be called this time ... Kano vs KFC Nom nom. Anyway, now for the fun numbers there ... Hardware % = Hardware / (Accepted + Rejected + Hardware) 7.48% which, BTW, is 29.3GH/s of hardware errors Well at least it's less than the original 16% when they were boasting about how good it was ... lolololol Now ... what are these things supposed to be doing? I'm sure I saw them boasting in that video how they were doing 500GH ... how did it that boasting go ... ? "... Back in May we promised you 250 ... well it's not 250 Then we upped it to 300 ... it's not 300 In June we said 350. We published that on the web site ... it's not 350 (tears paper in half) In August we said 400 ... well it's not 400 (screws up the page and throws it on the floor) We have a 500 machine here for you today and as evidence of the 500 machine we have a laptop in front of us running a full copy of cgminer. We can see here that we are actually achieving, on average, over 500 In fact the theoretical limit is 576+ 576 gigahashes a second and it's fully working and we start shipping today ..."Interesting definition of "fully working" ... So do you feel like telling them to go fuck themselves about the red comments for your hardware? I will add they failed to see that it wasn't even showing 500GH/s on the screen as I pointed out here: https://bitcointalk.org/index.php?topic=170332.msg3276727#msg3276727But of course the most important point being firstly that they seem to think that cgminer showing that on the screen is all the proof they needed. Yay cgminer Pity they wrote the driver and fucked up cgminer's reputation ... well ... we didn't have anything to do with their driver code.
|
|
|
|
matthewh3
Legendary
Offline
Activity: 1372
Merit: 1003
|
|
October 09, 2013, 11:17:19 PM |
|
Hmm calculation time on your picture Elapsed = 96511s Accepted = 7963136 1diff shares Rejected = 166912 1diff shares Hardware errors = 657472 1diff nonces So Accepted hash rate is 2^32 * Accepted / Elapsed 354.4GH/s Full hash rate (Accepted + Rejected) is 2^32 * (Accepted + Rejected) / Elapsed 361.8GH/s Only one minor comment on those - you can only count the Rejected in the device GH/s if KnC hasn't fucked with the submit_nonce() code and also you can verify that by seeing why the shares were Rejected. As far as I know there's been no sign of the GPL3 code as should have been given to anyone with a KnC who asks for it ... and it must have all versions of the code asked for. Gee ... I wonder if I'll have another Kano vs GitSyncom ... what'll it be called this time ... Kano vs KFC Nom nom. Anyway, now for the fun numbers there ... Hardware % = Hardware / (Accepted + Rejected + Hardware) 7.48% which, BTW, is 29.3GH/s of hardware errors Well at least it's less than the original 16% when they were boasting about how good it was ... lolololol Now ... what are these things supposed to be doing? I'm sure I saw them boasting in that video how they were doing 500GH ... how did it that boasting go ... ? "... Back in May we promised you 250 ... well it's not 250 Then we upped it to 300 ... it's not 300 In June we said 350. We published that on the web site ... it's not 350 (tears paper in half) In August we said 400 ... well it's not 400 (screws up the page and throws it on the floor) We have a 500 machine here for you today and as evidence of the 500 machine we have a laptop in front of us running a full copy of cgminer. We can see here that we are actually achieving, on average, over 500 In fact the theoretical limit is 576+ 576 gigahashes a second and it's fully working and we start shipping today ..."Interesting definition of "fully working" ... So do you feel like telling them to go fuck themselves about the red comments for your hardware? I will add they failed to see that it wasn't even showing 500GH/s on the screen as I pointed out here: https://bitcointalk.org/index.php?topic=170332.msg3276727#msg3276727But of course the most important point being firstly that they seem to think that cgminer showing that on the screen is all the proof they needed. Yay cgminer Pity they wrote the driver and fucked up cgminer's reputation ... well ... we didn't have anything to do with their driver code. I've got a Jupiter mining on Slush but one of its boards died on a firmware update. Tho still with only three of the four chips I'm getting an average of 400GH over ten rounds on Slush.
|
|
|
|
|