Latest posts of: -ck

Quote from: WBF1 on March 23, 2015, 09:53:53 PM

Hi Kano and friends.

I periodically check to see if kano.is pool is working with my AMTube miner because I'd love to move over from another pool.

It's still not working without proxy. I know it's not high on the priority list but I wanted to just pass that along.

We can't fix this unless we had someone to debug it with us live, preferably via IRC, and we're currently swamped with other tasks so it's unlikely to happen any time soon.

Quote from: -ck on March 19, 2015, 04:09:05 AM

You may notice a few blips lately and the pool uptime is never very long. I'm trying to track down a subtle bug yet again in the updated pool code and have created the conditions to try and reproduce it to get good debugging information. The pool is set to restart instantly so the downtime is only ever milliseconds but very occasionally some of you may fail over during the restart. Apologies if this causes you any inconvenience.

Looks like I finally nailed this bug so we're back to normal functioning now with hopefully no more pool restarts in the near future. Block on!

I updated the version number to 0.8.7 and tagged M14 after a number of substantial updates and fixing a long standing crash bug that has been eluding me till now.

Quote from: Blackbird0 on March 23, 2015, 03:18:03 PM

Probably not a good idea in practice because the worker difficulty gets too high for the U1/U2, but it works fine.

Worker difficulty makes no difference to performance. It's fine for difficulty to be suitable for the combined hashrate and not each device.

Quote from: zefir on March 23, 2015, 08:48:02 AM

With the latest builds of bitcoind

Anything obviously wrong? I'll debug and report back if not, just to be sure it is not some silly mistake at my side.

bitcoind rpc allow command changed

No one understands what you're asking. Try in your local board in your own native language.

Nothing will happen. Bitcoin diff is affected by the rate of block solving, not the difficulty of the successful solves.

Quote from: os2sam on March 21, 2015, 10:55:07 PM

Edit: So do think this is a fix or a preliminary test? Also what is the driver instance name for the --usb options?
Thanks a bunch, again.

This code should just become part of the next release. It's still all under the same device name for all bflsc driver devices so BAS. The code was never rewritten to account for variants detected after the fact and black/whitelist them (it would be a massive rewrite and manufacturers have all but made this venture worthless).

Quote from: os2sam on March 21, 2015, 10:38:48 PM

Is this what you're asking for?

Code:

C:\cgm491>CGMINER -D -T
 [2015-03-21 17:30:07] Started cgminer 4.9.1
[2015-03-21 17:30:08] USB init - BAS device 5:1 usbver=0200 prod='BitFORCE SHA256 SC' manuf='BUTTERFLY LABS' serial='FTYM9T5M'

Yes that's it.

Try this:

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

Quote from: os2sam on March 21, 2015, 07:14:05 PM

They identify themselves to Windoze as BitFORCE SHA256 SC and CGMiner 4.9.1 identifies them as a BAS.

What a pain. That's the identifier for their 65nm hardware. No idea why they put it on mofarchs as well

65nm so far showed up as:
"BitFORCE SHA256 SC"

while 28nm as:
"BitFORCE SC-28nm"

The old FPGA showed up as:
"BitFORCE SHA256"
and then 28nm started showing up as this too.

Now they're mixing the 65nm identifiers with their "new"er hardware. If BFL didn't have bigger problems, I'd say they were doing it deliberately, but this is probably just plain screwup on their part I guess.

What does the iManufacturer field list?

Quote from: collins6542 on March 21, 2015, 07:34:58 AM

using CGMiner 4.3,

That's ancient and the rockminer support didn't even exist back then. Why? Grab the latest cgminer.

Someone calling themselves HASHPOOL found a block using the existing code

https://blockchain.info/tx/4eb1d6e38d5953155c6b5ca7950405c578937a42fcc37080996931a0b864bb68

Quote from: opentoe on March 20, 2015, 07:39:04 PM

My antminer S5's aren't shutting down when they hit 80C or above.

Quote from: opentoe on March 20, 2015, 07:39:04 PM

Was told this issue is probably in the bitmaintech driver code and they need to resolve it.

This.

Quote from: LeviWalker on March 19, 2015, 11:38:02 PM

Quote from: -ck on March 09, 2015, 09:38:19 PM

Cross compiling is not for the inexperienced. I suggest you take the top off the cointerror, pull out the usb cables from the beaglebone controller and plug them into any pc running linux. The device works fine from any controller running cgminer.

I have two of these myself and was just thinking the same thing. Mine actually run fine (good actually) so I dont know if there would be anything to gain other than experience by doing this. I am running your CKPool in the same rack as the miners so what do you think about running these with cgminer on the server? Its a virtual environment so I can easily add another server for mining only if that would be better.

Up until my cointerra turned into a blast furnace and tried to weld itself to my shelf, I ran it off a PC instead of the BBB built in and found the USB communications much more reliable where errors were virtually non existent and latency was lower, so I definitely think there's an advantage (provided you have ridiculously cheap electricity, otherwise these make great boat anchors).

Quote from: hedgy73 on March 16, 2015, 11:36:41 PM

Quote from: -ck on March 16, 2015, 11:30:54 PM

Quote from: hedgy73 on March 16, 2015, 11:29:03 PM

Just noticed and curious what is IPV6 mining as mentioned in your OP?

http://en.wikipedia.org/wiki/IPv6

Thanks, has it made any difference?

It makes no difference. It only provides another way to connect to the pool if you have an IPV6 capable system and are connected via IPV6 in some way to the internet instead of the regular IP address which is IPV4.

Quote from: hedgy73 on March 16, 2015, 11:29:03 PM

Just noticed and curious what is IPV6 mining as mentioned in your OP?

http://en.wikipedia.org/wiki/IPv6

Quote from: LeviWalker on March 16, 2015, 11:20:40 PM

I have just decided to put everything in solo and let it ride. So far it appears to be working.

{"hashrate1m": "3.64T", "hashrate5m": "3.13T", "hashrate1hr": "3.05T", "hashrate1d": "1.14T", "hashrate7d": "199G", "lastupdate": 1426547567, "workers": 2, "bestshare": 118405504.19514887}

I was going to setup a little python script to track my metrics over time and setup some monitoring alerts so I know if something goes south. Do you have any preference on the poll interval to the stats page? I was thinking like every 5 minutes unless you don't want the extra 288 hits a day.

Thanks for setting this pool up!

Stats are updated every 1 minute. Anything less than one minute makes no sense and every minute is fine by me.

Quote from: os2sam on March 16, 2015, 09:31:26 PM

So does the very short N make it hoppable?

No because he still pays the last N which is the key to making it unhoppable. I'm trying to envision if there might be some way to strategically mine going back and forth between two pools where the N ends up being wildly different durations but I can't think of one. OOC might be able to chime in here.

Quote from: DrHaribo on March 16, 2015, 06:58:18 PM

And I guess Slush's pool is much less profitable to pool hop than a prop pool.

Slush moved from his exponential scoring system to PPLNS with a very short N instead. He just never posted an announcement here since he's abandoned the forum as a support channel.