[2016-06-17 22:47:18.251] Possible block solve diff 377843408540.011597 !
[2016-06-17 22:47:18.394] BLOCK ACCEPTED!
[2016-06-17 22:47:18.394] Solved and confirmed block 416798 by 3JhmANFUNJkBREYYfPPy8hdJ3cnrGvWKhY.128
[2016-06-17 22:47:18.394] User 3JhmANFUNJkBREYYfPPy8hdJ3cnrGvWKhY:{"hashrate1m": "106T", "hashrate5m": "108T", "hashrate1hr": "108T", "hashrate1d": "107T", "hashrate7d": "109T"}
[2016-06-17 22:47:18.394] Worker 3JhmANFUNJkBREYYfPPy8hdJ3cnrGvWKhY.128:{"hashrate1m": "1.24T", "hashrate5m": "1.18T", "hashrate1hr": "1.19T", "hashrate1d": "1.15T", "hashrate7d": "1.12T"}
[2016-06-17 22:47:18.394] Block solved after 68134879360 shares at 34.8% diff
|
|
|
|
Must be a lot of new hardware going online for the pool. Saw a drastic jump to 76.00 Ph/s. Could've sworn it was 68/69 at least two hours ago. I saw it reach 82,10 Ph/s at one point, and one block was found when the rate was 81,32. But every time somebody throws a huge amount of extra power into the mix the only effect seems to be to reduce the amount we get paid per block — my subjective view is that the pool doesn't actually appear to benefit by mining additional blocks.  Generally, the bigger the pool the lower the variance -- and all miners want lower variability in their income, right? What all miners want is more profit, yet they always get hung up on variance and it they end up choosing the lower variance option over better profits to their own detriment. It's a pattern that hasn't changed in years... I praise the pool ops who have the stamina to explain it over and over and over and over and over and over and... |
|
|
|
You are confusing official with bitmain versions of cgminer. The commands you are using with "au3" in them are for the official cgminer while "bmsc" options are for bitmain's unofficial version, yet you are using what appears to be an old bitmain version. Download the latest official cgminer 4.9.2 and use only the au3 options. Official one is available here: http://ck.kolivas.org/apps/cgminer/As for the "difficulty changed to 1024" that is 100% normal operation and you should stop seeing it as an error. Pools choose what diff you mine at and cgminer will tell you what it is. |
|
|
|
|
There seems to be a connectivity issue at the data centre for the main pool. Apologies for the inconvenience; no idea how long it will last.
EDIT: Looks to be back with no explanation. Probably just "one of those things."
|
|
|
|
I' not sure what's wrong but mning here with Avalon4 only shows me doing at best 980 gh i have over clocked it to do 1.26th let me go on it's only on this pool it does it i can't get to hash over 1.06 th only on this pool i can go to any other pool no lie and it picks right up and start hashing at 1.26 th or better so it's not the miner .. my setting are stratum+tcp://stratum.mining.eligius.st:3334 the normal stuff after btc address is 13Xb4RvqoeRumYbzNpe4a8jNLb7N3qhFNZ would that effect it if so which one should i use . if i use just CGMiner or minera --lowmem --avalon4-fan 60 --avalon4-freq 550:500:450 --avalon4-voltage 8250 --avalon4-miningmode 0 --avalon4-automatic-voltage if I use there supplied software same setting but they do it, i even have left out some stuff and it got worse . i had this problem one other time and fixed it by using a different firmware from bitmain but that's was a antminer .that was a nice hash fork that didn't like this pool so i went back to butmains fw and it picked right up. but in this case with that Avalon4 i don't have to much pick from and BFG does not support Avalon4 and up that i see or i can't find any support or id use it . i have tried default setting under clocking and etc tried my own complied version of cgminer with just cg,miner and in minera and with the openwrt software they supply untouched. and best it hits is three hour is 724.46 and now it's actually showing it at 128 seconds 1,082.43 Gh/s with that miner and the software is showing Per 5s: 1208GHs Per 15m: 1067GHs but seems to go down as i said it's only on this pool and with the update coming i may buy 2 S7 1 a6 and set here like before sense s9 are beyond what I'm willing to pay or can afford even if i could afford one i wouldn't it's a moral thing with me and S7 and a6s are and im not blaming anyone just looking for tips to try to see if anyone has one i haven't tried yet. and it just didn't start it been going for weeks i never said any thing i was hoping id find out why and apply a fix . Probably the host CPU is too slow. You could try setting --queue N higher. haven't tried that yet ill give it go. Avalon4 doesn't use queue as it does stratum internally. It could just be the large coinbase that this pool uses. |
|
|
|
[2016-06-15 19:03:19] Lost 10 shares due to no stratum share response from pool 0
from bmminer during times when my connectivity to the pool seems fine Even though cgminer has had a stable release out for over 6 months with this fixed, there's an extremely high chance they have an out of date version of cgminer which isn't handling the pings from ckpool and misinterpreting the ping command as a share. BM have been notoriously bad at keeping their code in sync with master cgminer - basically they haven't. So does this suggest that the S9's will underperform on Kano (or maybe everywhere)? And why did they rename cgminer to bmminer? No. It's just harmless irrelevant noise. As to why they renamed it? Beats me, probably marketing, but there's nothing that stops you renaming a forked version of GPL licensed software provided you make your source modifications also freely available. That's how the other infamous hostile fork was created from cgminer as well. Not to mention heaps of altcoin variant forks based on cgminer code. |
|
|
|
|
I should also point out that before the last halving, the global hashrate went up for a while while people brought back online old inefficient hardware for the last few blocks on the chance they'd get one of the last 50BTC blocks before retiring that old hardware forever as a complete loss. I expect something similar will happen this time too.
|
|
|
|
New bitcoind is much faster than the old one at generating block templates so they switch away from their empty SPV block work sooner than they used to.
Thanks, -ck. Which bitcoind? Was it available after October last year (when we first started to see much smaller interblock durations than previously)? 0.12 branch, so whenever dev for that had made significant progress if they had switched to it. They say they made other changes (after kano's continual prodding) but one can only surmise what they may have been; probably the first step to switching to a full block template as soon as it was available from a fully validating client (bitcoind). |
|
|
|
|
One does not mine bitcoins with CPUs or GPUs any more.
|
|
|
|
|
New bitcoind is much faster than the old one at generating block templates so they switch away from their empty SPV block work sooner than they used to.
|
|
|
|
[2016-06-15 19:03:19] Lost 10 shares due to no stratum share response from pool 0
from bmminer during times when my connectivity to the pool seems fine Even though cgminer has had a stable release out for over 6 months with this fixed, there's an extremely high chance they have an out of date version of cgminer which isn't handling the pings from ckpool and misinterpreting the ping command as a share. BM have been notoriously bad at keeping their code in sync with master cgminer - basically they haven't. |
|
|
|
[2016-06-15 10:22:37.151] Possible block solve diff 218581804444.025787 !
[2016-06-15 10:22:37.296] BLOCK ACCEPTED!
[2016-06-15 10:22:37.297] Solved and confirmed block 416419 by 1Jz3USw2AnNPEeVkCLjzxBw5fsD3c5v9Z2
[2016-06-15 10:22:37.297] User 1Jz3USw2AnNPEeVkCLjzxBw5fsD3c5v9Z2:{"hashrate1m": "772T", "hashrate5m": "727T", "hashrate1hr": "717T", "hashrate1d": "377T", "hashrate7d": "264T"}
[2016-06-15 10:22:37.297] Worker 1Jz3USw2AnNPEeVkCLjzxBw5fsD3c5v9Z2:{"hashrate1m": "772T", "hashrate5m": "727T", "hashrate1hr": "717T", "hashrate1d": "377T", "hashrate7d": "264T"}
[2016-06-15 10:22:37.297] Block solved after 597517702278 shares at 304.8% diff
|
|
|
|
Sorry im new with this, but may i know what is this error please?   It means you don't have any mining devices, as it says. Cgminer is just controlling software to allow your computer to control mining hardware attached to it. The computer itself doesn't do the mining. |
|
|
|
|
Correct. There's definitely lag time before those who mine below profit margins come to grips with it and slowly turn off their hardware. The rise in bitcoin value at the moment may alleviate and even offset it entirely though this time around since btc is on the up and up.
|
|
|
|
Difficulty will decrease after the halving. If diff increases it's due to newer hardware and btc price rising instead.
Did difficulty decrease after the last halving in 2012? A lot. |
|
|
|
How can we be at 300% block with all this hash?
The hash rate just determines how long we 'would take' to get to X% Diff It makes no difference to the value of X% Diff each block. Put simpler: Hash rate has no effect on luck. |
|
|
|
|
Difficulty will decrease after the halving. If diff increases it's due to newer hardware and btc price rising instead.
|
|
|
|
|
Offtopic's getting outta control again guys.
|
|
|
|
They'd always lose if they broadcast it after another pool has found a block unless they were big enough to get two blocks back to back.
Not necessarily. It would depend on how well connected they were to other miners and pools, and how well connected the pool that found the block was. If they received the block directly from the pool that found it, and then immediately broadcast their own block to all the other pools before the competing block had propagated, then they'd have a pretty good chance of winning. Anything's possible, sure, but since they have to receive it from the other pool and then broadcast their own, then every other pool may also have received the block. Sure they might be the only pool with a good connection to the one pool that solved the block but there is no magic to make one pool substantially better connected to all pools than all other pools might have. Too many ifs and buts, but yes in this pedantic world, my ALWAYS is indeed wrong. Let's say 99% to not leave any absolutes out there... Either way it's far too risky to likely lose a whole block reward. |
|
|
|
They might miss out on the 12.5 BTC since they didn't broadcast their block
They could always withhold the block until someone else finds a block, at which point they can broadcast their block and hope to win the race. They would still lose sometimes, but sometimes they'd win. They'd always lose if they broadcast it after another pool has found a block unless they were big enough to get two blocks back to back. |
|
|
|
|
Show Posts
