|
By the way I spotted that it is still possible for a few untracked shares to rarely show up, but for the most part it is only a cosmetic issue and is corrected in the current git tree.
|
|
|
|
Actually come to think of it, perhaps the results are coming back before the database entry is even being created. Hmm
I connect cgminer to the mining_proxy which itself connects to the Slush's pool. Both connections are via Stratum. This way I get cgminer stable on network outages. Maybe it is also a reason of getting an extra-fast response by cgminer from the other end of Stratum. Yes, being a local proxy it responds quickly which is why you can reproduce it. Try 2.8.7 please. |
|
|
|
Hold on while I respin the 2.8.6 release as 2.8.7  ... it hasn't been out that long  Pretend you didn't see anything... |
|
|
|
Testing 2.8.6 on Win7 x64.
There are lots of messages "Accepted untracked stratum share" among regular "Accepted 68132465..." ones.
What do they mean?
p.s. It took about 50 sec to recover normal operations when I switched to another wifi network.
And it died when I switched back.
That means the stratum pool you are mining with is returning "accepted" messages without the same ID that cgminer sent the share with, so cgminer doesn't know which shares the pool is accepting. The communication is all done asynchronously and cgminer keeps a database of sent shares so that when it gets a response from the pool it can tell you which share it was. Actually come to think of it, perhaps the results are coming back before the database entry is even being created. Hmm |
|
|
|
Testing 2.8.6 on Win7 x64.
There are lots of messages "Accepted untracked stratum share" among regular "Accepted 68132465..." ones.
What do they mean?
p.s. It took about 50 sec to recover normal operations when I switched to another wifi network.
And it died when I switched back.
That means the stratum pool you are mining with is returning "accepted" messages without the same ID that cgminer sent the share with, so cgminer doesn't know which shares the pool is accepting. The communication is all done asynchronously and cgminer keeps a database of sent shares so that when it gets a response from the pool it can tell you which share it was. |
|
|
|
P2pool. Which has always been based on variable difficulty and fast local work generation.
Not quite... it actually accepts diff 1 shares and tests them all against its internal variable difficulty, and still operates off the getwork protocol. In its current form I'm pretty sure it would consume a lot of CPU trying to keep ASICs busy since it already consumes quite a lot of CPU without this added load. |
|
|
|
|
New versions -> 2.8.7, 29th October 2012
Mainly stratum fixes for windows plus minor tweaks and cosmetic changes.
Human readable changelog
After much wrestling I've discovered that windows happily sends stuff into sockets for a long time after they're dead and finally found a workaround that would realise it couldn't send them. I'm assuming the crashes people were seeing on windows are related to overflows with this phenomenon and hopefully this will improve stratum reliability further on windows.
Pool timeouts on unresponsive pools with stratum should be picked up sooner.
Failure to submit shares with stratum now also registers as an RF remote failure.
Kano tracked down a longstanding memory leak which was small but did add up over time when GPU mining.
There is a new "compact" display mode you can specify with --compact or enable it in the menu during runtime which only shows the summary stats and not a line for each device, in case you have heaps of devices and they don't fit on screen.
The best share difficulty is now displayed in the status window at the top, and in the summary on exiting.
Some details have been trimmed from the pool listing in the status window in the interest of screen real estate efficiency.
Full changelog
- Fail on select() failing in stratum thread without needing to attempt
recv_line.
- Add share to stratum database before sending it again in case we get a
response from the pool before it's added.
- Shorten the initiate stratum connect timeout to 30 seconds.
- Shorten the stratum timeout on read to 90 seconds to detect unresponsive pool.
- Display best share difficulty on exit.
- Make stratum socket fail more robust on windows by disabling the send buffer.
- Reuse the same curl handle forcing a new connection instead of risking
derefencing.
- Add information about submission failure to stratum send.
- Only add stratum share to database if we succeeded in submitting it, with a
debug output saying it succeeded.
- Use keepalive with stratum sockets to improve its ability to detect broken
connections.
- Show only the URL in the status bar to avoid long prefixes making for extra
long lines.
- Display compact status in menu and update README to reflect current menu
entries.
- Add a compact display mode that does not list per device statistics in the
status window.
- Add blank spaces after best share displayed.
- Round a few static string arrays up to 4 byte boundaries for ARM.
- Display best share diff for scrypt as well.
- Show the best diff share as "best share" and add info to the README.
- Display the best diff share submitted so far.
- Redundant check.
- The work struct pointer in struct pc_data in findnonce is never freed yet
there is no need to allocate it separately so make struct work a static part of
the struct pc_data.
|
|
|
|
been running great under windows vista/7 so far.
Thanks!
EDIT: say, what does "rejected <hash, stats etc> job '57f7' not found" mean?
With stratum mining that's whatever return code the server has given you for the rejection. That one usually means it has asked you to start on new work and that share is from the old work. i.e. stale. |
|
|
|
Already underway  This is new in the display of the next version: Block: 029a31ecc6e1269154fd5c6b... Started: [08:12:07] Best share: 7.58M Very cool, can't wait.  How does cgminer know if it found a block? It doesn't know the network difficulty, does it? It does, from the work. |
|
|
|
I got a share that registered a diff of 7.58M  That was a block solve for mtred since current difficulty is just over 3 million.  You should add a stat upon shutdown for highest difficulty achieved. I noticed you already put in one for telling you when you found a block. Already underway This is new in the display of the next version: Block: 029a31ecc6e1269154fd5c6b... Started: [08:12:07] Best share: 7.58M |
|
|
|
I got a share that registered a diff of 7.58M That was a block solve for mtred since current difficulty is just over 3 million. |
|
|
|
Thanks for the reply. I don't think that REST and re-enabling a GPU should be causing it to crash. I'm currently mining on a pool that uses var diff also. Not sure it that help.
I wasn't saying that was necessarily the cause of the crash, but it's worth noting that you had an overheat anyway. |
|
|
|
CGminer crashed on me again today with the "Cgminer program has stopped suddenly" or something to that sort. Anyhow, I could see behind the message popup, and it looks like Cgminer put a GPU to REST mode, and then tried to re-enable it, and this is when it crashed. I'm currently on W7 with version 2.8.5. Thanks!
REST is usually due to an overheat event, unlike SICK and DEAD. |
|
|
|
I've been thinking why not hard code the --fix-protocol into 2.8.6+ since it seems to do the job very well. (and add a --no-fix-protocol option instead?)
Because Stratum will hopefully be the default mining protocol soon. Better to get the bugs out of the way now. Right. |
|
|
|
Haha - totally forgot about Schrodinger's Cat. Am so glad the cat is alive  This image haunts me. Am glad to hear cgminer will work with BFL SC line Ckolivas and lodcrappo - BAMT and cgminer work so nicely together! My little 7 GPU mining setup has been running reliably for months, even on a weak wifi signal... I just wish I had discovered this genius combination a year or so ago. From 95F to 30F ambient temps, I never have to worry about fan settings, auto-downclocking etc with cgminer. The best part is how it all can be reset with a simple power cycle, by using BAMTs ultra-easy config file. Although cgminer can be re-added to BAMT, it'd be a shame for an updated version of it not to be included in the BAMT image. People should have the option of a future version of cgminer, so they can discover from day 1 of testing that cgminer will have been the correct choice. Lodcrappo, Ckolivas is a non-stop improver, and I'm sure cgminer will continue to have its strengths over other miners in the ASIC era. I'm looking forward to the next BAMT release, where it'll be run on a mix of FPGA and ASIC (and possibly GPUs to heat my garage area ambient temp to above freezing during this transitional time) ! Thanks. However I'm pretty sure Lodcrappo won't be reading this particular forum thread. |
|
|
|
Ok I see what's wrong here. The expire= parameter with x-roll-ntime is how many seconds after the getwork is sent that the miner is allowed to roll time for... it is NOT how many "seconds of rolling equivalent" they're allowed to add to the timestamp. That should be limited only by what bitcoin would accept, which is a maximum of 7200 seconds.
The spec seems to imply (to me) BOTH the allowed values of the timestamp AND a deadline time for which they will be accepted. As a practical matter, we even accept work with larger timestamp rolls as long as the block being worked on is still current. I suggest you ignore the timestamp entirely so long as it's within 2 hours of the getwork generation since that's how the spec is implemented by mining software and other pools alike. We do. The only thing we check is work age. We measure how old the work we gave you is. If it's stale, we still give you credit if it falls within our 60 second grace period. So PLEASE DO send stale shares to us (but please also refresh your getworks each 60 seconds). If you do both of those, I see no reason why miners on our pool would see anything but 0% stales. Great And cgminer submits stale by default unless it has tried multiple times to submit it and the pool is unresponsive. |
|
|
|
Does anybody know if cgminer will be able to work with the new ASICs? It's the only miner I use in my BAMT setup I know the author of cgminer is working directly with Tom for the bASIC hardware support. Yes, I will be developing for both bASIC and the BFL SC devices. However, BAMT is dropping support for cgminer. See: https://bitcointalk.org/index.php?topic=65915.msg1146320#msg1146320 |
|
|
|
Variable difficulty -has- to adjust upon new work without being opened up to exploitation, regardless of protocol used. It's very simple for a fast miner to withhold higher difficulty shares when it knows that it's going to force a difficulty increase, then submit them for higher credit once the adjustment lands.
Which - if I'm reading the spec right - is quite hard to do with the current protocol. Even if you change the difficulty at the exact same moment as sending out a new work unit, the difficulty change applies to all the previous work units and miners are allowed to continue working on those at the new difficulty unless you invalidate all of them at the same time. Except that if you do that, you're making the miner throw away work they've done without submitting it. There's a mismatch between how the protocol wants you to handle difficulty changes and the way you actually need to handle them to prevent cheating by miners. btcguild is the only stratum pool with variable diff, and it sends out a clean work with every difficulty change meaning all work gets thrown out with each diff change. Even blocks and valid shares at the new diff get thrown out I might add. |
|
|
|
To be fair, I had exactly the same discussion with Eleuthria but I had bigger fish to fry and stopped caring about it. He or slush can come and defend why they think it's ok. |
|
|
|
Since this is the Speculation subforum... I don't see the point of CoinLab's second half. To me, they started as a bitcoin pool, but wanted to be more than that. Now they have to be more than that to survive, but I can't see how they actually plan on doing that. Actually coinlab was never going to be a bitcoin pool as far as I can tell. I'm guessing the pool was found to be a good stepping stone for people with GPUs to get out of the bitcoin mining scene when it becomes unprofitable. Disclaimer: I work for coinlab but only as a software contractor and have very little knowledge of the goings on in the company. |
|
|
|
|
Show Posts
