It already tries to restart the cards itself without any options unless you specify --no-restart, but it only does so if it knows it's safe. It almost certainly has tried and failed and you're just lucky that restarting cgminer fixes it. I suggest clocking less or cooling better if you're routinely killing the driver like that.
Is there a way to make it keep trying to restart the dead card every X seconds? It does so every minute already. If however the restart thread is killed by the driver destroying it, it does not try to restart it any further because that is usually when it will crash the entire of cgminer instead, so the safer option is to at least let any remaining devices keep mining. Most cards, when they go DEAD, usually cgminer will keep mining on the rest of the devices, but you have to actually reboot to get the dead one back. |
|
|
|
I have a question related to the --gpu-map option. I'm using RDP to connect and manage my Windows 7 PC remotely. [2012-07-05 08:00:24] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2012-07-05 08:00:24] Platform 0 devices: 2
[2012-07-05 08:00:24] 0 Tahiti
[2012-07-05 08:00:24] 1 BeaverCreek
[2012-07-05 08:00:25] ADL found less devices than opencl!
CL found 2 devices, so presumably adl is only finding one. Many remote access software thingamajigs only work with the first device. Dunno about losedows... but it's the equivalent of not doing EXPORT DISPLAY on linux. |
|
|
|
I'm getting a "DEAD" signal after a few hours of mining on a card that works just fine if I close and re-open CGminer. I had the same issue with GUIminer where a simple stop/start (button in the program) would get the card going again, so the restart can be automated.
Kinda new to CGminer, so I'm guessing it's something with the code I fiddled with:
Is there a line I'm missing to restart dead cards?
It already tries to restart the cards itself without any options unless you specify --no-restart, but it only does so if it knows it's safe. It almost certainly has tried and failed and you're just lucky that restarting cgminer fixes it. I suggest clocking less or cooling better if you're routinely killing the driver like that. |
|
|
|
Stable here too on 4 x icarus with 2.4.4.
Still cant decide between 2.4.4 and 2.4.3.
Any advantages between the two versions? anything changed for icarus?
I use a proxy pool so I cant really tell if stales are better or worse since the pool swings between high rejects and low depending on where the hashes are going.
kind regards
Apart from broken dynamic intensity, 2.4.4 should be better across the board. |
|
|
|
Darn. Guess I broke instead of fixed dynamic. I'll have to investigate again soon...
I've committed a change to the git tree which should fix it. Can anyone who has the problem and builds from git confirm please? Negative, not fixed. Fresh pull from git and built on a Win7 x64 system. Same behavior.Edit: Did a new pull and tried it again. This time it works, I must have borked something up the first time. Going to let it run a bit and see how it does. Edit #2: Has been running now for 3 hours. Seems to be stable. Will update again in the morning (12 hours). But so far it looks like a good candidate for a binary. Great, thanks a lot! |
|
|
|
Darn. Guess I broke instead of fixed dynamic. I'll have to investigate again soon...
I've committed a change to the git tree which should fix it. Can anyone who has the problem and builds from git confirm please? |
|
|
|
Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks! ./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer) Wrong version of ubuntu. |
|
|
|
|
Luke just go away already. I already told you I'm outta here, so dunno why you're still whining.
|
|
|
|
|
Just go away already. I already told you I'm outta here. Take all the bfl stuff, I'm retiring.
|
|
|
|
|
I finally got sick of the poor BFL performance argument and bickering between luke and kano so I wrote my own solution generically even though I have no hardware of my own. It's now in the git master tree and Kano has tested it.
|
|
|
|
I got sick of hearing about this issue, so I coded up a generic solution for the problem myself, even though I have no singles of my own.
How do you put up with their constant bickering? lol By ignoring them. I finally offered code to fix some BFL hardware and luke rejected it lol. I guess he was afraid BFL might realise they're betting on the wrong horse by supporting him instead of me. Whatever, I'm outta here, this is like a primary school playground and I'm no longer interested. |
|
|
|
|
I got sick of hearing about this issue, so I coded up a generic solution for the problem myself, even though I have no singles of my own.
|
|
|
|
|
Darn. Guess I broke instead of fixed dynamic. I'll have to investigate again soon...
|
|
|
|
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. |
|
|
|
Great work Con, keep it up  . 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 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. |
|
|
|
...
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. |
|
|
|
May want to take a look at the windows binary. Getting 1.5Mh/s on my 5870s with the new 2.4.4.  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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
In the meantime you can upgrade to cgminer 2.4.4 which I just released which should support massive hashrates anyway with a dramatic rise in efficiency. The faster the device, the higher the efficiency.
|
|
|
|
|
Show Posts
