-ck (OP)
Legendary
Offline
Activity: 4256
Merit: 1645
Ruu \o/
|
|
July 03, 2012, 01:41:19 AM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
GernMiester
|
|
July 03, 2012, 01:42:06 AM |
|
Stable here with BFL's and 3 GPU's. Seesm to get a few more Mh/s but the fans dont seems to slow back down as fast as they used to. I think the update makes it adjust fan speeds much slower than previous versions.
|
|
|
|
TheHarbinger
Sr. Member
Offline
Activity: 378
Merit: 250
Why is it so damn hot in here?
|
|
July 03, 2012, 02:34:23 PM |
|
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. Edit #3: Coming up on 20 hours of running stable. I would say go ahead and pack it CKolivas. Only thing you might want to look at is I'm showing about 400% efficiency and a reject rate of 0.007%, so clearly something is wrong.
|
12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
|
|
|
|
punin
|
|
July 03, 2012, 07:48:09 PM Last edit: July 03, 2012, 09:52:52 PM by punin |
|
I've had strange issues with a cluster of 18 ztex boards connected through 2 separate powered hubs run by cgminer 2.4.2 and 2.4.4 on a Raspberry Pi. 1 random board dies (and gets a LED on). After 10 minutes cgminer pronounced it dead. I must stress that there's seems to be no logic in what board fails. It's completely erratic (4 different boards now after each restart of cgminer). Any clues? EDIT: And now segfault: [2012-07-03 22:18:27] ZTEX 04A32Exxxx-1: Failed readHashData with err -1 [2012-07-03 22:18:27] ZTEX 04A32Exxxx-1: Failed to read hash data with err -1, retrying [2012-07-03 22:18:27] ZTEX 04A32Exxxx-1: Failed readHashData with err -4 [2012-07-03 22:18:27] ZTEX 04A32Exxxx-1: Disabling! [2012-07-03 22:18:27] ZTEX 04A32Exxxx-1: Failed to read hash data with err -4, giving upSegmentation fault
EDIT: removed 1 board, restarted. 1 random dead again.
|
|
|
|
kentrolla
|
|
July 04, 2012, 01:11:26 AM |
|
pack dat shi up
|
█████████████████████████ ████████▀▀████▀▀█▀▀██████ █████▀████▄▄▄▄██████▀████ ███▀███▄████████▄████▀███ ██▀███████████████████▀██ █████████████████████████ █████████████████████████ █████████████████████████ ██▄███████████████▀▀▄▄███ ███▄███▀████████▀███▄████ █████▄████▀▀▀▀████▄██████ ████████▄▄████▄▄█████████ █████████████████████████ | BitList | | █▀▀▀▀ █ █ █ █ █ █ █ █ █ █ █ █▄▄▄▄ | ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ . REAL-TIME DATA TRACKING CURATED BY THE COMMUNITY . ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ | ▀▀▀▀█ █ █ █ █ █ █ █ █ █ █ █ ▄▄▄▄█ | | List #kycfree Websites |
|
|
|
Fuzzy
|
|
July 05, 2012, 01:50:04 AM |
|
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: { "pools" : [ <snip> ],
"intensity" : "9,9,9,9", "temp-cutoff" : "95,95,95,95",
"expiry" : "120", "gpu-threads" : "2", "log" : "5", "queue" : "1", "retry-pause" : "5", "scan-time" : "60", "temp-hysteresis" : "3",
"kernel-path" : "/usr/local/bin" }
Is there a line I'm missing to restart dead cards?
|
|
|
|
Diapolo
|
|
July 05, 2012, 06:11:11 AM |
|
I have a question related to the --gpu-map option. I'm using RDP to connect and manage my Windows 7 PC remotely. When I want to start mining, CGMINER tells me ADL and OpenCL devices do not match (which is no problem, when I sit in front of the PC and use it locally). This is my cgminer.exe -n output: [2012-07-05 08:00:24] CL Platform 0 vendor: Advanced Micro Devices, Inc. [2012-07-05 08:00:24] CL Platform 0 name: AMD Accelerated Parallel Processing [2012-07-05 08:00:24] CL Platform 0 version: OpenCL 1.2 AMD-APP (938.1) [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:24] Failed to ADL_Adapter_ID_Get. Error -5 [2012-07-05 08:00:24] Failed to ADL_Adapter_ID_Get. Error -5 [2012-07-05 08:00:24] Failed to ADL_Adapter_ID_Get. Error -5 [2012-07-05 08:00:24] Failed to ADL_Adapter_ID_Get. Error -5 [2012-07-05 08:00:24] Failed to ADL_Adapter_ID_Get. Error -5 [2012-07-05 08:00:24] Failed to ADL_Adapter_ID_Get. Error -5 [2012-07-05 08:00:25] Failed to ADL_Adapter_ID_Get. Error -5 [2012-07-05 08:00:25] ADL found less devices than opencl! [2012-07-05 08:00:25] There is possibly more than one display attached to a GPU [2012-07-05 08:00:25] Use the gpu map feature to reliably map OpenCL to ADL [2012-07-05 08:00:25] WARNING: Number of OpenCL and ADL devices did not match! [2012-07-05 08:00:25] Hardware monitoring may NOT match up with devices! [2012-07-05 08:00:25] 2 GPU devices max detected But now I'm unsure about how to map, as the listed devices 0 Tahiti and 1 BeaverCreek are correct (perhaps I should take a look at the output, when locally working on the machine though). Thanks, Dia
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4256
Merit: 1645
Ruu \o/
|
|
July 05, 2012, 06:41:54 AM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4256
Merit: 1645
Ruu \o/
|
|
July 05, 2012, 06:54:02 AM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
Fuzzy
|
|
July 05, 2012, 07:02:35 AM |
|
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?
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4256
Merit: 1645
Ruu \o/
|
|
July 05, 2012, 07:07:14 AM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
|
July 05, 2012, 07:31:41 PM |
|
I'm playing with p2pool again. I have 3 miners pointing to a local pool. Two are cgminer 2.4.4, one is phoenix 2.0.0. I get this in the p2pool log every so often for cgminers, not sure about the phoenix miner:
2012-07-05 15:28:18.808000 > Worker q6600 @ 127.0.0.1 submitted share more than once!
p2pool, cgminer, or something else causing this?
M
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
rav3n_pl
Legendary
Offline
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
|
July 05, 2012, 07:38:10 PM |
|
I'm playing with p2pool again. I have 3 miners pointing to a local pool. Two are cgminer 2.4.4, one is phoenix 2.0.0. I get this in the p2pool log every so often for cgminers, not sure about the phoenix miner:
2012-07-05 15:28:18.808000 > Worker q6600 @ 127.0.0.1 submitted share more than once!
p2pool, cgminer, or something else causing this?
M
Try use different login names for each worker. Looks like different workers find exact same share and send it to p2pool, but it seems very unlikely near to impossible.
|
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
|
July 05, 2012, 08:14:48 PM |
|
I'm playing with p2pool again. I have 3 miners pointing to a local pool. Two are cgminer 2.4.4, one is phoenix 2.0.0. I get this in the p2pool log every so often for cgminers, not sure about the phoenix miner:
2012-07-05 15:28:18.808000 > Worker q6600 @ 127.0.0.1 submitted share more than once!
p2pool, cgminer, or something else causing this?
M
Try use different login names for each worker. Looks like different workers find exact same share and send it to p2pool, but it seems very unlikely near to impossible. Each worker has it's own name. miner1, miner2, q6600. M
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
rav3n_pl
Legendary
Offline
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
|
July 05, 2012, 08:26:58 PM |
|
elif header_hash in received_header_hashes: print >>sys.stderr, 'Worker %s @ %s submitted share more than once!' % (request.getUser(), request.getClientIP())
This message is shown, when miner send exact same share that is already in share chain. What p2pool version? It is very odd....
|
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
|
July 05, 2012, 08:33:03 PM Last edit: July 05, 2012, 08:54:38 PM by mdude77 |
|
elif header_hash in received_header_hashes: print >>sys.stderr, 'Worker %s @ %s submitted share more than once!' % (request.getUser(), request.getClientIP())
This message is shown, when miner send exact same share that is already in share chain. What p2pool version? It is very odd.... I confirmed, I'm getting it from all 3 miners, two are cgminer. So I'm not sure this is a cgminer issue. And I see it fairly regularly, enough that I can just watch the p2pool interface scroll by and they jump out at me. My biggest miner sometimes has it 2x in a row. I'm on p2pool 3.1, the latest as far as I can tell. Windows version. Should I cross post in the p2pool forum?EDIT: posted into p2pool forum. M
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
Beaflag VonRathburg
|
|
July 05, 2012, 09:07:19 PM |
|
Is there a known issue trying to run 5 or more BFL singles under windows in either 2.4.1 or 2.4.2? 2.3.6 seems to be able to handle 5 singles fine. But every time I try to run all five under a single instance with 2.4.1 or 2.4.2, I get a crash in libpdcurses.dll.
Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x4fcad128 Faulting module name: libpdcurses.dll, version: 0.0.0.0, time stamp: 0x4f460f95 Exception code: 0xc0000005 Fault offset: 0x000012fe Faulting process id: 0xb24 Faulting application start time: 0x01cd419e02e067d8 Faulting application path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\cgminer.exe Faulting module path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\libpdcurses.dll
I think I saw a thread elsewhere here that said if you increase the size of the command window in windows, it might solve this problem. Yes, increasing the size of the command window (before starting cgminer) has helped people with similar symptoms. (EDIT: I've seen you already got it working.) To set a larger size as a default, hit start->run and type in cmd.exe<enter>; then click the black system icon in the top left corner of the command window that pops up. Choose 'properties'. The important thing here is the 'Layout' tab. Specifically Window Height. Set the Window height to 40 or 50. You can change the font as well to make it fit your monitor better. Click ok. You may then exit the command window. Any command window you open after this will come up with its new size. There is a difference in how different versions of cgminer behave with Singles. 2.3.6 worked perfectly for me with up to 15 Singles. I since moved to 2.4.1 (and now 2.4.2) and have found that, using the same command line and command window layout size, 15 Singles crashes it. 2.4.1 are happy with 10 Singles, but not 15. 2.3.6 works fine with 15. I don't know what broke between cgminer 2.3.6 and 2.4.1. It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad). Win 7 x64 9x BFL Singles 10 Port powered USB hub Issue: Neither 2.4.4 nor 2.3.6 will start more than 6 BFL singles Troubleshooting: - Multiple restarts usually resulting in BFL singles receiving different COM numbers than previous reboot - Powering and unpowering USB hub - Plugging USB hub into multiple USB 2 ports will cause zero BFL singles to start in cgminer - Plugging into USB 3 port will allow 6 BFL singles to start in cgminer, but I receive a, "This device can perfom faster when plugged into a USB 2.0 port," message - Plugging the 3 BFL singles that where not starting in cgminer into another computer directly to the front USB ports. None would start resulting in same COM errors (2.4.3) At this point I'm trying to figure out if the USB hub, cables from hub --> singles, cgminer, or the singles themselves are the point of error. All singles light up and the fans spin. Any help would be greatly appreciated.
|
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
|
July 05, 2012, 09:09:00 PM |
|
Is there a known issue trying to run 5 or more BFL singles under windows in either 2.4.1 or 2.4.2? 2.3.6 seems to be able to handle 5 singles fine. But every time I try to run all five under a single instance with 2.4.1 or 2.4.2, I get a crash in libpdcurses.dll.
Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x4fcad128 Faulting module name: libpdcurses.dll, version: 0.0.0.0, time stamp: 0x4f460f95 Exception code: 0xc0000005 Fault offset: 0x000012fe Faulting process id: 0xb24 Faulting application start time: 0x01cd419e02e067d8 Faulting application path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\cgminer.exe Faulting module path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\libpdcurses.dll
I think I saw a thread elsewhere here that said if you increase the size of the command window in windows, it might solve this problem. Yes, increasing the size of the command window (before starting cgminer) has helped people with similar symptoms. (EDIT: I've seen you already got it working.) To set a larger size as a default, hit start->run and type in cmd.exe<enter>; then click the black system icon in the top left corner of the command window that pops up. Choose 'properties'. The important thing here is the 'Layout' tab. Specifically Window Height. Set the Window height to 40 or 50. You can change the font as well to make it fit your monitor better. Click ok. You may then exit the command window. Any command window you open after this will come up with its new size. There is a difference in how different versions of cgminer behave with Singles. 2.3.6 worked perfectly for me with up to 15 Singles. I since moved to 2.4.1 (and now 2.4.2) and have found that, using the same command line and command window layout size, 15 Singles crashes it. 2.4.1 are happy with 10 Singles, but not 15. 2.3.6 works fine with 15. I don't know what broke between cgminer 2.3.6 and 2.4.1. It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad). Win 7 x64 9x BFL Singles 10 Port powered USB hub Issue: Neither 2.4.4 nor 2.3.6 will start more than 6 BFL singles Troubleshooting: - Multiple restarts usually resulting in BFL singles receiving different COM numbers than previous reboot - Powering and unpowering USB hub - Plugging USB hub into multiple USB 2 ports will cause zero BFL singles to start in cgminer - Plugging into USB 3 port will allow 6 BFL singles to start in cgminer, but I receive a, "This device can perfom faster when plugged into a USB 2.0 port," message - Plugging the 3 BFL singles that where not starting in cgminer into another computer directly to the front USB ports. None would start resulting in same COM errors (2.4.3) At this point I'm trying to figure out if the USB hub, cables from hub --> singles, cgminer, or the singles themselves are the point of error. All singles light up and the fans spin. Any help would be greatly appreciated. I'm pretty sure I've seen this before. If you resize the window cgminer runs in, it might fix it. M
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
July 05, 2012, 09:45:02 PM |
|
... Win 7 x64 9x BFL Singles 10 Port powered USB hub
Issue: Neither 2.4.4 nor 2.3.6 will start more than 6 BFL singles ... At this point I'm trying to figure out if the USB hub, cables from hub --> singles, cgminer, or the singles themselves are the point of error. All singles light up and the fans spin. Any help would be greatly appreciated.
With 2.4.4 it detects 2 specific problems and displays a message: 1) Do not have user privileges required to open %s 2) %s is already in use by another process If you are not getting either of those messages, then running cgminer also with the -D option it will give you a message why it can't start some of your BFLs However, I guess the fix might be one of: 1) Try using "\\.\COMn" (not just "COMn") if you aren't already 2) use "bitforce:\\.\COMn" for all the devices (<- this is the most likely fix on Win 7 64bit)
|
|
|
|
|