I flashed with 2013-08-10 yesterday, and my hashrate appears to have dropped. I was using 2013-07-03 earlier.
|
|
|
|
If we are going to be smoking weed and imagining things... "I have a litecoin miner that paid for itself in 144 hours". lol if you pick the right altcoin you can make your rig costs back very quickly  You sir and GSnak, I salute thee for giving me one of the finest bitcointalk laughs ever. |
|
|
|
|
The --avalon-auto option already does precisely that: it uses a rolling average to adjust frequency rather than an all time average.
|
|
|
|
...however, what are you doing with that figure?
OK, at the risk of this being a trick question, I'm going to humiliate myself by saying "we display the value thus adding readability"? I'm not trying to humiliate you. I'm asking if you have a valid use for the figure. Whether it changes your mining in any way? |
|
|
|
I don't have any intention of including the hw error % as a separate statistic. I also don't understand why you'd start deleting statistics from debug output like that, and I have to tell you your calculations are completely wrong.
You don't think adding the hw error% will cut down on all those questions from people what have difficulty interpreting the confusing numbers? Not sure what you mean by deleting statistics from debug output and for the record, I am only referring to the thread by Ben Turas https://bitcointalk.org/index.php?topic=254331.0 My math is even worse than his ;-) It's probably (100*hw/(diffaccepted+hw))
? That is the correct equation. ...however, what are you doing with that figure? |
|
|
|
|
BFL chips don't start creating hardware errors till 85 degrees and don't start throttling till 90 degrees, so this is not as big a problem as you might think...
|
|
|
|
|
I don't have any intention of including the hw error % as a separate statistic. I also don't understand why you'd start deleting statistics from debug output like that, and I have to tell you your calculations are completely wrong.
|
|
|
|
I've completed the rework of the stratum work generation code which was where most of the high CPU usage on p2pool was, and uploaded new firmware with the newly released version 3.3.3 of cgminer:
Updated link, with slightly newer firmware addressing slower speeds on auto: http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/ |
|
|
|
First problem found in --avalon-freq <arg> Set frequency range for avalon-auto, single value or range
with range set from 330-360 this is not working and miner has been sat on 330 for over an hour not increasing on decreasing in speed yet on previous version was working?
There's a regression where auto doesn't go quite as fast as it used to, I'm working on a fix now. I've uploaded a new firmware. Should fix this. http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/ |
|
|
|
|
Yes there's a small regression in the auto code, I'm working on it now.
|
|
|
|
First problem found in --avalon-freq <arg> Set frequency range for avalon-auto, single value or range
with range set from 330-360 this is not working and miner has been sat on 330 for over an hour not increasing on decreasing in speed yet on previous version was working?
There's a regression where auto doesn't go quite as fast as it used to, I'm working on a fix now. |
|
|
|
Hi,
I'm having this message continually since I upgraded to 3.3.3
[2013-08-12 23:49:01] Rejected 9f13b83d Diff 1/1 AMU 3 pool 0 (Extranonce2_size violated)
will roll back to 3.2 to see if it fix the problem.
EDIT: The problem seems to only happen with bitminter. I have switch to slush pool and all is fine.
EDIT2: Yep. The incompatibility has been introduced by 3.3.3. I have come back to 3.3.2 and it started to work again.
Ah yes I see what's wrong there. I've committed a fix to git for this. |
|
|
|
|
They all use the icarus communication method, however cgminer automatically detects and lists them as AMU.
|
|
|
|
|
I believe this is why the abbreviation YMMV was invented, but we love you still.
|
|
|
|
I've uploaded new firmware 20130813 with the latest version of cgminer 3.3.3. http://ck.kolivas.org/apps/cgminer/avalon/20130813/This release contained a concerted effort to decrease CPU usage for stratum mining, and makes a massive difference when mining on p2pool. A reminder that my firmware does not contain code to detect batch3 devices so you'll have to manually enter the higher target and overheat temperatures into your configuration. |
|
|
|
Thanks for testing. Still got a little bit more to squeeze out of it but the cpu usage will always look a little higher due to the driver cpu usage all being attributed to cgminer now instead of hidden in the operating system (since there is no driver with direct usb).
I've completed the rework of the stratum work generation code which was where most of the high CPU usage on p2pool was, and uploaded new firmware with the newly released version 3.3.3 of cgminer: EDIT: Updated link, with slightly newer firmware: http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/ |
|
|
|
|
New release: Version 3.3.3 - 13th August 2013
This release was a concerted effort to decrease CPU usage for mining ASIC hardware on low power machines, especially when used with p2pool.
Human readable changelog:
- Avoid reproducing work as much as possible when generating work on stratum by storing a midstate of sorts on each stratum notification update.
- Cache some of the work to decrease work duplication on GBT.
- Fix a potential bug if a pool uses a nonce2 size bigger than 4 bytes.
- Fix a (very low) potential data corruption on work generation.
- Add more useful debugging for when low level crashes in semaphore and mutex operations occur.
- Fix the intensity vs --scrypt bug introduced in 3.3.2
Full changelog:
- Only perform the bin2hex on nonce2 data if it's required for stratum
submission, thereby removing the last conversion of that type from stratum work
generation.
- Create a work data template when receiving stratum notification, allowing a
simple memcpy of the merkle root avoiding more hex2bin conversions on each work
generation.
- Export the workpadding char in miner.h
- Avoid a potential overflow should a pool specify a large nonce2 length with
stratum.
- Avoid one more hex2bin in gen stratum work.
- Rename work gbt_coinbase to coinbase to be in line with pool variable name.
- Perform merkle bin hex2bin on stratum notify to avoid doing it on each work
generation.
- Reuse just the one pool coinbase variable in stratum, avoiding more string
functions and storage in gen_stratum_work on each work generation.
- Rename pool gbt_coinbase variable to coinbase to combine it with the stratum
coinbase data.
- Use a nonce2 offset variable for both gbt and stratum to consolidate
requirements on work generation.
- Merge pull request #474 from kanoi/master
- util.c update quit call for new functions
- use correct define for OSX in util.c
- miner.h inline semaphores increase information on failure
- util.c expand quit to show file/func/line
- Merge remote-tracking branch 'conman/master'
- Cache as much of the gbt coinbase as possible to avoid doing unnecessary
hex2bin conversion on every work generation with gbt.
- We should be using a cg_wlock initially in generating stratum and gbt work
before downgrading the lock.
- Add the ability to downgrade a write variant of the cglocks.
- Fix --scrypt being required before scrypt intensities on command line or not
working at all via config files.
- Cache the hex2bin of pool nonce1 in stratum, avoiding hex2bin on each work
generation.
- Cache the binary generation of coinbase1 and 2 on stratum, avoiding a hex2bin
of coinbase1 and 2 on each work generation.
- cgsem - increase information on failure
|
|
|
|
Kano and ckolivas, Did you guys know that there is a WinXP only version of Zadig? I setup my XP Pro laptop to be backup to my Win7 mining rig and found that the Zadig in your download directory is incompatible with WinXP and it doesn't do a check to tell you that. So I found the XP only version and that got me off the races with my backup PC. I'm wondering if that is part of the trouble some Windoze users are having with the Zadig utility? The XP Only version can be had from this link http://sourceforge.net/projects/libwdi/files/zadig/zadig_xp_v2.0.1.160.7z/downloadThanks, Sam Yes I'm aware of it, and I do understand why people stick with XP, but in all honesty I'm still surprised that no one would run a 12 year old PC but they're using a 12 year old unsupported by MS operating system. As I said, I do understand the whole if-it-ain't-broke concept, but it still surprises me... |
|
|
|
It seemed like an odd change to me, so I just assumed it was taking the wrong value from somewhere. Thanks for pointing it out.
You are not alone with that. I can't really see the point of changing that but it's cons decision. I'm the opposite. I don't quite see any point whatsoever in showing absolute share count at all any more. The pools report your share count the same relative way. It's just a legacy from when there was only diff1 mining. I'm trying hard to move away from confusing information on the main screen (you can always get whatever information you want from the API). |
|
|
|
|
Show Posts
