SergES
Member
Offline
Activity: 81
Merit: 10
|
|
February 11, 2016, 06:19:57 PM |
|
I noticed that, constant diff (for S7 set 20k in "Workers\Management"):
397438 8/Feb 22:10 24.96438632 730.646G 39hr 58m 56s 21.80PHs 0.06% 415.474M 12.40THs 397279 7/Feb 20:48 24.94621895 721.188G 40hr 28m 43s 21.26PHs 0.06% 420.763M 12.40THs 397238 7/Feb 15:52 24.80670238 724.086G 41hr 2m 34s 21.05PHs 0.06% 426.759M 12.41THs
and variable (vardiff "0"):
397818 11/Feb 03:05 25.28178578 731.051G 41hr 10m 46s 21.18PHs 0.06% 414.693M 12.01THs 397747 10/Feb 16:59 25.21331413 727.871G 41hr 17m 54s 21.03PHs 0.06% 415.750M 12.01THs 397723 10/Feb 13:25 24.93550825 721.073G 40hr 49m 32s 21.07PHs 0.06% 411.102M 12.01THs
but what better, fixed diff or vardiff?
Neither of those are related directly to hash rate. They are related directly, only, to how much of the elapsed time of the 5Nd you mined, which may not have been the full time depending upon various circumstances with your miner and the pool. Edit: or you could just look at the pool graph and see a spike down that is part of the 2nd 3 and not part of the first 3 See here: https://bitcointalk.org/index.php?topic=789369.msg13831674#msg13831674Lastly you will also note that your % is the same for each of the 6 - try checking that to a few extra places. That would give the same explanation also. It blocks a row, not selectively, I do not think that a row spike down 3-5 bloks... Left select - fixed diff, right select - 0(vardiff) Actually, since this is a 5Nd pool, any large spike up or down will have an effect on the next 3-5 blocks...that's how 5Nd works. Bottom line is over the long haul it will not matter which way you set it so pick vardiff or fixed diff and have at it. The default is vardiff and it has worked well for me over time. I personally trust kano and ck to know how to run the best pool environment possible...bar none! I am trust too, in case of replace the pool...See: 397818 11/Feb 03:05 25.28178578 731.051G 41hr 10m 46s 21.18PHs 0.06% 414.693M 12.01THs 397747 10/Feb 16:59 25.21331413 727.871G 41hr 17m 54s 21.03PHs 0.06% 415.750M 12.01THs 397723 10/Feb 13:25 24.93550825 721.073G 40hr 49m 32s 21.07PHs 0.06% 411.102M 12.01THs 397649 10/Feb 02:39 25.02525347 724.414G 40hr 45m 48s 21.20PHs 0.06% 414.845M 12.14THs 397628 10/Feb 00:22 25.10738938 726.052G 40hr 50m 25s 21.21PHs 0.06% 417.485M 12.20THs 397511 9/Feb 08:26 25.10888855 726.812G 39hr 47m 13s 21.79PHs 0.06% 412.734M 12.38THs 397486 9/Feb 04:55 24.94781485 734.550G 40hr 13m 30s 21.79PHs 0.06% 418.219M 12.40THs 397438 8/Feb 22:10 24.96438632 730.646G 39hr 58m 56s 21.80PHs 0.06% 415.474M 12.40THs 397279 7/Feb 20:48 24.94621895 721.188G 40hr 28m 43s 21.26PHs 0.06% 420.763M 12.40THs 397238 7/Feb 15:52 24.80670238 724.086G 41hr 2m 34s 21.05PHs 0.06% 426.759M 12.41THs Blocks 397238-397486 fixed diff, rest changed when to vardiff...less and less...why have a question that is best...And other, when put into difficulty 0, in the asic diff is not changed, but 02.10.2016 when the pool is not working some time asic's changed diff, vardiff turn on...This put on one's guard what is a better.
|
|
|
|
zOU
|
|
February 11, 2016, 06:21:42 PM |
|
|
|
|
|
nhando
|
|
February 11, 2016, 06:23:58 PM |
|
Kano better upgrade his server fast!! That's a lot of FIREPOWER!!! Hope you get the next block ZOU....... Those Compac sticks are fun.
|
Just "Mining" my own business.
|
|
|
zOU
|
|
February 11, 2016, 06:26:22 PM |
|
Kano better upgrade his server fast!! That's a lot of FIREPOWER!!! Hope you get the next block ZOU....... Those Compac sticks are fun. I do not want to hit a block or i'll regret forever no leaving them on solo :p Lol
|
|
|
|
nhando
|
|
February 11, 2016, 06:27:58 PM Last edit: February 11, 2016, 06:42:36 PM by nhando |
|
26PH BABY!!!!!!!!!!!!!!!!!!!!!!! We're on our road to 40PHHHHH
10% in 41mins. This means a block in roughly 7hrs on average at this rate. More excitement..........WOOT.
|
Just "Mining" my own business.
|
|
|
thedreamer
Legendary
Offline
Activity: 1694
Merit: 1002
Go Big or Go Home.....
|
|
February 11, 2016, 08:16:47 PM |
|
Kano better upgrade his server fast!! That's a lot of FIREPOWER!!! Hope you get the next block ZOU....... Those Compac sticks are fun. I do not want to hit a block or i'll regret forever no leaving them on solo :p Lol Heheh, never think like that. Don't forget, Hindsight is always 20/20.
|
Go Big or Go Home.
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
February 11, 2016, 08:34:10 PM |
|
I do not want to hit a block or i'll regret forever no leaving them on solo :p
Well don't feel too bad if they do hit a block on Kano.is, because that doesn't necessarily mean they would have hit a block on cksolo or anywhere else. Every hash has the same chance as the next at solving one no matter where it's pointed.
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
February 11, 2016, 09:56:14 PM |
|
I'll be implementing unwanted events and access limitations in ckdb code today or tomorrow. (that's what I've been working on over the last week or so) Basically, failure events or excessive access events will trigger 2 things: firstly to simply reply without any data requested, for all requests, for a specific amount of time, after any event limit is exceeded and secondly to temporarily (hours or days) ban IP addresses that exceed certain event limits that I deem require an IP ban In the past I've done most of this 'somewhat' manually. This will completely automate the process. The code is not in git yet, since I'm still making code adjustments, but it will all be there, but without showing the limits I'll use, since that will be, of course, data in the database, not fixed limits in the code. The design is very much 'guilty until proven innocent' There's no issue with the web site at the moment, though about once a week someone tries to hack into it and always fails (and always will fail) There's also been a few 'annoying' attacks at the web site (that also will always fail) that this will stop dead in their tracks as soon as they start. Web hit rate is over 400k a day, and that isn't using up much CPU at all since ckdb is very fast at getting the data and the web design is very quick and returns a tiny amount of web data to produce the web page. I'd expect there to be no problem to even have a hit rate 10 times that a day, since the current doesn't even show a blip on the CPU usage. ... yet, the data you get from the web site is always the current live data to the second
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
February 11, 2016, 09:56:59 PM Last edit: February 11, 2016, 10:09:51 PM by kano |
|
Kano better upgrade his server fast!! That's a lot of FIREPOWER!!! Hope you get the next block ZOU....... Those Compac sticks are fun. I do not want to hit a block or i'll regret forever no leaving them on solo :p Lol That will never happen since the hash that finds a block here, will not produce a block anywhere else. It has a one in 6.2x10^20 chance of producing a block somewhere else Edit: or to put that 2 decimal place accurate ... 1 in 620000000000000000000
|
|
|
|
PPOC
|
|
February 11, 2016, 10:10:35 PM |
|
Kano better upgrade his server fast!! That's a lot of FIREPOWER!!! Hope you get the next block ZOU....... Those Compac sticks are fun. I do not want to hit a block or i'll regret forever no leaving them on solo :p Lol That will never happen since the hash that finds a block here, will not produce a block anywhere else. (it has a one in 6.2x10^20 chance of producing a block somewhere else) So, what you're saying is thats it possible then..... Movie quote, forget which one. I think Dumb and Dumber
|
BTC: 1Bo6YsPeHCrVRygHLJg9BwHeaLSQpppcJi "Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone."
|
|
|
kano (OP)
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
February 11, 2016, 10:12:30 PM |
|
Kano better upgrade his server fast!! That's a lot of FIREPOWER!!! Hope you get the next block ZOU....... Those Compac sticks are fun. I do not want to hit a block or i'll regret forever no leaving them on solo :p Lol That will never happen since the hash that finds a block here, will not produce a block anywhere else. (it has a one in 6.2x10^20 chance of producing a block somewhere else) So, what you're saying is thats it possible then..... Movie quote, forget which one. I think Dumb and Dumber Yes it is also possible for this pool to find 10 blocks in 10 minutes. I wonder how often that has happened ... ...
|
|
|
|
PPOC
|
|
February 11, 2016, 10:30:32 PM |
|
Doing a 2.5PH rental hoping to crack this block sooner rather then later. Hope it works!
|
BTC: 1Bo6YsPeHCrVRygHLJg9BwHeaLSQpppcJi "Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone."
|
|
|
estemaire
Newbie
Offline
Activity: 18
Merit: 0
|
|
February 11, 2016, 10:39:38 PM |
|
Started pointing my rented power here a day or so ago, don't know why I didn't do it earlier. Rental is >7 days, all part of my little experiment to burn some bits to see if I can swing a profit Bring on another block!
|
|
|
|
os2sam
Legendary
Offline
Activity: 3586
Merit: 1098
Think for yourself
|
|
February 11, 2016, 10:55:42 PM |
|
I'll be implementing unwanted events and access limitations in ckdb code today or tomorrow. (that's what I've been working on over the last week or so)
Good to see improvements continually coming. Any progress on the single payment per 24 hour period? My payments are getting really small and having them grouped will be nice. Thanks, Sam
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
kano (OP)
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
February 11, 2016, 10:59:16 PM |
|
I'll be implementing unwanted events and access limitations in ckdb code today or tomorrow. (that's what I've been working on over the last week or so)
Good to see improvements continually coming. Any progress on the single payment per 24 hour period? My payments are getting really small and having them grouped will be nice. Thanks, Sam That's probably second on the todo list after some more performance changes. This "event limit" change was something I've been thinking about for quite a while and started coding last week thinking that it would be better to have it now rather than 'after something unexpected happens' since the pool is growing so fast. Funnily enough an event occurred a few days later that made me decide to complete it before anything else
|
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
February 11, 2016, 11:40:01 PM |
|
Any progress on the single payment per 24 hour period? My payments are getting really small and having them grouped will be nice.
That's probably second on the todo list after some more performance changes. If all of a user's dust rewards for a single day total more than 0.0001btc will they be paid under the new once-per-day payment scheme? Or since each single reward is less than 10,000 satoshi will they continue to be held in bitcoin jail?
|
|
|
|
thedreamer
Legendary
Offline
Activity: 1694
Merit: 1002
Go Big or Go Home.....
|
|
February 11, 2016, 11:47:44 PM |
|
Is steve2 reading this thread?
|
Go Big or Go Home.
|
|
|
citronick
Legendary
Offline
Activity: 1834
Merit: 1080
---- winter*juvia -----
|
|
February 11, 2016, 11:58:47 PM |
|
I'll be implementing unwanted events and access limitations in ckdb code today or tomorrow. (that's what I've been working on over the last week or so) Basically, failure events or excessive access events will trigger 2 things: firstly to simply reply without any data requested, for all requests, for a specific amount of time, after any event limit is exceeded and secondly to temporarily (hours or days) ban IP addresses that exceed certain event limits that I deem require an IP ban In the past I've done most of this 'somewhat' manually. This will completely automate the process. The code is not in git yet, since I'm still making code adjustments, but it will all be there, but without showing the limits I'll use, since that will be, of course, data in the database, not fixed limits in the code. The design is very much 'guilty until proven innocent' There's no issue with the web site at the moment, though about once a week someone tries to hack into it and always fails (and always will fail) There's also been a few 'annoying' attacks at the web site (that also will always fail) that this will stop dead in their tracks as soon as they start. Web hit rate is over 400k a day, and that isn't using up much CPU at all since ckdb is very fast at getting the data and the web design is very quick and returns a tiny amount of web data to produce the web page. I'd expect there to be no problem to even have a hit rate 10 times that a day, since the current doesn't even show a blip on the CPU usage. ... yet, the data you get from the web site is always the current live data to the second I have workers page refreshed every 15 seconds and other useful stats info every 25 seconds = would this constitute "excessive access"? I think you reminded me on this similar situation before and I would not want to get IP banned - do advise me if I am doing something wrong.
|
If I provided you good and useful info or just a smile to your day, consider sending me merit points to further validate this Bitcointalk account ~ useful for future account recovery...
|
|
|
hoosier_13
Member
Offline
Activity: 62
Merit: 10
|
|
February 12, 2016, 12:20:55 AM |
|
Block nice
|
Bitrated user: TICH13.
|
|
|
vh
|
|
February 12, 2016, 12:23:58 AM |
|
|
|
|
|
|