What can be done, however, is on the pool side.  Pool operators can fine tune their code to make sure potential block solves are broadcast to the network quickly so they do not produce orphan blocks, and also to make sure all the pool workers get new work quickly and start working on the next block as soon as they can.  This is a significant, measurable attribute that can be the difference between solving a block and not.

This is really cool.  Without reading back more than a page I assume that this is done via the R1?  So if I order one from you it will come with this new version on it and be "plug and play"?  How is your stock looking?  I want to order one soon, but I'll pull the trigger sooner if stock is low.  Thanks.

Nice find, thanks for sharing the link.  I think this is the route I will go, support the local community and give back a little to the people who figure out how to crack and code this stuff.  Plus, it saves me from having to re-read pages of thread and figure out how to do it (mess it up) on my own.

+7.76% to +8.00% Mikestang

Well, actually it's a column, but that's the engineer in me speaking through my OCD.


I'm not understanding the physics as to why a 6" long tube on the end makes it any quieter.  Do you have dB meter readings to back this up?

The only "good" share is one that is greater than network difficulty.  Yours is 30 times too small, so no, it's not a good share, sorry.

It's probably a bit above average for a typical S3 share, but none of that matters in the end.

Edward Snowden says it best:

"Traditional, effective surveillance means targeting suspects. Not a population. Not a technology. Not a service. The suspect."

Phil, did you consider cutting out a vent hole low in the wall between garage doors and ducting the exhaust outside?  You could put a nice vent cover over the outside and it wouldn't look like anything out of the ordinary, and then all the heat and much of the exhaust noise would be directed outside.

What "huge recent jump" are you referring to?  You have to go all the way back to April to see a difficulty adjustment higher than 5% and the very next adjustment after that was negative.  You have to go all the way back to November 2014 to see one above 10%.

Why would I want to do that?  I enjoy mining from a technical and tinkering perspective and I still believe that the S3 is the best machine on the market for the average Joe.

My S1 boards are going to gekkoscience in support of the pod miner they are developing, and I'm saving that chassis and controller for when they develop and release full boards.

My S3 will get used all winter again as a solo mining lottery ticket.

The $100 or so I would get for both of them wouldn't be worth it to get rid of them, there's nothing out there better suited for a miner like me.

My S1 and S3 are still turned off.  Electricity is so expensive here in so. Cal. that it is almost impossible to mine at a profit.  When it gets cold I'll turn them back on for heat and because I really enjoy mining, but for now it still isn't cost effective for me to run anything except my little usb "farm".

Coin price is strong and getting stronger, we finally got over the dip that XT caused.  I think we'll see sub-5% for most of this winter, 70G network difficulty coming soon! 

I think this just means that there are still more S7s that Bitmain has unplugged and are making their way to new homes.

I also think that, as difficulty rises, the percent increase each adjustment will be less than we are used to, because 2% of 60G is 50% more than 2% of 40G from a few months ago. I.E. a 2% adjustment at 60G equals a 3% adjustment at 40G, and they both equal 1% at 80G.

So lower adjustments now look nice, but they are the same as bigger adjustments a year ago.

Because I posted a picture from the movie Pod People a few pages back and it has subconsciously stuck in your brain. 

I like that cgminer runs without errors, but I do not like having to use zadig.

I like the cgminer-gekko build, but since I can't compile and that build doesn't see my other usb sticks since it wasn't compiled with any other hardware options it's tough.

I like that bfgminer has the RPC option to mess with frequency while the stick is hashing.

I use them both on different computers.  One of mine I cannot use zadig so that one gets bfg.

I plan to do a linux install eventually, I just don't have a lot of free time and that is pretty low on my priority list at the moment.

I use this one: http://www.amazon.com/gp/product/B00JEVRXQA

I think there is a hub discussion in this thread, but you'd have to go through the posts to find it.  Or it could be in one of the following 2 threads:
https://bitcointalk.org/index.php?topic=1126705.0
https://bitcointalk.org/index.php?topic=995675.0

You are in said thread.  Check the first post.

Do you have any specific questions?  Much easier to help if we know where your issues are.

My bfg batch file for the compac sticks is:
Adjust the clock value based on the hub you are using.  The api commands are there so I can use RPC to adjust clock real-time.

You can find posts by me earlier in this thread having the same comms error, both with the compac stick and the U3.  I'm not sure what causes it or how to make it go away, I posted more in the compac club thread.

I get the same comms error, I've reported it in a few threads but never had any response as to what causes it or how to make it go away.  I get the same error using my U3 with bfgminer on this same machine, so I think it may be hardware related and not actually have anything to do with bfg.

On this machine I currently have 2 gekko sticks and 2 nanofury usb sticks.  I do not get comm errors with only the nanofury sticks, but once I plug in the compacs or the U3 the errors pop up.  Since the compac used to be recognized as a U3 I think that's a hint as to where the issue is.

The good news is my devices seem to hash along just fine, despite the error.  The only problem is that eventually, after 8-24 hours, the hash drops to almost nothing pool side while bfg still reports full hash speed.  At that point I just restart bfgminer and unplug/replug the miners, that's the only work around I've managed to come up with.

Pool side reports a bit lower than bfg, probably a result of the comms error.

Why wouldn't you think the majority switched the pool?  It is apparently very simple to do, someone figured it out and posted here within the first week or so the device was released.  This website is one of the world's largest repositories of bitcoin know-how, so most people that mine probably visit this site.

I get what you are saying about the initial setup and all that, but you made an assumption about how the stat is being reported so maybe your assumption is incorrect.

I would assume the majority have switched pools, since you can go through this thread and see almost everyone who commented said it was lame that it's set to mine on Bitmains antsolo pool and that they would change it if they had the device.  When I get mine I am configuring it to mine elsewhere right away, I do not want to mine for Bitmain at all or use any of their pools.

Would someone be able to provide a complete command line example of the proper syntax?  I am unlcear if I need to use --request-diff in concert with /#cksuggest?

Or maybe I'll take a shot and let me know if this is correct?  Using bfgminer to solo mine on cksolo pool would this be correct?