btw i have a lot of hw, it only can done by a failure miner?
Normal with those miners. Ignore them if it's still hashing ok. |
|
|
|
Hi, i have a redfury USB stick and i was thinking best i can do is to play lotery with it. I tried to configure the redfury with my new computer (installing the zadig and replacing the winUSB driver), but when i run the cgminer 4.9.2 it show me "share above Target" and do very few accept works and a lot of hw... why? this miner was running fine in past... i am doing the configuration wrong?
I use a .bat with this line:
cgminer --widescreen --worktime -o stratum+tcp://solo.ckpool.org:3333 -u 1BPX9vJBqpGb2Hj1KyPi4p58kNEcWH6vyU -p x
worktime is for debugging and share above target is a normal message in that mode. Remove that part of your command. |
|
|
|
cgminer.exe -stratum+tcp://solo.ckpool.org:3333 -u 1AqTMBDUQ9V4Z1gRkxhgSUdBuVgXQY8i61 -p x --compac-freq 225
Syntax is wrong. "-stratum" should be "-o stratum" |
|
|
|
I get:
No stratum, GBT or solo support in pool 0 <null> unable to use
That's almost certainly because you're trying to connect without a valid bitcoin address as your username. Nothing else works on this pool - you will be rejected. Unlike some other pools where they just leech the hashrate of invalid miners' addresses. |
|
|
|
I remember when ck's signature read to the effect 'only ignoring luke jr.'
That's when I tried to figure out who's who or what around here and I came to the conclusion that jr. guy was some sort of a jesus freak who also happened to 'pick up' on ck's early open source? miner and bend it to his liking. This is my current understanding.
To the point, jesus freaks aren't supposed to steal and cheat. This too is my current understanding.
And he's still the only person on my ignore list. Unfortunately in that time the landscape has changed so much and so many people have moved on and newcomers replaced them that the reason for the argument is not known by many of the current people in the bitcoin world - most people think it's a simple matter of "why don't you just make up and be friends?". But search enough and the history on the internet doesn't lie about where source code came from, who wrote it first, what claims were made, and how ridiculous he was, is and will continue to be. Then one can understand why that is not a solution. The biggest continuing problem is I try to remain out of the arguments, but in this world if you don't defend yourself, then people just end up believing the person who shouts loudest and longest and silence is assumed as guilt through being unable to defend oneself. Kano enjoys such fights and I have him to thank for defending when the trolling resurfaces (as it often does). I have no time for them... |
|
|
|
I received another reply today from Slush regarding the recent influx of invalid blocks. The primary reason for this behavior was recent malleability attack on Bitcoin network which caused the Bitcoind overload with transactions and directly affected the ability to propagate blocks into the network.
Not only our nodes were affected but many other nodes across entire BTC network as well.
Which is what I said. Well, probably that in combination with bitcoinds that haven't been optimised to cope in this transaction spam environment which can cause massive mempool and cpu blowouts and subsequently very slow block changes/getblocktemplate calls.
In other words slush hadn't manage to optimise his bitcoinds to cope under the circumstances and ended up depending on the newer bitcoind version to fix it. While he says many other nodes were affected, there were pools that were not. |
|
|
|
In an email reply I received from Slush inquiring about the abnormally high invalid blocks he responded by stating "it was a matter of chance to end up with invalid block". And additionally stating "We don't have direct impact over this behavior. Invalid blocks are natural part of the Blockchain ecosystem..."
Do all of you agree with this?
It is an expected phenomenon of the way blocks propagate that orphans will eventually occur, but it is the responsibility of the pool owner to optimise their design to minimise this effect. Having orphans is expected, yes, but having a high rate of orphans is not expected. Check the orphan rates of other pools. The percentage should be about the same for all pools, irrespective of their size, though statistically it would be hard to get an accurate percentage on smaller pools simply because of the number of blocks solved. |
|
|
|
Presumably everything has slowed down due to the extra load of having so much hashrate on his pool. Since slush's pool code is python, it's likely just the slowdown of python not scaling to the greater number of clients it's seeing. He either needs more mining nodes or better software.
From memory, slush's pool used to prioritise which clients got block updates first - since it takes time to send updates to all the miners, he prioritised the biggest miners first so all the small miners used to get the block change later. Perhaps even that workaround is no longer enough.
I'd assume something else is the issue. I highly doubt he has more active miners than ever, just higher speed ones. There's way fewer small fries out there today than there were a year or more ago. In a proper implementation of vardiff, the speed of connected miners should have absolutely no impact on actual server load, only the number of miners in general. Well, probably that in combination with bitcoinds that haven't been optimised to cope in this transaction spam environment which can cause massive mempool and cpu blowouts and subsequently very slow block changes/getblocktemplate calls. |
|
|
|
@ Con what's your phd in?
And pardon me for guessing it is a phd. Just an assumption on my part.
I'm a medical doctor - a specialist in anaesthesia. |
|
|
|
Does anyone see these Orphaned blocks as an attack by some of these Chinese Pools (specifically Antminer)?
More likely it's just Slush's pool backend not updating to other blocks on the network fast enough (or being really slow in releasing its own blocks). He's the only one having such absurd orphan rates, the problem is on his end. Presumably everything has slowed down due to the extra load of having so much hashrate on his pool. Since slush's pool code is python, it's likely just the slowdown of python not scaling to the greater number of clients it's seeing. He either needs more mining nodes or better software. From memory, slush's pool used to prioritise which clients got block updates first - since it takes time to send updates to all the miners, he prioritised the biggest miners first so all the small miners used to get the block change later. Perhaps even that workaround is no longer enough. |
|
|
|
Mr Kolivas,
I think a tip is well deserved. forgive me if this is posted elsewhere, what BTC address should I send a donation to?
It's actually Dr. Kolivas, but I prefer to just be called Con anyway. Thanks! Any of my usual donation addresses listed in any of my software projects or the pool address are fine. The cgminer address is 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ |
|
|
|
Thats Me!!! Thank you! I have a total of 34 Th usually mining at antpool or nicehash. They were supposedly mining at Nicehash when one hit the block. I set ckpool as the secondary pool on all 23 of my miners.
Congratulations! Good thing for you your primary pool was unstable and ckpool was its usual level of stability  Enjoy! |
|
|
|
BTW, I just found out that RPi 2 only has just one USB bus (and all it's four USB port sit on it), so --usb 1:* approach doesn't work for me. It seems that I have to write some script now, which analyzes lsusb/cgminer --ndevs output, sorts devices by their vendor ID into groups, and then runs different cgminer instances with specific options for each group. It would be nice to have all this out-of-box, of course)
There's a good chance that that device doesn't keep changing usb positions (unlike the U3). In which case you can just specify exactly the usb position it's at with the nano cgminer instance. --usb 1:3 etc. |
|
|
|
|
So far the pool has solved 110 blocks and hasn't had an orphan. While I've gone to great effort to optimise this pool to minimise the risk, nothing can entirely remove the risk of orphans given the way block solving works. It's a little scary to think about but at some stage someone will find a block and it will be orphaned...
|
|
|
|
Does avalon nano actually work? Actually it works just fine with --icarus-options 115200:1:1 and --icarus-timing 0.22 settings, maybe with HW error rate on a relatively higher side (~7%). The easiest way would be to find which ports belong to different usb buses and then put the nano on one usb bus and confine that cgminer version with the --usb command. I understand that, it's just not very convenient in my configuration (Raspbnerry Pi 2 + 12-port USB hub), where all the ports in the hub belong to the same USB bus. I need separate USB hub for each device family, etc. That's why I asked my question. But if there is no way to run all devices from just one cgminer instance, then I will have to rearrange hardware somehow. Thanks for your answer. No there isn't because too many devices use the same damn usb communication chip without any added identifier for cgminer to tell them apart and blindly use the 1st fpga/asic driver from cgminer (icarus) in different ways. The icarus commands were never designed with different devices in mind but new devices+drivers continue to come out that use that driver as though it's the only device connected. |
|
|
|
For instance, --icarus-timing 0.22 seems to be required for Avalon Nano 3 ( https://en.bitcoin.it/wiki/Avalon_nano ). Otherwise, cgminer shows ~500 KH/s rate instead of ~3.6 GH/s, and the device is idling most of the time according to its status LED and temperature. However, this timing is clearly inappropriate for ASICMiner Block Erupter that I'm trying to use at the same time. Does avalon nano actually work? I've never heard of anyone getting the driver working before... I apologise in that case. Then you'll need to confine them with separate cgminer instances. The easiest way would be to find which ports belong to different usb buses and then put the nano on one usb bus and confine that cgminer version with the --usb command. EG: If you find which ports belong to usb bus 1 and usb bus 2, then start one cgminer instance with all the other devices plugged into bus 1 with --usb 1:* and put the avalon nano on bus 2 ports and start cgminer with --usb 2:* |
|
|
|
 congrats to 1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt for the Block. @ck: I think in a year, or one and a half, you will be one of the 7 bigest Pools because of the halfing of Block reward and a lot of smaler pools will be closing because of that. [2015-10-17 18:40:11.046] Possible block solve diff 186675369984.113098 !
[2015-10-17 18:40:11.695] BLOCK ACCEPTED!
[2015-10-17 18:40:11.697] Solved and confirmed block 379339 by 1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt
|
|
|
|
|
Show Posts
