Usually my 2 cm1's using the hashvoodoo175 bitsteam (very stable) give a combined U rating (cgminer) of 19.1-19.2
So I figured moving to diff10 at best will give me 1.9 and put less pressure on EMC servers, overall it's a win, even if not for me.
I've been mining for a while and it's bouncing between 2.0 and 2.1, so I consider this to be a nice win-win.
So moving to diff10, has given me a nice boost in average hashing power per minute and theoretically diff10 should be less strain on the server than diff1. I won't be trying diff1 on my laptop, It only just manages u rating of 1.
There is no boost in hashing power. Utility has always been proportional to hashrate x luck. If it's high at the moment, that's luck. |
|
|
|
If anyone wants to play around with 10Diff shares: diff10.eclipsemc.com port 8337
Give it a shot and see if anything breaks!
I'm running two BFL singles with cgminer 2.7.4 on the diff10 server. Here's what it looks like: cgminer version 2.7.4 - Started: [2012-08-24 12:31:53]
--------------------------------------------------------------------------------
(5s):1612.6 (avg):1588.3 Mh/s | Q:225 A:194 R:1 HW:0 E:86% U:1.9/m
TQ: 0 ST: 3 SS: 0 DW: 65 NB: 17 LW: 3719 GF: 12 RF: 0 WU: 21.2
That all looks about right. Your work utility is about 10 times higher than your utility and variance will be much greater at difficulty 10 which is why it isn't exact. Furthermore your efficiency is at 86% despite the 10x difficulty, which would be about 860% at normal difficulty. All in all you're getting a lot less work from the server since it supports rolltime, and submitting a lot less shares since it's diff10. Assuming the calculations for rewards are correct, this is good news for the server. The efficiency with cgminer will go up the faster the rig is. |
|
|
|
On btcguild.com, I click on reset for the worker.
Then, I restarted cgminer, somehow it solves it. It is reporting 1.2GH.
Now I added back the primary pool GPUMAX, and now GPUMAX is also showing correctly.
This is when I say what just happened? I didn't know what I did to fix it.
A lot of pools lately have been doing upgrades/fixes and the hashrate is something a lot of them have been showing wrong until the changes are complete. |
|
|
|
Thanks. Plan to once a stable release is out.
2.7.4 gets me ~10% less hashrate than all recent versions (including 2.7.1, 2.7.0 and 2.6.5 for fresh comparisons) on a 5870 with SDK 2.1 (ati-drivers 11.6) on Gentoo amd64. Didn't test 2.7.2 or 2.7.3. 2.7.2/3 will not even work on sdk2.1. It appears the kernel changes are not so great for sdk2.1. Oh well. There's a suggestion from IRC that those with ultra low memory clock speeds on sdk2.4/2.5 are seeing this, and going from say 150 to 250 is enough to recover it. Perhaps it's not the SDK at all but the memory speed. EDIT: Just to further explain why these changes have been made to ALL the kernels. Basically there are some small probability scenarios where some shares are missed by the existing kernel designs. It's not a lot, but given btc mining is entirely a probability game, we need everything on our side. |
|
|
|
Is it possible to know if you are going to solve a block, then just not pass that information on to the pool's server (just to be a jerk)?
Yes, that's a withholding attack. But all you're doing is making the pool poorer. Why would you want to do that? |
|
|
|
Thanks. Plan to once a stable release is out.
2.7.4 gets me ~10% less hashrate than all recent versions (including 2.7.1, 2.7.0 and 2.6.5 for fresh comparisons) on a 5870 with SDK 2.1 (ati-drivers 11.6) on Gentoo amd64. Didn't test 2.7.2 or 2.7.3. 2.7.2/3 will not even work on sdk2.1. It appears the kernel changes are not so great for sdk2.1. Oh well. |
|
|
|
New unstable version: 2.7.4Fixed some shit. Added some shit. Will only call it stable once it's tested by others. What a rotten day  You really need some rest. Thanks. Plan to once a stable release is out. |
|
|
|
New unstable version: 2.7.4
Fixed some shit. Added some shit. Will only call it stable once it's tested by others.
Full changelog
I upgraded from 2.7.0 to 2.7.3. Two of my miners crashed w/o me noticing it. On 2.7.4 now. First thing I noticed is the efficiencies are consistent now across my miners. Instead of some being way of the charts, and others just off the charts, now they are all off the charts like they are supposed to be. All using local instances of p2pool. M Yep and true efficiency should be higher than ever. |
|
|
|
Generous donations, thanks very much guys  |
|
|
|
2.7.4 is saying that it's 2.6.6 and it won't start properly for me.
Re-uploaded with correct binaries. |
|
|
|
cgminer detects stale shares and does not submit them. However, there are pools which credits for stale shares. Is there an option how to force cgminer to try to submit all shares?
It eventually gives up even with submit stale if it has already tried sending them at least once. Otherwise you could end up with a billion shares waiting in the queue, out of memory and crash. |
|
|
|
|
New version: 2.7.4, 23rd August 2012
All the showstoppers are fixed. Status upgraded to stable on this release.
Human readable changelog
Once again completely rehashed the work queueing mechanism trying to take -everything- into account. It should all be fixed now.
There are updated kernels here designed to never accidentally miss a share which previous kernels might have - if you underclock your memory a lot, you may find it needs to be slightly higher to not lose hashrate, increasing memory from say 150 to 250 OR you may need to play with worksize on R5xxx if previously you found 128 better because it defaults to 256 now. Others might even notice a slight increase in hashrate.
Full changelog
- Perform select_pool even when not lagging to allow it to switch back if needed
to the primary.
- Simplify macros in output kernels avoiding apparent loops and local variables.
- Carry the needed bool over the work command queue.
- Move the decision to queue further work upstream before threads are spawned
based on fine grained per-pool stats and increment the queued count immediately.
- Track queued and staged per pool once again for future use.
- OpenCL 1.0 does not have native atomic_add and extremely slow support with
atom_add so detect opencl1.0 and use a non-atomic workaround.
- Pools: add RollTime info to API 'stats' and 'Stats' button in miner.php
|
|
|
|
windosw 7 x64 SP1 Driver 12.8 SDK 2.7 cgminer 2.6.6 - crash ! [2012-08-23 15:15:44] Started cgminer 2.6.6
[2012-08-23 15:15:45] Probing for an alive pool
[2012-08-23 15:15:45] Long-polling activated for http://lp.abcpool.co:8337/longpoll
[2012-08-23 15:15:45] Unable to open diablo120724.cl or ./diablo120724.cl for reading
[2012-08-23 15:15:45] Failed to init GPU thread 0, disabling device 0
[2012-08-23 15:15:45] Restarting the GPU from the menu will not fix this.
[2012-08-23 15:15:45] Try restarting cgminer.
[2012-08-23 15:15:57] Unable to open diablo120724.cl or ./diablo120724.cl for reading
[2012-08-23 15:15:57] Failed to init GPU thread 1, disabling device 1 Redownload the zip file please. |
|
|
|
|
Stable release update: 2.6.6
Right, I am totally utterly completely over 2.7, so I've released a stable release of 2.6 without the queueing and kernel changes in 2.7: 2.6.6. Get it in the usual place.
|
|
|
|
Hi. I have a severe bug. I was using 2.7.1 no problems. I tried 2.7.3 and got this error.  restarting cgminer doesn't fix it. it prevents me from mining entirely. I am using a single 5870 on 12.1 driver, 2.1 sdk (platform 1 specified in conf file), dynamic intensity, phatk, worksize 128, and vectors = 2. I reverted back to 2.7.1 and have no problems. windows 7 x64 ultimate Looks like sdk 2.1 doesn't support atomics. I had no idea... hrm.... This is one endless series of fucking bullshit. I can't seem to get out of the cycle of upgrade=break. |
|
|
|
|
Yes, if you blinked, you missed 2.7.2.
|
|
|
|
- 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. |
|
|
|
|
Show Posts
