Meanwhile on a different note ... I just restarted the ckpool 10minutes ago - after 24hours of stable running.
Would have been some failover.
More updates, but hopefully more stability as we have also had in the past 24hrs.
I believe I've made significant inroads into finding the cause of the long standing bug which recently has become much more pronounced after investigating for the last week solid (see ckpool git for the number of patches recently committed). It's too early call it fixed but it has not shown up for a longer stretch than in a while and we've ruled out numerous other possible causes so this was the first scheduled restart in a while, and hopefully we can leave the pool in peace for a bit. And now for some blocks please. |
|
|
|
My main issue is the number of 'duplicate' shares I keep getting.
I'm currently using cgminer 4.6.1 (simply because I haven't needed to upgrade)
Think about those two statements. |
|
|
|
|
I gave it a swift kick in the balls for misbehaving, sorry about that.
|
|
|
|
The problem is that when a larger force to occupy the mine operator pool, opportunities for small miners have not luck situation.
You are using google translate it seems and your translation makes very little sense. Sorry. However I think I understand what you are saying, that big miners mining here affects the chances of small miners finding a block. This is wrong. Each miner's chance of finding a block is not affected by other miners at all and only depends on their own hashrate. |
|
|
|
|
You're most welcome. I mainly opened this pool to test my ckpool code and hoped to make a little off doing so. While it was not necessarily directly from Phil's pleas that I decided to start this solo pool, no doubt it contributed to my deciding to start it (so thanks Phil). There's also quite a nice mini community that's developed on this pool too, even though there is only ever one winner at a time. It reminds me a little more of what it was like to mine years ago when I first started. I just paid up another 3 months worth of server time to run this pool on.
|
|
|
|
I don't see why the version wouldn't stick after a restart, but we'll see...
The filesystem you see when S5s are running is in ram only, it is not on the flash storage in the device. It needs to be embedded in the firmware for it to be on the flash storage. One day maybe there will be actual firmware you can use in the regular fashion if we can get coordinated with bitmain. Bitmain USA is more receptive to involving us than their main China group. |
|
|
|
|
To put it simply, we're dealing with the usual fuckage and nothing can really connect to the pool while it's happening even though the pool is still running, and try to restart things as soon as possible to minimise the downtime. We've excluded quite a few possible causes but not found the problem yet and are still investigating and hopefully narrowing in on the true cause.
|
|
|
|
The queue setting is the one that will make the difference. The others won't help you. Also, you should use --submit-stale since by default the cgminer binaries in the Ants all throw away stale work, which is a very bad thing for p2pool. Okay, thanks; I'll try "--submit-stale" and see if that improves things. Update: It appears `cgminer` doesn't have a "--submit-stale" option. I think my S5s build (and ck's, too) submits stales by default because there is a "--no-submit-stale" option. I'm not sure if kano/ck have built a cgminer binary for the S5... if they have, then I'd suggest using theirs. Yes, he does: http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminerHowever, ck's version doesn't have a "--btc-address" option for solo mining. Is there a way to solo-mine with ck's version? Update: Wow, I'm getting up to 2.54 Thash/s (as reported by P2Pool) with two S5s and ck's cgminer 4.9. Thank you, jonnybravo0311! If you're going to solo mine, just point the miners to solo.ckpool.org. Not really worth trying to solo mine directly to the coin daemon, so there's really no need for the --btc-address parameter. If you really want to do it yourself, then you'd be better off setting up your own instance of ckpool; however, unless you're well connected you run a high risk of submitting an orphaned block, and seeing that 25 BTC go down the drain would really suck. I swear I read from ck/kano that the Bitmaintech fork of cgminer tossed stale work... and that was one of the reasons to use the binary from them instead of Bitmain's. Yes that is correct. The --submit-stale option was removed from cgminer something like 3 years ago and it was made default to submit stale. What bitmain did was they unnecessarily added even more stale test code in their driver and deleted stale submissions. Only the firmwares/binaries myself and kano made do not do that. Anyone mining on p2pool with bitmain hardware should not be using their firmwares. |
|
|
|
Does this pool have it out for bfgminer? I ask because I'm trying to tune the voltage on some Neptunes, and bfgminer allows me to see hw error rates for each die while cgminer doesn't. I'll be using cgminer once everything is sorted out, but for now I need bfgminer. Seems like bfgminer (5.0.0) will only connect to the pool 10% of the time, and fail over to my second pool the rest of the time. cgminer (4.9.1) connects every time without issue.  Not intentionally, no. If there's something broken in its implementation that disagrees with ckpool then that's the first I've heard about it. Since I wrote both cgminer and ckpool it's only natural that's what I'd be testing with. Since the hostile fork's stratum implementation was initially entirely pulled from cgminer's reference implementation I figured it wouldn't have changed much from cgminer's apart from unnecessarily asking for transactions that no pool will do anyway. |
|
|
|
Well I thought CK is in Australia so I figured the servers are there as well but was not sure what was better as far as West or Nice. But I partnered up with another and together we are throwing hash here to see if we can hit a block.
Server is located west coast USA. |
|
|
|
and well written pool software  Heh well that's a bit of a sore point cos Kano keeps expecting me to find something and fix it, but any possible cause for the recurring issue that might be in the software that I postulate doesn't seem to change the behaviour so I keep blaming hardware... but I keep looking anyway. Chasing ghosts indeed. |
|
|
|
It's mostly just plain old luck.
entirely |
|
|
|
|
It makes no difference to your chance of finding a block. The only reason to use different workers is so you can monitor their performance separately.
|
|
|
|
|
The latest version of the pool software has been up for over a month so the earlier instability seems resolved (and more importantly quite a few blocks were solved in that time). I'll be restarting it shortly to pull in the latest changes.
EDIT: Done.
|
|
|
|
So then what the hell is it doing, if it's not completing a double SHA256? You've completely lost me on this. Again I have to ask... if it's not completing a double SHA how does it know that it's got any valid hash below the target?
You don't need the last few steps in sha to examine the first few bytes. |
|
|
|
just check randomly what process is using ram resources with top or htop.
some process is making a peak on ram usage therefore kernel starts killing processes. I suggest htop - you can order processes by ram usage.
there's probably is a better way to monitor this but I am not a system administrator :-)
This is unnecessary. The ram usage is all due to bitcoind. Monitoring it will just tell you "yes it's bitcoind, it spikes to high levels" which we already know. You can disable the wallet, set the cache lower and decrease the maximum connections but that's about all you can do to minimise its ram usage. It will still use heaps of ram. Short of a rewrite, or using different software, there's no way around it. |
|
|
|
Isn't the fact that they only return the nonce a matter of the software not the hardware? The hardware itself would be specific in the fact that it is chip tuned to perform Double SHA256 hashing extremely effectively. The chip itself can't return anything out of it other than a completed full hash.
If you could recode the software/firmware to spit out a full hash from the software side, you would have a valid SHA256 hash, so long as your input is specifically 80 Bytes. I mean is it not the firmware/software that has the logic coded in it to determine what is and is not below the target?
No that's not how ASIC hardware works. It does indeed only return nonces since it doesn't even fully complete the double sha256. |
|
|
|
|
Show Posts
