Still waiting to see some results from luke-jr...
Uh he's not doing anything, he tried to send this thread a cryptic message saying the topic was troll bait... |
|
|
|
|
New release: 2.10.5, 7th February 2013
Maintenance release improving on the already good 2.10.4
Linux binaries are now made against ubuntu 12.10 which also work on ubuntu 12.04
Windows binaries are built from a new cross compile setup of mine so they include a new set of DLLs to suit in the archive.
Human readable changelog
Fixed the memory leak, the size of which was proportional to stratum share submissions.
Sped up work generation on stratum even more.
Fixed (one of?) the corrupt stratum share submission bug (found by Kanoi).
Fixed a potential overflow that pools could theoretically use to crash your miner or worse (found by luke-Jr).
Full changelog
- Fix logic fail on partial writes with stratum send that was leading to corrupt
message submissions.
- Do not consider every call to stratum_resumed a pool recovery unless it was
actually idle.
- Do not enable the pool disable on reject feature unless explicitly enabled
with --disable-rejecting.
- Stratum disconnect shares - count total against stale
- Use sanity checking to prevent a possible overflow with invalid data being
given by the pool for difficulty as reported by luke-Jr.
- Check for calloc failure for completeness in gen_stratum_work.
- Cache the coinbase length to speed up stratum work generation.
- Cache the header length when generating stratum work to avoid calculating it
on every work generation, and to only need one alloc+sprintf, speeding up work
generation.
- Use heap ram for coinbase in gen_stratum_work, zeroing it before use.
- Provide a wrapper for aligning lengths of size_t to 4 byte boundaries.
- Fix memory leak on stratum share submission.
- Zero the best share string memory when zeroing stats.
|
|
|
|
|
Sweet on the vardiff! OOC did an analysis of variance and found that 20-24 shares per minute would keep it visibly within that of maintaining diff 1 shares so it seems a reasonable range to aim for 12-24 allowing some hysteresis on diff change. Note also that the spec for stratum specifies that when diff is changed, it is applied only to new work after that, as older work may be submitted at the old diff by mining software and this creates potential for lost work (when going down in diff) and rejects (when going up in diff).
|
|
|
|
How does one force GBT usage in 2.10.4?
Trying to poke the ASIC miner into GBT'ing from bitcoind, rather than getwork'ing.
I did not add support for GBT from bitcoind, sorry. It's a different protocol to GBT from pools. |
|
|
|
This is foto (my old USB cam) of a prototype board (4,8 GH/s):
Why different colors for the heatsinks? Stick with blue, you'll improve hashing rate by about 17.4%. Also the odd angle of the black one is causing instabilities in CGminer. I think I only provided support in cgminer for up to 15 degrees of black heatsink rotation, but 25 degrees for blue. |
|
|
|
Maybe con can enlighten us about the development process of the HPC client?!
After a brief look through my contract to remind myself of what I'm allowed to say, I can't say anything much about the progress of the HPC client nor surmise about the business strategies of Coinlab. What I can say is that I have virtually no input into the business strategies, nor do I participate in discussions regarding the business plans at large. Ultimately I'm just an outside coder and work on what I'm asked to work on, when asked to work on it. Sorry I can't give you more. |
|
|
|
|
Try some ridiculously conservative values, like shaders 96 or something.
|
|
|
|
cgminer mines scrypt/litecoin just fine on my nvidia GPU at an appallingly slow rate. Not that I mine with it, just test it works.
allright, gonna compile a debug build and send u the informations (in case u got some spare time) Chances I look at it are slim I'm afraid. |
|
|
|
|
cgminer mines scrypt/litecoin just fine on my nvidia GPU at an appallingly slow rate. Not that I mine with it, just test it works.
|
|
|
|
|
You don't see anything on a 51+% fork until it's all over.
|
|
|
|
Good news. Mining on BTC Guild with vardiff seems to have dramatically reduced the restarts.
That would almost certainly then be due to the memory leak associated with stratum share submission since you're submitting less of them you are getting a slower leak. The leak has been fixed in git, but unfortunately, you only have a binary... and we have no modified source code from them yet. Where is that anyway? |
|
|
|
Ckolivas,
Recently we introduced at coinotron.com support for stratum. I spent a lot of time reading logs from my pool looking for bugs.
I discovered strange behavior of cgminer 2.10.4 mining in Stratum mode. From time to time those miners send mining.submit RPC with interchanged extranonce2 and ntime. Like in following example:
{"params": ["xxxxx.ltc01", "1936", "510d2a61", "22000000", "5b5c6000"], "id": 1206, "method": "mining.submit"}
ntime extranonce2
There are even more exotic interchanges:
{"params": ["yyyy.yy", "510d2d4e", "1963", "06000000", "f7d60000"], "id": 8, "method": "mining.submit"}
Pool rejects such works. Is this known bug or effect of misconfiguration of cgminer?
Never seen anything like it, and I have no idea how it could happen? Here's the parsing code: job_id = json_array_string(val, 0);
prev_hash = json_array_string(val, 1);
coinbase1 = json_array_string(val, 2);
coinbase2 = json_array_string(val, 3);
bbversion = json_array_string(val, 5);
nbit = json_array_string(val, 6);
ntime = json_array_string(val, 7);
clean = json_is_true(json_array_get(val, 8));
and here's the submit generation code: work->ntime = strdup(pool->swork.ntime);
sprintf(s, "{\"params\": [\"%s\", \"%s\", \"%s\", \"%s\", \"%s\"], \"id\": %d, \"method\": \"mining.submit\"}",
pool->rpc_user, work->job_id, work->nonce2, work->ntime, noncehex, sshare->id);
Pretty straight forward so your guess is as good as mine? Unless there's memory corruption going on in the miner because of scrypt's weird and wonderful use of memory, but you're describing a simple swapping which is not like memory corruption. Could you track the message the pool sent when the miner returns something odd to make sure it was sent out ok, because this is the first time this sort of bug has been reported and other scrypt pools have been supporting stratum for a while? |
|
|
|
|
Yes the pool data is never relinquished to prevent a dereference from occurring if you delete a pool from the list and then a random share or work item tries to refer back to it after the fact. If you're not deleting the pool, the data needs to stay there till shutdown anyway, and no effort is made to clean it up just for the sake of it on exit. It is not a lot of ram and there's no point trying to chase it all down by keeping track of every single work item and share out there to see when none of them are referencing that data any more. It shouldn't actually increase in memory usage.
|
|
|
|
More people talking nonsense....
There are still algorithmic improvements, at some point in time further 'shortcuts' will be discovered.
Spotted at least one myself... problem is I'm not a maths guru.. so I cannot figure out a formula, but I can see it happening.
So why didn't these happen on GPU (which are pretty damn easy to reprogram). GPU algorithm mining efficiency has all but stalled. 18 months ago people were finding 10% here, and 3% there and that all essentially flatlined almost a year ago. I doubt there is much algorithm efficiency left. Now it is possible SHA-256 will be partially compromised which allows for the creation of "optimized" hashers which take that cryptographic flaw into account but that is hard to predict when or if it will happen. D&T is right. I can tell you both Diablo and I, along with numerous others along the way, have spent many hours trying everything to further tweak the algorithms as used by GPUs, and we have been unable to squeeze anything more out of it. I suspect the on-chip algorithm on the ASICs closely resembles these optimised OpenCL kernels as used by GPUs. |
|
|
|
i seem to have some problem with cgminer too. I downloaded 2.10.4 to re-try soloing LTC and i get this after opening:
"Connected to 127.0.0.1 diff 1.24M without LP as user nethead"
I get full gpu usage and it seems to mine (no blocks yet from this version) but why is the diff so high??
README last FAQ. |
|
|
|
So Stratum vs GBT  Which one should I use? (I plan to continue using cgminer) Stratum |
|
|
|
Guy's I am running my lancelot cluster on tp-link openwrt platform with 64M of ram. I am noticing the restart of my system because cgminer 2.10.4 slowly and steadily eats all of the available free RAM about 45M. And when cgminer eats all memory (45M) it takes about 2-3 days following happens Feb 1 14:36:53 cgminer kern.warn kernel: [281314.280000] miner 11 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Kernel kills cgminer because system is running out of ram Is there a way to reduce mem usage when cgminer is compiled for openwrt? 10X PS: Otherwise it runs perfect same as when my pc i386 was used. No hashing speed decrease. The only difference was that my PC had 4G of RAM  Yes there is a very slow memory leak in it which only becomes a problem at high hashrates on machines with little ram. A fix will be coming soon. |
|
|
|
What's with the high discarded work rate?
Normal, with new blocks you don't keep working on it, you throw it out to not create shares from stale work. |
|
|
|
|
Sure their first post is "unprofessional", but they're not asking you to send millions of dollars before there's any proof the hardware exists...
|
|
|
|
Copy/pasta: Once the video has been shot we have decided to ship the device to conman who in my opinion develops the best Bitcoin mining software available. Please check back for more updates. Well it's nice they decided to use me as their primary software developer if something ever goes ahead... but given conman is my IRC nickname and it holds certain "connotations", it would probably have been better to use my real name  |
|
|
|
|
Show Posts
