- Give warning with sdk2.7 and phatk as well.
- Whitelist sdk2.7 for diablo kernel as well.
Do i have to set the Kerneloption (-k ) to use the modified poclbm if a had an AMD 7xxxx with SDK 2.7 or does cgminer set it automatical? Don't do anything different to what you already do. |
|
|
|
|
New version - 2.7.3, 23rd August 2012
LATEST STABLE IS 2.6.6! DON'T USE 2.7.3
Not happy with 2.7.1, NOR 2.7.2, NOR 2.7.3 but this is what we're up to:
Bugfixes for networking, dynamic mode, new kernels, updated miner.php, and a bfl flash utility for linux.
Full changelog:
- Minimise the number of getwork threads we generate.
- Pick worksize 256 with Cypress if none is specified.
- Give warning with sdk2.7 and phatk as well.
- Whitelist sdk2.7 for diablo kernel as well.
- Only keep the last 6 blocks in the uthash database to keep memory usage
constant. Storing more is unhelpful anyway.
- BFL Flash - always distribute source
- Increase kernel versions signifying changed APIs.
- BFL flash - include source in builds and more FPGA-README
- Check we haven't staged work while waiting for a curl entry before proceeding.
- Use atomic ops to never miss a nonce on opencl kernels, including nonce==0,
also allowing us to make the output buffer smaller.
- Remove compile errors/warnings and document compile/usage in FPGA-README
- bitforce-firmware-flash.c by Luke-jr
- Ignore the submit_fail flag when deciding whether to recruit more curls or not
since we have upper bounds on how many curls can be recruited, this test is
redundant and can lead to problems.
- API-README update cgminer version number
- API-README fix groups P: example mistake
- API-README add COIN and other edits
- gpu->hit should be reset on new work as well.
- Do not add time to dynamic opencl calculations over a getwork.
- miner.php allow 'coin' is custom pages
|
|
|
|
|
Okay I believe I've found the problem with 2.7.1 and pushed it to master git branch (this is not included in the test binary I uploaded).
|
|
|
|
I saw another interesting glitch. I disabled, then removed pool 4, leaving pools 0, 1, 2, and 3, with priorities to match, and my next share was submitted to, pool 5. There hadn't been a pool 5 at all, so that was really weird, then it seemed to stop submitting good shares, so I quit and started over. Obviously there's probably not enough information here to even point toward the problem, but on the off chance that an event like that could lead to an epiphany, I would post about it. Regarding the git version, I'm not incredibly familiar with git and didn't have a lot of time to figure it out again. Moreover, I was still waiting to see if the problem I saw within 15 minutes of adding pool 4 the first time happened again, and it didn't all day, since I was done with that pool, I just happened to stumble upon this. In case this info is helpful, I'm still on a really old sdk, and I compiled with --enable-scrypt, which obviously won't function (as someone pointed out after I asked, and I may have previously known and forgotten). Point is, I don't know if these non-scrypt bugs are hanging out in the scrypt modifications or not, but maybe they could be? The only reason I'm not still on 2.4.(whatever the highest was) is because I was having high CPU usage in linux after pool problems, and finally decided to try to end them, 2.6.(whatever the highest was) still had that, and so did 2.7.0 and 2.7.1. I probably need to find stable pool or just quit mining since all I have is a 5830.
No, once a pool is removed, because there may still be work "in flight" it still keeps a reference to the old pool around till those work items are complete. After a couple of minutes no more shares will be submitted to it. Thanks tho. |
|
|
|
Alas that was the bug I was trying to fix going from 2.7.0 to 2.7.1. If anyone's on git and want to give the latest git master a try there's one tiny change which might help, but it's a long shot.
Well as usual no one puts their hand up, so here's a windows binary to test instead for those having the refusing to stay on one pool problem: http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe |
|
|
|
|
Alas that was the bug I was trying to fix going from 2.7.0 to 2.7.1. If anyone's on git and want to give the latest git master a try there's one tiny change which might help, but it's a long shot.
|
|
|
|
I'm having a problem with dynamic intensity with 2.7.1 on Windows XP:
When I start cgminer with dynamic intensity it generally operates around intensity 3 or 4 depending on what I'm doing on the PC. Last night I changed the intensity from dynamic to 8 (by typing "g, i, 8" in cgminer) and found the PC almost unresponsive this morning with an intensity of 13. I expected it to still be at 8.
Not at all expected behaviour. |
|
|
|
I am most certainly not going to give one more second's thought to scrypt.
Don't mean to make you think of it, but, what the heck is "scrypt" anyway? Sam Litecoin mining, which I hope dies and goes away. Why is that? Because I don't care about LTC, the software to mine it is really awkward, newbies keep coming around expecting me to hold their hands and explain it to them when it is not remotely trivial, and it complicates cgminer code and support. |
|
|
|
winsows 7 x64 driver 12.8 SDK 2.7 cgminer 2.7.1 after few hours run appear error : [2012-08-22 08:41:14] Failed to create get_work_thread Most unusual. That is a fatal error because there are too many threads running or the system has run out of ram. This bug falls into the "I have no idea" category. |
|
|
|
Autopayout should be working now. I had forgotten I disabled it earlier while I was working on the server trying to diagnose the connection issue. Should be good to go now, sorry about that . They will all process in about 8 minutes.
Yes, shares are still 1diff. I may bump that to 2diff, that shouldn't really affect anyone, but it will half the share returns, which is a huge gain, but in either case, I will make an announcement prior to doing that.
Note to miners on cgminer 2.7.0+, you will be able to see how much "work" you're still doing via the new "work utility" statistic if the pool changes the target difficulty. Your "utility" will drop because you will be returning less shares, but your work utility should remain the same. |
|
|
|
|
Further side note: cgminer DOES check for block solves when you are mining for bitcoin. It will say BLOCK! next to the share if it solves it, and will include block solves in the summary when you shut it down. However there is no way to magically make that block suddenly belong to your own wallet.
|
|
|
|
I am most certainly not going to give one more second's thought to scrypt.
Don't mean to make you think of it, but, what the heck is "scrypt" anyway? Sam Litecoin mining, which I hope dies and goes away. |
|
|
|
Hi, Big problems with my miner. I have been mining 2-3 months, but I had to make fresh install of my backup computer. All steps and logs are here: https://bitcointalk.org/index.php?topic=101758.0Please, someone? RCP calls and job curls are missing... I have spotted the part in cgminer.c code, but so far I have not added own debugging messages while I hope someone knows what is wrong. Absolutely no idea unless the 32 bit version of ubuntu you installed happened to have a broken curl library. |
|
|
|
New version - 2.7.1, 21st August 2012
Something odd : I have 6 mining rigs. 4 have multiple cards, 2 have a single card with a total of 21 cards. Until 2.7.1, I've had next to zero hardware errors reported by cgminer, only one card in the 21 had occasional (maybe 1/day) errors, it was a 5870 in a 5-card rig. With 2.7.1, I've got hardware errors reported on all cards in the rigs with multiple cards (in fact 18 out of 19 cards have errors). The cards in a single-card rig don't have errors reported (even a 5970 with its 2 GPUs, so if it may be linked to the number of cards, it's not with the number of GPUs). Could something have prevented errors to be reported with previous versions ? Some additional, maybe related information : I had hardware errors on a 7970 when I used 2 threads on it, switching everything to dynamic with a 250ms target made these errors disappear (with no noticeable difference in hashrate). All the cards are overclocked/downvolted/... but are set in a configuration which is(/was ?) known to be stable (ie: each time a card is SICK/DEAD or crashes cgminer it is downclocked), it's only when a new card is added that a rig can be temporarily unstable the time I find its sweet spot. Note that I detect card making cgminer crash by monitoring their temperature: on my configuration a card was most of the time not detected SICK (I suspect it as something to do with my using the API to monitor the rigs: it seemed to crash cgminer before the 60s SICK delay) but crashed cgminer, before each crash I could witness the temperature of the offending card dropped markedly. Nothing I can think of that "prevented errors" directly apart from the fact that 2.7.0+ will work the GPUs harder than ever, with very little chance of rest between work unless you have a significant outage. |
|
|
|
So I tried to use scrypt on cgminer 2.7.1 just to see what kind of hashrate I would get with my 5830. This is the command I ran:
Needs sdk 2.6+ |
|
|
|
Hopefully the dynamic mode for GPUs is fixed on windows.
What about on Linux? I've been noticing the -10 bug pop up since I upgraded to 2.7 last night. I've had to start just manually switching my intensity from 4 to 6. Hmm then that's almost certainly related to one long getwork skewing the results. In which case it is not fixed in either linux or windows on 2.7.1. Darn, well at least I know what to fix next. |
|
|
|
I can confirm this. At first I thought it was because I manually added a pool while cgminer was running and that messed it up, but now he's posting a similar issue. Did you add a pool like me or did it switch and fail to switch back on its own Morblias?
It switched and failed to switch back. Was bonuspool the common element? |
|
|
|
Other vector sizes have been tried. They suck.
They've been tried with scrypt you say? Because, with scrypt, a lot of the overhead is shifted to the loading and unloading of data. And I recall having 8 vectors working for me better than 4 with the VLIW5 based GPU as long as the code could be written to support it. Instead of just one uint8, we have two uint4 variables that have to load back and forth. Now, it might just be me, but that seems rather inefficient doing that many reads and writes. If someone would give it a try, I think we could determine it once and for all. Blow yourself away, because I am most certainly not going to give one more second's thought to scrypt. |
|
|
|
|
New version - 2.7.1, 21st August 2012
Bugfixes galore \o/ The emphasis was just on outstanding bugfixes on this release to try and get a nice stable release out after the frantic pace of development recently.
Human readable changelog:
The occasional strange behaviour where lots of work would end up on backup pools in failover mode should be fixed.
The occasional scenario where one pool dies and the others behave like they're slow to provide work should be fixed.
Very high hashrate (U > 100) machines should now be able to work unhindered even on pools that don't support rolltime.
The -r and -R options no longer do anything and are deprecated in preference for faster communications and simpler code.
Hopefully the dynamic mode for GPUs is fixed on windows.
cgminer dying on switching users on windows should be fixed (it may actually restart itself to recover unless --no-restart is specified).
Hopefully the 7 day windows crash bug has been fixed
Share submissions that are re-sent will have (resend) appended to the log
Hopefully the gpu-map feature is working for more adl devices than opencl.
BFL autodetect fixes on windows.
New API features
New miner.php features.
Full changelog:
- Update windows build instructions courtesy of sharky.
- Increase max curls to number of mining threads + queue * 2, accounting for up
and downstream comms.
- Queue enough requests to get started.
- There is no point trying to clone_work in get_work() any more since we clone
on every get_work_thread where possible.
- There is no point subtracting 1 from maxq in get_work_thread.
- Only set lagging flag once there are no staged work items.
- select_pool does not switch back to the primary once lagging is disabled.
- miner.php allow page title to be defined in myminer.php
- Free work before retrying in get_work_thread.
- Increment total work counter under mutex lock.
- Increment the queued count after the curl is popped in case there's a delay
waiting on curls and we think we've queued work when in fact we're waiting
- API new command 'coin' with mining information
- Do the dynamic timing in opencl code over a single pass through scanhash to
make sure we're only getting opencl times contributing to the measured inte
- Increase curl reaping time to 5 minutes since comms between curl requests can
be 2 mins apart with lots of rolltime.
- No need for extra variable in hash_push.
- Remove short options -r and -R to allow them to be reused and remove readme
entries for deprecated options.
- Avoid attempting to recursively lock the console mutex by disabling warnings
in gpu_fanpercent when fanspeed monitoring fails on windows. Debugged by luke-jr
- Deprecate the opt_fail_pause parameter, leaving a null placeholder for
existing configurations.
- Don't pause after failed getwork, set lagging flag and reassess.
- Add message to share if it's a resubmit.
- We should not be pausing in trying to resubmit shares.
- Get rid of the extending fail pause on failed connects since we discard work
after a period.
- get_work always returns true so turn it into a void function.
- get_work never returns false so get rid of fail pause loop.
- Get rid of pause and retry from get_upstream_work so we only do it from one
place.
- Deprecate the opt_retries feature as no one wants cgminer to automatically
abort. Leave a null placeholder for configurations that still have it.
- Reinstate fix ADL gpu-map not working when there are more ADL devices than
openCL patch by Nite69. Add virtual adl mapping for when none is specified o
- miner.php show summary Diff1 Shares total
- miner.php fix Work Utility totals
- miner.php format new Work Utility and Diff1 Shares
- API V1.17 show Work Utility and Diff1 Shares
..and now I may lie down for a week to recover...
|
|
|
|
On second thought, there may be a bug here... will investigate tomorrow.
About this, I have confirmed there is a bug in 2.7 where it can get into a situation where it can't queue enough work and continually thinks one pool is not providing enough work. I have fixed this in git but this has introduced a new crash which kano is trying to help me track down. In the meantime, anyone on 2.7.0 should probably enable --failover-only to mitigate its problems. |
|
|
|
|
Show Posts
