-ck
Legendary
 Offline
Activity: 4088
Merit: 1631
Ruu \o/
|
 |
July 16, 2015, 10:12:43 AM |
|
Wow guys - that's some blocktastic green run you've got going on there, well done! Do you think it's because of your modifications -ck mentioned earlier?: Gimme gimme........   The modifications are custom and private, sorry  Pools need to have some advantage. I'm intrigued...... No |
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
|
|
|
|
|
|
|
|
|
|
The forum strives to allow free discussion of any ideas. All policies are built around this principle. This doesn't mean you can post garbage, though: posts should actually contain ideas, and these ideas should be argued reasonably.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
p3yot33at3r
|
|
July 16, 2015, 10:44:51 AM |
|
Luck it is then...... |
|
|
|
|
-ck
Legendary
Offline
Activity: 4088
Merit: 1631
Ruu \o/
|
|
July 16, 2015, 10:46:28 AM |
|
Luck it is then...... Yes |
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
|
|
|
kano (OP)
Legendary
Offline
Activity: 4480
Merit: 1800
Linux since 1997 RedHat 4
|
|
July 16, 2015, 01:24:03 PM
Last edit: July 16, 2015, 01:39:10 PM by kano |
|
Wow guys - that's some blocktastic green run you've got going on there, well done! Do you think it's because of your modifications -ck mentioned earlier?: Gimme gimme........ The modifications are custom and private, sorry Pools need to have some advantage. I'm intrigued...... Well ... actually ... it is valid to say it affects the % luck of the pool. There is a problem in the bitcoin world of saying what the pool's luck is. Although you would statistically expect that over a long period of time, the pool's accepted hashes would approach the expected: 100% luck, that isn't completely true. There are factors that reduce the number of blocks found. Specifically orphans. Some pools have long term bad luck because they are slow at handling block changes and lose more blocks because of that. Eligius is an example of this There were also pools that counted stale shares for a short period of time after the block change had occurred. While this makes the pool look better by lowering and lying about their reject statistics, it also has the long term effect of lowering the pool luck. Not sure which pools do this. One pool in particular doesn't count all the hashes used to produce it's blocks and thus reports luck higher than it really is. P2Pool The change does have a long term affect on our % luck, but it doesn't affect what is really 'Luck' - which isn't exactly what pools report  However, it is also true to simply say that running ckpool has a long term effect on the % luck since it handles block changes very fast. |
|
|
|
|
pekatete
|
|
July 16, 2015, 01:49:01 PM |
|
The change does have a long term affect on our % luck, but it doesn't affect what is really 'Luck' - which isn't exactly what pools report However, it is also true to simply say that running ckpool has a long term effect on the % luck since it handles block changes very fast. I've actually had the same thing on my mind since ck posted the message about the changes made (I believe that was during the "attack" on the network). I won't speculate as to what the changes may have been as it is to a large extent over my head, but suspected the changes would reduce the variance of the pool's luck (ultimately, as you say, seemingly improving the pool's luck, ie smooth it). Now I know ck said those changes are being kept for the pool to have a better advantage over other solo pools, but wouldn't adding (some of) those features to a distributed proxy (which I believe distributed ck pool code has) go even further to improve / smooth the pool's luck to all our benefit? (just a thought ...) |
|
|
|
kano (OP)
Legendary
Offline
Activity: 4480
Merit: 1800
Linux since 1997 RedHat 4
|
|
July 16, 2015, 08:57:16 PM |
|
Well ... we did an hour and a half ago Payouts 365491 and 365509 sent f9811d479993f1cdfc2030ac9bdc9a4a79aa91c2b60aae1d2aea84bb82c40940 8e37ec2c2cbc6ac1877153c4dd7aede4341535f8271c3065e30e6e191e734ccf and both confirmed |
|
|
|
|
PPOC
|
|
July 17, 2015, 01:35:25 AM |
|
Well ... we did an hour and a half ago Payouts 365491 and 365509 sent f9811d479993f1cdfc2030ac9bdc9a4a79aa91c2b60aae1d2aea84bb82c40940 8e37ec2c2cbc6ac1877153c4dd7aede4341535f8271c3065e30e6e191e734ccf and both confirmed So whats the odds of keeping the luck at over 200% for the next 10 block with such a good luck streak over the last 10 block, or 25 and 50 for that matter....... |
BTC: 1Bo6YsPeHCrVRygHLJg9BwHeaLSQpppcJi
"Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone."
|
|
|
|
LoneRangir
|
|
July 17, 2015, 01:39:50 AM |
|
Not sure the odds, but we found another one!
|
|
|
|
|
|
WBF1
|
|
July 17, 2015, 01:50:55 AM |
|
Wow guys - that's some blocktastic green run you've got going on there, well done! Do you think it's because of your modifications -ck mentioned earlier?: Gimme gimme........ The modifications are custom and private, sorry Pools need to have some advantage. I'm intrigued...... Well ... actually ... it is valid to say it affects the % luck of the pool. There is a problem in the bitcoin world of saying what the pool's luck is. Although you would statistically expect that over a long period of time, the pool's accepted hashes would approach the expected: 100% luck, that isn't completely true. There are factors that reduce the number of blocks found. Specifically orphans. Some pools have long term bad luck because they are slow at handling block changes and lose more blocks because of that. Eligius is an example of this There were also pools that counted stale shares for a short period of time after the block change had occurred. While this makes the pool look better by lowering and lying about their reject statistics, it also has the long term effect of lowering the pool luck. Not sure which pools do this. One pool in particular doesn't count all the hashes used to produce it's blocks and thus reports luck higher than it really is. P2Pool The change does have a long term affect on our % luck, but it doesn't affect what is really 'Luck' - which isn't exactly what pools report However, it is also true to simply say that running ckpool has a long term effect on the % luck since it handles block changes very fast. So it may lead to a better "luck" the metric but has no impact on "Luck" the abstract concept of things seeming to go your way. |
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4480
Merit: 1800
Linux since 1997 RedHat 4
|
|
July 17, 2015, 02:35:35 AM |
|
Well ... we did an hour and a half ago Payouts 365491 and 365509 sent f9811d479993f1cdfc2030ac9bdc9a4a79aa91c2b60aae1d2aea84bb82c40940 8e37ec2c2cbc6ac1877153c4dd7aede4341535f8271c3065e30e6e191e734ccf and both confirmed So whats the odds of keeping the luck at over 200% for the next 10 block with such a good luck streak over the last 10 block, or 25 and 50 for that matter....... Well in the simplest terms ... For the 5 block luck to stay the same or be better, the new block found must be the same or better than the current 5th block. i.e. the 5 block range drops one off the end when it adds a new one on the front. That's of course the same for each of the block ranges (except the "All" blocks one) How much the range luck will change will depend on the luck of the new block found vs the one dropped off the end of the range. |
|
|
|
kano (OP)
Legendary
Offline
Activity: 4480
Merit: 1800
Linux since 1997 RedHat 4
|
|
July 17, 2015, 10:48:11 PM |
|
Payout 365602 sent
0469d434de8bfc6561e6eb9c440e8eb1885d5a38b3b779ff6b646e6e4615a5a1
and confirmed
Payout 365637 sent 39ac3b69b3b158a659f72cb061689da7844d6d6f80dd6150127a82e93e5ff6a3 and confirmed |
|
|
|
kano (OP)
Legendary
Offline
Activity: 4480
Merit: 1800
Linux since 1997 RedHat 4
|
|
July 17, 2015, 10:55:24 PM |
|
...
So whats the odds of keeping the luck at over 200% for the next 10 block with such a good luck streak over the last 10 block, or 25 and 50 for that matter.......
To answer that in terms of a run of blocks, (which I didn't in the last answer ...) Well, firstly, the previous 5, 10, 25 have no effect on the next 5, 10, 25. But the CDF[Erl] of the block range gives you insight into the chances of getting the current value ... and of course the chance of repeating the same performance at the end of the next N blocks |
|
|
|
Dmc123dmc
Member
Offline
Activity: 70
Merit: 10
Time is the one thing you can't run from
|
|
July 18, 2015, 08:34:44 AM |
|
Hi Kano, since BTCGUILD closed down i have used a few pools but none that made me want to stick with them. I happened upon this thread and your attitude and honesty have won me over so i'm pointing my s3+'s at your pool and will keep them there. I see you have written some modifications for the s3 but i can't seem to find the all the information. Is there a thread that explains it fully? Are there any performance gains or is it mainly a graphical change? Thanks in advance!
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4480
Merit: 1800
Linux since 1997 RedHat 4
|
|
July 18, 2015, 12:18:33 PM |
|
Hi Kano, since BTCGUILD closed down i have used a few pools but none that made me want to stick with them. I happened upon this thread and your attitude and honesty have won me over so i'm pointing my s3+'s at your pool and will keep them there. I see you have written some modifications for the s3 but i can't seem to find the all the information. Is there a thread that explains it fully? Are there any performance gains or is it mainly a graphical change? Thanks in advance!
Firstly the AntS3 README is here: https://github.com/kanoi/cgminer-binaries/tree/master/AntS3One big change I've added since I merged in the S3 changes into master git is to reduce CPU usage. You'll find the Load Average spends most of it's time under 1.0 - and that change is advantageous, not harmful. I basically removed a major CPU waste, doing something unnecessary. There are a bunch of issues with the bitmain fork of cgminer, which are not in the master cgminer of course. They are actually listed in the S2 README: https://github.com/kanoi/cgminer-binaries/tree/master/AntS2down at the initial release Master cgminer doesn't have the Best Share of Diff setting problem either (they added that problem to some of their versions) Also, of course, it's the latest cgminer 4.9.2 which means it has all the latest cgminer fixes The update is not a flash change, just a few reasonably simple steps to extract an archive into the Ant The archive file is simply a gzipped tar of the changes that are all effectively the source code except for the cgminer binary itself. The web interface changes are listed in the AntS3 README, the most important one being you can see and modify the API allow settings to make it secure. Since you have an S3+ make sure you check what your settings are in the Advanced Tab before you update and set/save them again after the update. However it's easy to see what settings my version is running since I also display them at the bottom of the Miner Status web page |
|
|
|
Dmc123dmc
Member
Offline
Activity: 70
Merit: 10
Time is the one thing you can't run from
|
|
July 18, 2015, 01:58:47 PM |
|
Hi Kano, since BTCGUILD closed down i have used a few pools but none that made me want to stick with them. I happened upon this thread and your attitude and honesty have won me over so i'm pointing my s3+'s at your pool and will keep them there. I see you have written some modifications for the s3 but i can't seem to find the all the information. Is there a thread that explains it fully? Are there any performance gains or is it mainly a graphical change? Thanks in advance!
Firstly the AntS3 README is here: https://github.com/kanoi/cgminer-binaries/tree/master/AntS3One big change I've added since I merged in the S3 changes into master git is to reduce CPU usage. You'll find the Load Average spends most of it's time under 1.0 - and that change is advantageous, not harmful. I basically removed a major CPU waste, doing something unnecessary. There are a bunch of issues with the bitmain fork of cgminer, which are not in the master cgminer of course. They are actually listed in the S2 README: https://github.com/kanoi/cgminer-binaries/tree/master/AntS2down at the initial release Master cgminer doesn't have the Best Share of Diff setting problem either (they added that problem to some of their versions) Also, of course, it's the latest cgminer 4.9.2 which means it has all the latest cgminer fixes The update is not a flash change, just a few reasonably simple steps to extract an archive into the Ant The archive file is simply a gzipped tar of the changes that are all effectively the source code except for the cgminer binary itself. Thanks for clarifying. Updated the first one and about to update the second with no issues. The web interface changes are listed in the AntS3 README, the most important one being you can see and modify the API allow settings to make it secure. Since you have an S3+ make sure you check what your settings are in the Advanced Tab before you update and set/save them again after the update. However it's easy to see what settings my version is running since I also display them at the bottom of the Miner Status web page Thanks for clarifying and pointing me to your github. First one done with no issues and about to do the second. |
|
|
|
elduderino
Full Member
Offline
Activity: 143
Merit: 100
Using some expensive heaters
|
|
July 18, 2015, 11:26:08 PM |
|
Hi,
Just a quick question for anyone who's mining on the pool right now:
Is all your hashing showing up? Just double-checking if it's just a problem with my hosted miners or the pool.
Thanks!
|
Do the things you know you must do first, then worry about the stuff you're not sure about.
|
|
|
thedreamer
Legendary
Offline
Activity: 1694
Merit: 1002
Go Big or Go Home.....
|
|
July 18, 2015, 11:36:51 PM |
|
Yeah that's fine. Although ck broke the pool with his update. We haven't had a block solve since. Can we start the hourly restarts? Lol |
Go Big or Go Home.
|
|
|
elduderino
Full Member
Offline
Activity: 143
Merit: 100
Using some expensive heaters
|
|
July 18, 2015, 11:41:44 PM |
|
Yeah that's fine. Although ck broke the pool with his update. We haven't had a block solve since. Can we start the hourly restarts? Lol Lol, I'm all for it! Thanks, bud. |
Do the things you know you must do first, then worry about the stuff you're not sure about.
|
|
|
kano (OP)
Legendary
Offline
Activity: 4480
Merit: 1800
Linux since 1997 RedHat 4
|
|
July 19, 2015, 01:37:18 AM |
|
Well from the mining side you shouldn't be mining to an IP address I'll look into seeing what they say about the rdns ... |
|
|
|
kano (OP)
Legendary
Offline
Activity: 4480
Merit: 1800
Linux since 1997 RedHat 4
|
|
July 19, 2015, 03:31:04 AM |
|
Well from the mining side you shouldn't be mining to an IP address I'll look into seeing what they say about the rdns ... I wasn't doing any mining, just troubleshooting slowdowns and 'website access denied' problems on a completely unrelated web sites. I've accidentally found that your has the same problem as the other ones. This could cause you (and your members) problems as the most common symptom was 'slowdown', not 'doesn't work anymore', depending on the firewall setup on the miner's end. Yeah they'll be updated soon. I'm not exactly sure if they did it on purpose or by mistake for the defaults - though I did ask them but they skipped that question among the rest. I've sent them updates but they also initially just removed the '$' characters so that should be resolved now or some time in the next 24hrs or so. I've not actually had anyone ask about slow web access. The web site it very fast ... most of the time ... by design |
|
|
|
|
