Would it be a suggestion that the server can take under advisement and choose to ignore?
I suggested this already, but there was almost no response by miner developers (cgminer). In oposite to mining.resume, mining.suggest is trivial to implement on pool side or it can be ignored if pool doesn't understand it. Just tell me what to do and I'd implement it, bugs and all. |
|
|
|
Here are some photos from Kanoi on his trip to BFL to inspect their ASIC progress. He returns this weekend, and the chips have not yet arrived to be assembled, as they're still in the bumping facility - BFL couldn't manage to make the bumping facility work any faster, but they're poised and ready to assemble when they do. http://198.245.60.111/Pix/Meanwhile myself and him have made some progress generically on preparing for ASIC support in cgminer, but the real driver won't be written until there's some hardware to actually test it on. If anyone's in Australia and interested in buying the 7970s used by me in developing cgminer, now's your chance to buy one  http://www.ebay.com.au/itm/SAPPHIRE-HD-7970-3GB-GDDR5-/321074334615Ironically I've made some tiny improvements to the OpenCL kernel and will be squeezing a few tiny drops more out of them in the next cgminer release. I feel it's my last chance to do anything with OpenCL and bitcoin mining and I'm gonna miss it. |
|
|
|
Hope kano can change his return flight then because it doesn't sound like there's going to be much to see in Kansas City this week.
Kano cannot change his plans as he has to leave on Saturday. |
|
|
|
Luke, I thought you were still using this full of bugs codebase.....?
Luke , have you submitted a support ticket to Con, so he can help you out?
He submitted 2 bugfixes, I took them. After that... no idea, but then I go out of my way to make myself uncontactable by him, but somehow he still gets through. I'm in a quandary here if I'm to fix bugs he reports but I don't give him a way to report them apart from random attacks on the codebase in the forum as quoted by someone else. If he could stop with the mindless attacks and other crap, I'd listen and he'd have a way, but I can't sift through his noise because it really is a mindfuck. I really should give up, this is doing my head in. |
|
|
|
They should have stuck with the original plan of Josh baby-sitting the chips once they left the fab - at least then BFL might have some clue what's going on. As it stands, Josh doesn't even know what's going on at the bumping facility because he can't get in touch with his contact.
kano's silence is also deafening. He's over in the US to report to the community on BFL's progress and hasn't posted anything since he got there.
Actually he's been exclusively talking at length on IRC in the cgminer channel. Summary: Lots of activity, lots of preparation, lots of hardware ready to be assembled, but no sign of the actual chips which are in the bumping facility... |
|
|
|
|
You're welcome.
The issue is some disconnects are impossible to detect, apart from noticing the pool has gone silent for an extended time. During that sort of outage, cgminer continues mining until it times out, not getting a response. The timeout needs to be long enough to be sure the pool is no longer sending info, and not too long to waste ages mining. So yes, it keeps mining. Anyway hopefully this should be better since the next version will include support for the new mining.resume function. This is already built into the git version, but only rEligius currently supports it. Hopefully other pools will follow suit.
|
|
|
|
|
If you wish to pay in BTC, you can bid on ebay for it in AUD and then I will be happy to accept payment in BTC at the current mtgox rate should you win. Remember there is also 20 AUD in postage, and it's for sale in Australia only.
|
|
|
|
Thanks for that. In the condition that code is, I can't really merge it into the mainline cgminer code. I'm not sure what your long term plans are for your hardware, as to whether it will evolve further, run off other hardware, be manually update-able, etc, but you might at least benefit from trying to stay in sync with the master branch of cgminer, and if you made the code in such a way that it didn't just work on avalon hardware, it could be merged into cgminer master. Then it's possible others can add bugfixes, improvements etc. although these are hard to do without actually trying them directly on the hardware. Please don't remove the copyright of authors who clearly contributed to the original versions of files you have copied and modified, such as from the Icarus code, to suit the Avalon hardware. |
|
|
|
|
Well, an extra authorise request is no big deal, so for the moment, that's how I've implemented it in cgminer. So most of the mining.resume support is now in the master git branch for cgminer.
|
|
|
|
Why are you sending mining.subscribe after mining.resume??
I don't think there's any security issue. If the "attacker" knows the session id, then he obviously also known passwords used by workers for authentication.
My mistake about redoing mining-subscribe. Fixed in git. I will await to see what others have to say about needing to re-authorise since the only implementation currently does expect it. |
|
|
|
If mining.resume is successful, does this mean the miner does not need to do mining.authorize afterwards?
Yes. If pool returns true for the call, it means the connection can continue like if it wasn't interrupted (so no authorization is needed). This is current response of mining.subscribe(): {"id": 1, "result": [[], "08000002", 4], "error": null}\n
This is response containing session id: {"id": 1, "result": [[], "08000002", 4, "some-session-id"], "error": null}\n
This is also valid response of the server, but no session id is given, so no resume is available: {"id": 1, "result": [[], "08000002", 4, null], "error": null}\n
Thanks. In the preliminary support in rEligius, wizkid tells me they still expect mining.authorize after mining.resume, and then they sent a new session-id which seems counterintuitive to me? [2013-02-15 22:03:25] SEND: {"id": 2, "method": "mining.resume", "params": ["08000000"]}
[2013-02-15 22:03:26] RECVD: {"result": true, "id": 2, "error": null}
[2013-02-15 22:03:26] Resumed stratum connection to pool 0
[2013-02-15 22:03:26] SEND: {"id": 3, "method": "mining.subscribe", "params": []}
[2013-02-15 22:03:26] RECVD: {"result": [[["mining.notify", "090000001"], ["mining.set_difficulty", "090000002"]], "09000000", 4, "09000000"], "id": 3, "error": null} I would have expected that mining.resume is enough without needing authorise, and then there would be no new mining.notify, and the sessionid would be the same. Are there any security implications with allowing a miner to reconnect without re-authorising? I can't think of anything significant. |
|
|
|
miner will call mining.resume('session-id') instead of mining.subscribe(...). Also can you elaborate on the exact format of mining.subscribe with an example please? I'll inevitably get it wrong if I don't see a sample. |
|
|
|
If just one pool op decides to implement this, I will support it in cgminer.
No problem. I just hope that the first daredevil will implement it properly, so response of mining.subscribe will have one extra argument 'session-id': {"id": 1, "result": [[], "08000002", 4, "some-session-id"], "error": null}\n
If this parameter is set and non-null, the miner will store sesssion id internally and then, after the crash of the connection, miner will call mining.resume('session-id') instead of mining.subscribe(...). Pool will respond with true/false. If true, miner can continue in the previous session (so re-upload pending shares, ...), if false, miner must call mining.subscribe and throw away pending shares. Correct? Nice. If mining.resume is successful, does this mean the miner does not need to do mining.authorize afterwards? |
|
|
|
If something, then go with mining.resume() and let the pool decide if he'll accept it or not. However I don't think anybody sane will want to implement full mechanism of session resuming.
You have certainly expressed your disinterest in implementing it, but that is not the case for all other pool ops. If just one pool op decides to implement this, I will support it in cgminer, and as per always, once one pool has set the standard, it would be crazy for others to not follow. So who's first? |
|
|
|
User 67117 has now become the first connection on Stratum to reach a 4-digit variable difficulty.
[00:39:31] Increasing [obfuscated]'s difficulty to 1024!
What does that mean? It means somebody mining at 1.5+ TH/s is using roughly as much bandwidth and server resources as a miner running a graphics card over Stratum, and LESS bandwidth than a graphics card using the outdated getwork protocol.
Sounds great! Do you use the client.get_version command with your stratum implementation? It would be interesting to know what software they apparently run. |
|
|
|
|
The scrypt opencl kernel in cgminer was copied almost verbatim from reaper.
|
|
|
|
I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date. 13.1 is fucked. Would it be possible to update the first post with the optimal driver/sdk config for CGMiner? Not knowing this, I just defaulted to latest  It keeps changing as AMD skillfully keeps releasing broken shit... plus GPUs are going the way of the dodos shortly for BTC, so our attention to GPU issues is dropping off to almost zero. Try driver 12.8 |
|
|
|
I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date. 13.1 is fucked. |
|
|
|
|
Show Posts
