-ck (OP)
Legendary
Offline
Activity: 4200
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 02:52:00 AM |
|
New version - 2.4.4, 1st July 2012
I plugged my main PC's hard drive into an external USB reader to allow me to build this on my laptop since I really wanted this release out.
Human readable changelog: Massive overhaul of the nrolltime mechanism now should cause a huge rise in efficiency on pools that support it. This allows much lower getwork bandwidth for much higher hashrates. Support for the expire= feature. This works in concert with nrolltime when pools support it to allow more local generation of work. Support for the x-mining-hashrate feature. I'm sure some pool somewhere cares about this, even though I'm not convinced, but it was trivial to add. Better damping of GPU temperature changes should cause much less overshoot when temps rise or fall outside the optimal range in autofan mode. Reinstated the application restart should adl fail - disabling this did not fix the crashes for those who had cgminer crash after 1 week of uptime in windows fail land when their ATI driver would fail, and disabled the advantage of it fixing the problem for those who simply lost their fanspeed. API groups features - this is squarely aimed at grouping privileges for remote access for services like P4man's hopping puppetmaster service. Support for unlimited devices Support for unlimited pools Massive fix for the "dynamic" feature for GPUs. Somehow in the many device abstractions it had gotten broken and wasn't really doing what it was intended. It should be much more dynamic now. FPGA fixes. Fixes for builds on other platforms. Lots of other things under the hood.
Full changelog - Fix builds on non gnu platforms. - api.c ensure old mode is always available when not using --api-groups + quit() on param errors - Implement rudimentary X-Mining-Hashrate support. - Detect large swings in temperature when below the target temperature range and change fan by amounts dependant on the value of tdiff. - Adjust the fanspeed by the magnitude of the temperature difference when in the optimal range. - Revert "Restarting cgminer from within after ADL has been corrupted only leads to a crash. Display a warning only and disable fanspeed monitoring." - api.c fix json already closed - implement and document API option --api-groups - Put upper bounds to under 2 hours that work can be rolled into the future for bitcoind will deem it invalid beyond that. - define API option --api-groups - api.c allow unwell devices to be enabled so they can be cured - miner.php - fix/enable autorefresh for custom pages - miner.php allow custom summary pages - new 'Mobile' summary - Work around pools that advertise very low expire= time inappropriately as this leads to many false positives for stale shares detected. - Only show ztex board count if any exist. - There is no need for work to be a union in struct workio_cmd - fpgautils.c include a debug message for all unknown open errors - Don't keep rolling work right up to the expire= cut off. Use 2/3 of the time between the scantime and the expiry as cutoff for reusing work. - Log a specific error when serial opens fail due to lack of user permissions - Increase GPU timing resolution to microsecond and add sanity check to ensure times are positive. - Opencl code may start executing before the clfinish order is given to it so get the start timing used for dynamic intensity from before the kernel is queued. - fpgautils.c - set BAUD rate according to termio spec - fpgautils.c - linux ordering back to the correct way - miner.php remove unneeded '.'s - miner.php add auto refresh options - miner.php add 'restart' next to 'quit' - miner.php make fontname/size configurable with myminer.php - Make the pools array a dynamically allocated array to allow unlimited pools to be added. - Make the devices array a dynamically allocated array of pointers to allow unlimited devices. - Dynamic intensity for GPUs should be calculated on a per device basis. Clean up the code to only calculate it if required as well. - Use a queueing bool set under control_lock to prevent multiple calls to queue_request racing. - Use the work clone flag to determine if we should subtract it from the total queued variable and provide a subtract queued function to prevent looping over locked code. - Don't decrement staged extras count from longpoll work. - Count longpoll's contribution to the queue. - Increase queued count before pushing message. - Test we have enough work queued for pools with and without rolltime capability. - As work is sorted by age, we can discard the oldest work at regular intervals to keep only 1 of the newest work items per mining thread. - Roll work again after duplicating it to prevent duplicates on return to the clone function. - Abstract out work cloning and clone $mining_threads copies whenever a rollable work item is found and return a clone instead. - api.c display Pool Av in json - Take into account average getwork delay as a marker of pool communications when considering work stale. - Work out a rolling average getwork delay stored in pool_stats. - Getwork delay in stats should include retries for each getwork call. - Walk through the thread list instead of searching for them when disabling threads for dynamic mode. - Extend nrolltime to support the expiry= parameter. Do this by turning the rolltime bool into an integer set to the expiry time. If the pool supports rolltime but not expiry= then set the expiry time to the standard scantime. - When disabling fanspeed monitoring on adl failure, remove any twin GPU association. This could have been leading to hangs on machines with dual GPU cards when ADL failed. - modminer: Don't delay 2nd+ FPGAs during work restart - Disable OpenCL code when not available. - Fix openwrt crashing on regeneratehash() by making check_solve a noop. - FPGA - allow device detect override without an open failure - Fix sign warning.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 04:56:34 AM |
|
... and anyone looking for an Xubuntu 11.04 compile of 2.4.4 -> cgminer-2.4.4a at the top of https://github.com/kanoi/cgminer/downloads(I'm running this executable at the moment on both my rigs)
|
|
|
|
crazyates
Legendary
Offline
Activity: 952
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 05:03:33 AM |
|
I clearly have trust issues with anything luke-jr says ... maybe others do too? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) You should work on those issues. Would be more productive than posting lies on the forum. The problem with that statement is: Prove anywhere one lie you say I have said ... anywhere ... I'm sorry, but Kano > luke-jr, time and time again...
|
|
|
|
Krak
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 05:04:42 AM |
|
Getting this with 2.4.4. GPU 0: 290.3 / 289.7 Mh/s | A:74 R:0 HW:0 U:3.65/m I:4 73.0 C F: 74% (3049 RPM) E: 960 MHz M: 860 Mhz V: 1.175V A: 98% P: 0% Last initialised: [2012-07-01 00:41:44] Intensity: Dynamic (only one thread in use) Thread 0: 146.9 Mh/s Enabled ALIVE Thread 1: 146.1 Mh/s Enabled ALIVE
It says there's only 1 thread in use, but it shows both threads as being active. Is that right? Performance seems much better at least; ~20 MH/s better than 2.4.3.
|
BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4200
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 05:08:15 AM |
|
Getting this with 2.4.4. GPU 0: 290.3 / 289.7 Mh/s | A:74 R:0 HW:0 U:3.65/m I:4 73.0 C F: 74% (3049 RPM) E: 960 MHz M: 860 Mhz V: 1.175V A: 98% P: 0% Last initialised: [2012-07-01 00:41:44] Intensity: Dynamic (only one thread in use) Thread 0: 146.9 Mh/s Enabled ALIVE Thread 1: 146.1 Mh/s Enabled ALIVE
It says there's only 1 thread in use, but it shows both threads as being active. Is that right? Performance seems much better at least; ~20 MH/s better than 2.4.3. Odd, disables here: Intensity: Dynamic (only one thread in use) Thread 0: 190.1 Mh/s Enabled ALIVE Thread 1: 0.0 Mh/s Enabled ALIVE paused Performance should be pretty much dependent on intensity so it will be very different to before since it appears you're going up to intensity 4 where previously it would have been stuck at 0 +/- 1.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
Krak
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 05:11:40 AM |
|
Performance should be pretty much dependent on intensity so it will be very different to before since it appears you're going up to intensity 4 where previously it would have been stuck at 0 +/- 1.
I'm getting anywhere from 2 to 6 now. Before, it basically topped out at 4.
|
BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
|
|
|
wildemagic
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 05:57:56 AM |
|
So systems without opencl.dll and sdk dont need to specifically recompile for this version?
Kind regards
|
.,-._|\ Offgrid 1.7kW Solar and 3G wireless internet powering my mining rig. / .Oz. \ \_,--.x/ [219.5btc of successful trades total] with : rastapool, miernik, flatronw & OneFixt o
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4200
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 06:00:08 AM |
|
So systems without opencl.dll and sdk dont need to specifically recompile for this version?
Kind regards
If you use my precompiled binary you need opencl.dll. If you build it yourself it will require whatever you build it for.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
TheHarbinger
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 378
Merit: 250
Why is it so damn hot in here?
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 06:24:03 AM |
|
May want to take a look at the windows binary. Getting 1.5Mh/s on my 5870s with the new 2.4.4. ![Undecided](https://bitcointalk.org/Smileys/default/undecided.gif)
|
12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 08:38:20 AM |
|
... His excuse for this was: June-1 GMT+10 log discussion: [Private log reposted without permission removed]
Still no sign of that 'private' code he wrote more than a month ago ... So everyone using BFL on a pool that doesn't pay stale shares is getting 5x the number of stale shares with the current code than they should (and also of course luke-jr isn't getting this 5x) ...
So WHO THE FUCK is editing my posts here where I posted IRC discussion from the PUBLIC IRC CHANNEL #cgminer on FreeNet? You better have a good reason for it.
|
|
|
|
DiabloD3
Legendary
Offline
Activity: 1162
Merit: 1000
DiabloMiner author
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 11:11:41 AM |
|
... His excuse for this was: June-1 GMT+10 log discussion: [Private log reposted without permission removed]
Still no sign of that 'private' code he wrote more than a month ago ... So everyone using BFL on a pool that doesn't pay stale shares is getting 5x the number of stale shares with the current code than they should (and also of course luke-jr isn't getting this 5x) ...
So WHO THE FUCK is editing my posts here where I posted IRC discussion from the PUBLIC IRC CHANNEL #cgminer on FreeNet? You better have a good reason for it. luke-jr flagged your posts saying they were "illegal log posting", but I ignored his mod request. One of the other mods must have done it.
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4200
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 11:42:51 AM |
|
May want to take a look at the windows binary. Getting 1.5Mh/s on my 5870s with the new 2.4.4. ![Undecided](https://bitcointalk.org/Smileys/default/undecided.gif) Others are using this binary without any problems and I can't think of anything that would do this. I suggest you delete any .bin files you have and start again, or just extract it fresh and start again, doing the windows three finger salute (reboot) first.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4200
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 11:43:45 AM |
|
... His excuse for this was: June-1 GMT+10 log discussion: [Private log reposted without permission removed]
Still no sign of that 'private' code he wrote more than a month ago ... So everyone using BFL on a pool that doesn't pay stale shares is getting 5x the number of stale shares with the current code than they should (and also of course luke-jr isn't getting this 5x) ...
So WHO THE FUCK is editing my posts here where I posted IRC discussion from the PUBLIC IRC CHANNEL #cgminer on FreeNet? You better have a good reason for it. There's certainly nothing private about the #cgminer logs as far as I'm concerned, otherwise it wouldn't be an open public channel.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
tnkflx
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 01:19:11 PM |
|
May want to take a look at the windows binary. Getting 1.5Mh/s on my 5870s with the new 2.4.4. ![Undecided](https://bitcointalk.org/Smileys/default/undecided.gif) I'm not seeing this on a quad 6990 on Windows.
|
| Operating electrum.be & us.electrum.be |
|
|
|
John (John K.)
Global Troll-buster and
Legendary
Offline
Activity: 1288
Merit: 1227
Away on an extended break
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 01:34:27 PM |
|
May want to take a look at the windows binary. Getting 1.5Mh/s on my 5870s with the new 2.4.4. ![Undecided](https://bitcointalk.org/Smileys/default/undecided.gif) All of my 58xx series is working perfectly. In fact, I got a marginal increase of 1~Mh/s
|
|
|
|
Diapolo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 01:37:07 PM |
|
Great work Con, keep it up ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) . I always enjoy reading the changelog to see what progress you've made with that release. A question, is there a way to achieve the following: - set a fixed (low) fan speed, which is taken as upper limit - set an engine range, which is taken into account, while maintaining the maximum fan speed and temperature - set a maximum temperature and when this is reached the engine clock is lowered until we are in a safe sector I tried width "--gpu-fan 30 --gpu-engine 600-1100 --temp-overheat 75" and "--gpu-fan 30 --auto-gpu --temp-overheat 75", but that does not seem to do the job. The first one stays at 30% fan, 1100 MHz and does nothing, when reaching 75 °C. The secon one stays at 30% fan, 925 MHz and does nothing, when reaching 75°C. Dia
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4200
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 01:43:13 PM |
|
Great work Con, keep it up ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) . I always enjoy reading the changelog to see what progress you've made with that release. A question, is there a way to achieve the following: - set a fixed (low) fan speed, which is taken as upper limit - set an engine range, which is taken into account, while maintaining the maximum fan speed and temperature - set a maximum temperature and when this is reached the engine clock is lowered until we are in a safe sector I tried width "--gpu-fan 30 --gpu-engine 600-1100 --temp-overheat 75" and "--gpu-fan 30 --auto-gpu --temp-overheat 75", but that does not seem to do the job. The first one stays at 30% fan, 1100 MHz and does nothing, when reaching 75 °C. The secon one stays at 30% fan, 925 MHz and does nothing, when reaching 75°C. Dia Thanks ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) You need to differentiate target temp from overheat from cutoff temps. cgminer has a graded response depending on which of the 3 it is reaching, and you have to remember there is the hysteresis (3 default). So if you use the first of your numbers, and get rid of the overheat value, but enable autogpu, then it will start throttling the engine speed when it gets to about 78 degrees. ie you probably want: --gpu-fan 30 --gpu-engine 600-1100 --auto-gpu and that will keep the fan at static 30%, start the engine at 1100 and then if the temperature gets to 78 will start decreasing the engine speed. If 78 is too high, you can set the --temp-target to something besides 75.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
tnkflx
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 02:08:07 PM |
|
Con, will you be writing BFL support via their remote solution?
|
| Operating electrum.be & us.electrum.be |
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4200
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 02:26:01 PM |
|
Con, will you be writing BFL support via their remote solution?
I haven't decided yet because this is not a sign of BFL supporting the community, the developer or the clients. Of course taking a stand when BFL are guaranteed of sales monopoly and cornering the market will just make me look like I'm taking a stance when no one gives a shit, but then, I'm not sure what I get out of doing the hard work for them.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
TheHarbinger
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 378
Merit: 250
Why is it so damn hot in here?
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2012, 02:43:38 PM |
|
May want to take a look at the windows binary. Getting 1.5Mh/s on my 5870s with the new 2.4.4. ![Undecided](https://bitcointalk.org/Smileys/default/undecided.gif) Others are using this binary without any problems and I can't think of anything that would do this. I suggest you delete any .bin files you have and start again, or just extract it fresh and start again, doing the windows three finger salute (reboot) first. Okay, it was late when I posted this, so I didn't mess with it last night, just shut it down and went back to 2.4.3. Now it's a new day and I tried it again. I noticed something immediately this morning, the intensity was set to "-10". It will switch to any static (-10 through 14) intensity if I enter it with the GPU settings, or in the .conf file, but as soon as it is set back to dynamic (d) it pegs right back to -10 and stays there. Have tried; New clean copy, no .bin, no .conf New copy with old .bin, old .conf And all the variations of old and new Running a Win7 x64 w/ 2.5 SDK and Cat 12.6 So, ckolivas, tell me what I can do to help you figure this out.
|
12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
|
|
|
|