It's a nice start I think.  I think Slush is now PPLNS, but I don't know how to confirm that. Thanks for your effort so far, Sam |
|
|
|
Ok...
All other things being equal, and a bit of a derail. But... Why the HELL is eleuthria's trust rating so low? Mine is higher, and I mostly just talk.
The trust system seems really arbitrary. Eleuthria has a trust rating visible to me of 10: -0 / +1 Yours is all 0's. So what does that mean? |
|
|
|
I did not mean to offend Organofcorti , I did not realize that the pool Manager/Creator were responsible for maintaining their listing..
I would still maintain the list as i am slightly obsessive and would try and do my best.
Well if you really want to give a go PM OoC. He asked a few pages back for someone else to take it over. I wouldn't mind if a "slightly obsessive" individual such as yourself wanted to take up the task. Remember this is for Bitcoin only and not for alt coin pools as they have their own section and list. Also I don't think you offended anyone and I'm sorry if I gave the impression you did. Sam |
|
|
|
|
Also post in the CGMiner thread instead of creating a new one.
|
|
|
|
|
Just put a shortcut to your .bat file in the startup folder and run it minimized. You have to log in to start it but you can then lock the desktop or switch users.
|
|
|
|
can a mod remove this sticky so someone can start a new Pool List. hopefully someone that will keep it updated
Are you volunteering? I'm sure Organofcorti would be happy to pass the baton to you if so. In the mean time why remove the sticky to the listing of pools? The sticky isn't stopping anyone from making a new pool list if they want to. Also if it isn't updated that is only because the pool owners haven't taken the responsibility to post updates to this list. |
|
|
|
Each time I feel the process is a burden, I spend a few hours speeding up parts of it, but the final send will, for the time being, require me to check and send So, how often are payments made? Is it a daily or per block find or something else? I didn't see it mentioned in the top post. Thanks, Sam |
|
|
|
Do what I did, solo mine off your own node for a while then mine off this solo pool and compare results. Solo mining off my own node was problem after problem, I gave it up quickly.
Hmm. Kind of hard to compare results unless you hit blocks both ways. What problems did you have solo mining off your own node? It's pretty straightforward. I too prefer to solo mine here for the performance, but my own node is always in the end my list too. |
|
|
|
Don't take this the wrong way (as I really like the idea of this pool), but what are the advantages of mining here vs. real solo mining, assuming I already have a full node up and running?
Advantages over regular solo mining:
Mining at solo.ckpool.org avoids the overheads of running a full bitcoin node that requires both great storage and bandwidth for optimal performance.
Solo.ckpool.org is extensively connected to high speed low latency bitcoin nodes for rapid block change notification and propagation.
Unlike regular pools, ckpool never mines transaction-free blocks due to its ultra-scaleable code which has miners on both new blocks and transactions concurrently.
|
|
|
|
Can you tell what pool(s) are currently mining 0 transaction blocks consistently?
Not from the data I pulled since the core API doesn't provide it - I ran this against my local node. I don't know how happy blockchain.info would be if I pummeled them with 86k requests  . I ran my parser against a dataset - wasn't really designed for this - but here's what I've got: What is the "dataset"? Doesn't look like anyone is purposely mining empty blocks on a regular basis. So, that's a good thing. Thanks, Sam |
|
|
|
|
Can you tell what pool(s) are currently mining 0 transaction blocks consistently?
Thanks,
Sam
|
|
|
|
C:\Bitcoin\cgm491>cgminer -D -T
[2015-06-03 21:12:17] Started cgminer 4.9.1
[2015-06-03 21:13:15] BAS looking for and found BAS 0403:6014
[2015-06-03 21:13:15] USB lock BitForceSC 5-1
[2015-06-03 21:13:15] RES: BitForceSC (5:1) lock=1
[2015-06-03 21:13:15] USB res lock BitForceSC 5-1
[2015-06-03 21:13:15] RES: BitForceSC (5:1) lock ok=1
[2015-06-03 21:13:15] USB init, iManufacturer mismatch - BAS device 5:1
[2015-06-03 21:13:15] Found BUTTERFLY LABS vs Butterfly Labs
[2015-06-03 21:13:15] USB free BAS
[2015-06-03 21:13:15] USB init - BMA device 5:1 usbver=0200 prod='BitFORCE SHA256 SC' manuf='BUTTERFLY LABS' serial='FTYM9SV3'
[2015-06-03 21:13:15] BMA0: reset got err 0
[2015-06-03 21:13:15] BMA: cgid 0 SetLatency got err 0
[2015-06-03 21:13:15] BMA0: setdata got err 0
[2015-06-03 21:13:15] BMA0: setbaud got err 0
[2015-06-03 21:13:15] BMA0: setflowctrl got err 0
[2015-06-03 21:13:15] BMA0: setmodemctrl got err 0
[2015-06-03 21:13:16] BMA0: purgetx got err 0
[2015-06-03 21:13:16] BMA0: purgerx got err 0
[2015-06-03 21:13:16] BitForceSC detect (5:1) Warning unknown firmware ' 1.4.50x00' using Ver2
[2015-06-03 21:13:16] BMA: cgid 0 SetLatency got err 0
[2015-06-03 21:13:16] BitForceSC (5:1) identified as: 'BMA'
C:\Bitcoin\cgm491>cgminer -n
[2015-06-03 21:18:11] USB all: found 31 devices - listing known devices
.USB dev 0: Bus 5 Device 1 ID: 0403:6014
Manufacturer: 'BUTTERFLY LABS'
Product: 'BitFORCE SHA256 SC' Here's the portion that was relevant last time. Let me know if you need the entire dump. Thanks. It's recognising it fine and running it as a monarch so if it's not working then they changed the protocol and, well, there's no sign of any updated protocol documentation and I do believe all communication channels between the cgminer development team and BFL have effectively been severed so... fuck. Oh, Joy. It does work, kind of. 80 or 90 Ghs, 120Ghs sometimes briefly. Also the temp goes all the way up to 50 or so as if it was mining full speed. Thanks, Sam |
|
|
|
I had a Monarch die so I had to send it in. It came back from repair and now it only hashes around 70 to 80 Ghs with CGMiner 4.9.1 with the replacement .exe. My guess is yet another USB identity to confuse cgminer further, possibly even intentionally from their end. Do the usual and get the dump of adding "-D -T 2>log.txt" to your cgminer commands on startup and dump the contents of log.txt here to see what cgminer makes of it. C:\Bitcoin\cgm491>cgminer -D -T
[2015-06-03 21:12:17] Started cgminer 4.9.1
[2015-06-03 21:13:15] BAS looking for and found BAS 0403:6014
[2015-06-03 21:13:15] USB lock BitForceSC 5-1
[2015-06-03 21:13:15] RES: BitForceSC (5:1) lock=1
[2015-06-03 21:13:15] USB res lock BitForceSC 5-1
[2015-06-03 21:13:15] RES: BitForceSC (5:1) lock ok=1
[2015-06-03 21:13:15] USB init, iManufacturer mismatch - BAS device 5:1
[2015-06-03 21:13:15] Found BUTTERFLY LABS vs Butterfly Labs
[2015-06-03 21:13:15] USB free BAS
[2015-06-03 21:13:15] USB init - BMA device 5:1 usbver=0200 prod='BitFORCE SHA256 SC' manuf='BUTTERFLY LABS' serial='FTYM9SV3'
[2015-06-03 21:13:15] BMA0: reset got err 0
[2015-06-03 21:13:15] BMA: cgid 0 SetLatency got err 0
[2015-06-03 21:13:15] BMA0: setdata got err 0
[2015-06-03 21:13:15] BMA0: setbaud got err 0
[2015-06-03 21:13:15] BMA0: setflowctrl got err 0
[2015-06-03 21:13:15] BMA0: setmodemctrl got err 0
[2015-06-03 21:13:16] BMA0: purgetx got err 0
[2015-06-03 21:13:16] BMA0: purgerx got err 0
[2015-06-03 21:13:16] BitForceSC detect (5:1) Warning unknown firmware ' 1.4.50x00' using Ver2
[2015-06-03 21:13:16] BMA: cgid 0 SetLatency got err 0
[2015-06-03 21:13:16] BitForceSC (5:1) identified as: 'BMA'
C:\Bitcoin\cgm491>cgminer -n
[2015-06-03 21:18:11] USB all: found 31 devices - listing known devices
.USB dev 0: Bus 5 Device 1 ID: 0403:6014
Manufacturer: 'BUTTERFLY LABS'
Product: 'BitFORCE SHA256 SC' Here's the portion that was relevant last time. Let me know if you need the entire dump. Thanks, Sam |
|
|
|
|
I had a Monarch die so I had to send it in. It came back from repair and now it only hashes around 70 to 80 Ghs with CGMiner 4.9.1 with the replacement .exe. If I use the "special" version of BFGMiner on a 64 bit machine it hash's fine. It used to hash fine with CGMiner too. Any idea's?
Thanks,
Sam
|
|
|
|
You at least need to open a command prompt and run the command and see what the error is.
More details if you add -D --verbose to the cgminer options.
But most likely it will show without them.
Also ... cgminer -n will tell you what hardware it finds.
like: cgminer.exe -D --verbose --bmsc-options 115200:0.57 -o stratum+tcp://hashgoal.com:3332 -u 2XdsyV7ThMVPp65PxSmWmjpoL1ctW1rJDk -p x --bmsc-voltage 0800 --bmsc-freq 1286 ? because of i do this, i get nothing to see. That's what you do 2nd. First you run your original command line in a DOS window and see what you get. |
|
|
|
And what are we supposed to do about it? I don't think the Bitcoin community carries allot of weight with the Chinese Government. So if their government shuts down, or throttles, their internet access then we may have no choice but to carry on without China. Note that this is unrelated to any regulatory or whatever issues. This is regarding the block size. Specifically, one of the F2Pool people chimed in saying that while they support larger block sizes, they currently can't handle them. That is to say, they would have a larger yield of orphans. Which is okay, the same would apply to other pools facing the same limitations. However, pools like AntPool, which are stuffed with manufacturer-direct hardware at near-cost, can deal with higher orphans for a while, especially if the prospect is that they can push competitors out of the market. I recommend reading the entire thread, as Mike's reply taken out of context sounds a fair bit more harsh than it is: http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/554BE0E1.5030001%40bluematt.me/#msg34093766Steve, Thanks for the clarification. This subject was dropped in here with no context and I just assumed it was political discussion with their government. But the block size discussion is always a choice right? If a pool can't generate large blocks for a technical reason they can still choose to generate smaller ones? right?. Anyway I'll read the links when I get the chance. Thanks, Sam |
|
|
|
|
And what are we supposed to do about it? I don't think the Bitcoin community carries allot of weight with the Chinese Government. So if their government shuts down, or throttles, their internet access then we may have no choice but to carry on without China.
|
|
|
|
|
Kano,
Thanks for the clarification.
|
|
|
|
|
The configuration option
--enable-blockerupter is for the Tube/Prisma's only right?
whereas
--enable-icarus is for the old ASIC Miner Block Erupters?
Thanks,
Sam
|
|
|
|
|
Show Posts
