So apparently my old Bitfury rig is not fond of your pool. It is showing 350 GH/s on the webpage and only 73 GH/s at the pool currently. Any suggestions for what I can do? Other than throw it in the trash.
Maybe you can set it up with a unique worker name and give me the worker name and I can dig into the logs to see if there's anything obvious poolside. |
|
|
|
I can report that the binary drops in and replaces the old one, matches the architecture, and runs without exploding in a ball of flames! So I've pointed my S4, running this new binay, back at Slush's pool to see how it goes. Probably too soon to tell, but initially it reported hashing over 2TH via the web ui (as it always does) while Slush was showing it doing only about ~450GH, poolside. After a few minutes that climbed up to and settled around 1TH and has been sitting there. The Web UI also reports the Diff column (of the Slush row in the Pools table) as 1.05K, but I'm not sure if that indicates a problem... I also dug into the init script to see what comman line params it gets run with, and they are: /usr/bin/cgminer --bitmain-dev /dev/bitmain-asic \
--bitmain-options 115200:32:8:7:200:0782:0725 \
--bitmain-checkn2diff \
--bitmain-hwerror \
--queue 8192 \
--api-listen \
--default-config /config/cgminer.conf
and: root@ant:~# cat /config/cgminer.conf contains: {
"pools" : [
{
"url" : "stratum.bitcoin.cz:3333",
"user" : "gigawatt.ant-bambam",
"pass" : "x"
},
{
"url" : "",
"user" : "",
"pass" : ""
},
{
"url" : "",
"user" : "",
"pass" : ""
}
],
"api-listen" : true,
"api-network" : true,
"api-allow" : "W:0/0",
"bitmain-nobeeper" : true,
"bitmain-freq" : "7:218.75:1106",
"bitmain-voltage" : "0725"
}
What the heck does the --bitmain-checkn2diff option do (play chicken with the diff? lol) google not so helpful here, not was the cgminer readme. I tried adding --suggest-diff 2048 (as one google search result suggested) but that command line option was rejected by cgminer as "unrecognized" {sniff} Well, glad it works for starters. At least we know it managed to get up to higher diff which was half the problem to begin with. I doubt that getting it to diff 2k would help any further. So if it hashes lower than that then there's still some remaining issue, and likely it's the choice of a halfway diff. Checkn2diff is a hack used by the slow bitmain products to round off diff to the nearest power of 2 since they're so slow at confirming hashes. There's a chance it may not be needed with the hack I added to the driver, so try removing that command line option. As for suggest_diff, only ckpools have that implemented at the pool end anyway so I didn't bother adding it to the driver (though it's easy enough for me to do). So try without checkn2diff next. |
|
|
|
Thanks, that's all anyone can ask!
Fudged my way through a cross compile, wedged shit in here and there, patched stuff, moved stuff around, can't remember what I did, but here's a binary: http://ck.kolivas.org/apps/cgminer/antminer/s4/4.6.1-141009/cgminerI have no idea if it really is for the right architecture, where you stick it on their filesystem or what to make it work or if it will just explode in a ball of flames, but there it is. |
|
|
|
Wait a minute, before you all go praising ghash... where did you see the owner of those fees come forth and identify themselves and when did ghash return it?
Ghash just said they did in post 7. Scroll up and see. Edit: Seems like the person hasn't identified themselves yet, but maybe they'll show themselves eventually. No, they said they have done so (the particular case was 2.8BTC). They did not say that have done so in this case, and there's no evidence of it having happened this time. Of course the onus is on the person who made the mistake to identify themselves first and request it. |
|
|
|
Wow, that's ridiculous. How can you make such a huge mistake. Lucky that ghash was nice enough to refund it though. So crazy..
Wait a minute, before you all go praising ghash... where did you see the owner of those fees come forth and identify themselves and when did ghash return it? |
|
|
|
After what I learnt from the S4 investigation, I checked the S3s, and they have a very diminished version of the problem with pools that start at low diffs. Here's an updated binary for the S3s. http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141009/cgminerThis might make startup/pool switching a bit smoother, especially if your pools start at diff 1 and take a while to increase their vardiff. EDIT: Hashrates even seem a little faster after a few minutes... EDIT2: No it's not any faster after longer running, it's the same overall performance. Only the startup won't overload the S3 controller on low diff starting pools. |
|
|
|
Any idea what does the 2.4.21 firmware brings?
Would be nice to have some sort of change log .. even if its high level to increase visibility to the SP community about changes introduced.
While I've not been involved in the firmware side directly, I've seen a lot of work going on behind the scenes to improve stability of the Murata PSU based devices which don't recover properly after the initial tuning attempts and the devices are more stable with the newest firmwares, so my guess is it's this. |
|
|
|
If you need anything, anything at all, like ssh access to an S4 such as my own, to use as a guinea pig rig, I am of course very eager to hook you up. Coffee? Adderall? A foot rub? Anything you need, mate! I have several fine quality first born children who are negotiable, as well!
Cute  I don't have an S4, and I'm not even sure what architecture they are to create a binary for them, so it'd be doing it blind. I'll see if I can figure something out if I find the time. No I'm not against paid work at all. I lost that inhibition when hardware companies were trying to make millions of dollars in profit while depending on my free software and rarely they'd toss me a peanut. |
|
|
|
P2Pool isn't optimal with my hardware
You could probably run S4s on p2pool if you just add +1500 to your username when connecting to it. I have a public p2pool node (0.5% fee ) you can try it on at p2pool.ckpool.org:9332 (just added the dns entry, 167.160.36.109 if dns hasn't caught up) This is not meant for long term mining. It's just for experimentation. |
|
|
|
I wonder if someone was thinking they would hoard a bunch of testnet coins, I know this has happened in the past and that's why testnet was reset (twice). I hope it doesn't have to get reset again because the more often that testnet gets reset, the less complexity and length it has and less of a good model for mainnet it is.
Your assumption is correct, though I've made it clear that's not acceptable. I mined some Testnet coins just for fun.
I offer to sell at a very low, symbolic price of 0.0001 BTC per Testnet coin.
I gave out 1000 testnet coins for nothing. You want 0.1BTC for that amount. That's not symbolic... 120,000 testnet coins have been minted in under a week on my free testnet pool with hardware that would mine 0.1BTC over about 6 months mining real bitcoin... Symbolic would be 1 satoshi per testnet bitcoin. |
|
|
|
Did bitmain say if they would replace the controller in the next batch - or will they just keep using the workaround (i.e. hack)?
They weren't even clear on if and when they'd use the hack, but the only US contact I have took the patch. I can only hazard a guess that there is zero chance of them using a different controller this late in their production phase. As for btcguild, to stay on topic, it's probably time you further increased the minimum/starting diff here anyway given what hardware is left hashing these days. |
|
|
|
|
You're pointing to your new profile. We can't make anything out of that.
|
|
|
|
I'm a little confused tbh, as ck says: It turns out the controller is so low powered that it can only process ~30 shares per second which mean that unless diff is set higher, they work their way into a death spiral before diff catches up. Great...
Which to me sounds like a hardware issue - or is it the firmware that decides how much power is provided to the controller? It's not a firmware issue. The controller hardware they bundle with it is not fast enough to handle running at low diffs, and most pools start at a lower diff for a while before vardiff pushes them up. If they stay low diff long enough the controller never catches up. I gave them a driver code workaround (i.e. hack) to get over this hurdle. It means they'll (appear to) run at low hashrates for a while until the pool reaches a diff suitable for the device. When they say it's a firmware issue, they mean they'll offer new firmware with an updated cgminer to address the issue. |
|
|
|
It turns out the controller is so low powered that it can only process ~30 shares per second which mean that unless diff is set higher, they work their way into a death spiral before diff catches up. Great...
(quoted from another thread)Is this a problem if one is using an S4 with solo.ckpool.org? No. S4s work fine here. |
|
|
|
Whoa... My worker count just doubled and my hash rate tanked. Doing any pool work ck?
Nope, didn't touch anything. I checked the logs and only your clients were misbehaving. They all seemed to reconnect over a 2 minute timeframe. The worker count can take a while to go down if you hadn't disconnected cleanly and the old instances are still in ckpool's recent memory. |
|
|
|
|
We concluded some S4 testing in the last 24 hours and confirmed they work perfectly fine on this pool. While it may be a conflict of my own interests, I've helped the bitmain team so that they can modify the devices to work better on all pools.
|
|
|
|
I did a buy on the S4's and their hashrate locally is 2th/s or greater (awesome!) however, when connected to BTCGuild NONE of them show anywhere close to 2 Th/s. They show more like 200 Gh/s. I have 2 that are over 1 Th/s, but the rest between 0 - 278 GH/s. WTF Bitmain?  The fix for now is to use GHash or BTCGuild with 2048 difficulty. Pools with vardiff seem to overload the miners at the start when spamming them with difficulty 16 shares. A new firmware is on the way soon TM. Not quite. Rapidly adapting vardiffs also do fine as the ckpool based pools do, but yes they'll hopefully bring out new firmware with the changes I gave them. |
|
|
|
|
Show Posts
