I can confirm that the lastest version doesnt work in Windows 8
As soon as cmd windows open from batch file, it will be auto closed
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 460. (Read 5805537 times)
October 26, 2012, 07:15:31 PM
October 26, 2012, 05:24:18 PM
I've updated cgminer to 2.8.5 on all my 5 rigs (all with win7 x64 and 7950+7970 cards), with --fix-protocol key it seems to be the most stable version i've ever seen.
Without --fix-protocol cgminer sometimes stops if internet connection is broken.
Thanks. Can you at least describe what you mean by "stops"? It's really supposed to reconnect. Unfortunately windows sockets don't quite behave like real unix ones so once again I'm forever adding workarounds for windows. Without --fix-protocol cgminer sometimes stops if internet connection is broken.
October 26, 2012, 12:05:15 PM
Seeing a little improvement on my 3x Crossfile 6950 setup. Before when a card crashed windows crashed out cgminer. Now it just kills the one card, and the other 2 seem to keep mining.
October 26, 2012, 11:31:38 AM
I've updated cgminer to 2.8.5 on all my 5 rigs (all with win7 x64 and 7950+7970 cards), with --fix-protocol key it seems to be the most stable version i've ever seen.
Without --fix-protocol cgminer sometimes stops if internet connection is broken.
Without --fix-protocol cgminer sometimes stops if internet connection is broken.
October 26, 2012, 11:05:32 AM
report:
OS: win 7 x64 / 2 x HD7950OC , SDK 2.7 , cgminer 2.8.5
driver 12.09 and 12.10 a lot of reject and hardware errors ...
back to driver 12.08 more stable and profitable at the moment
Thanks for that. Typical of AMD to screw up something like 4 out of every 5 driver releases in one way or another. OS: win 7 x64 / 2 x HD7950OC , SDK 2.7 , cgminer 2.8.5
driver 12.09 and 12.10 a lot of reject and hardware errors ...
back to driver 12.08 more stable and profitable at the moment
October 25, 2012, 06:34:10 PM
report:
OS: win 7 x64 / 2 x HD7950OC , SDK 2.7 , cgminer 2.8.5
driver 12.09 and 12.10 a lot of reject and hardware errors ...
back to driver 12.08 more stable and profitable at the moment
OS: win 7 x64 / 2 x HD7950OC , SDK 2.7 , cgminer 2.8.5
driver 12.09 and 12.10 a lot of reject and hardware errors ...
back to driver 12.08 more stable and profitable at the moment
October 25, 2012, 05:20:06 PM
We can't hold on to shares forever, even with submit stale being the default.
I understand that, you 've made that point to plenty of people plenty of times. My concern was with the fact that the pool was marked as down while I received a longpoll. My question is this: "should the pool have been marked up when I received a longpoll from it?" Maybe the answer is no, in which case that share was destined to be discarded, but if the answer is yes, then I would think submission should have been attempted before it expired (or maybe it was, and that's why the pool wasn't marked as up?). October 25, 2012, 12:51:47 PM
We can't hold on to shares forever, even with submit stale being the default.
I understand that, you 've made that point to plenty of people plenty of times. My concern was with the fact that the pool was marked as down while I received a longpoll. My question is this: "should the pool have been marked up when I received a longpoll from it?" Maybe the answer is no, in which case that share was destined to be discarded, but if the answer is yes, then I would think submission should have been attempted before it expired (or maybe it was, and that's why the pool wasn't marked as up?). October 25, 2012, 09:02:14 AM
I rarely look at cgminer running, but last time I looked, I saw this:This was witnessed in 2.8.5; I actually saw it twice within 15 minutes (the second time there wasn't a share discarded in the few seconds after the longpoll). The pool isn't great on connectivity, so the communication failures don't surprise me, especially just before a longpoll, however, I am curious as to whether or not cgminer should have said "oh, communication is working now" when it got the longpoll instead of waiting a second or two to check/determine communication was restored. Obviously the share that was discarded would have been rejected anyway, I only ask because I wonder if there might be something missing/inefficient in the communication failure code.
We can't hold on to shares forever, even with submit stale being the default. Imagine a scenario where the pool keeps sending work but the server is borked in a way it won't accept work. Cgminer could get a backlog of work so large that it crashes due to running out of memory. So cgminer keeps trying to resubmit the shares only until it reaches the expired work criteria. However, if cgminer thinks it has found a block, it will hold onto it until it successfully submits it no matter how long it takes. Code:
[2012-10-24 12:04:00] Pool 0 communication failure, caching submissions
[2012-10-24 12:04:03] LONGPOLL from pool 0 detected new block
[2012-10-24 12:04:05] Share became stale while retrying submit, discarding
[2012-10-24 12:04:05] Pool 0 communication resumed, submitting work
Either way, a reliable pool is the most important variable here.
October 25, 2012, 08:58:41 AM
This night, crashed and ... cgminer restarted!!! (windows xp). fine.
Thanks! it works for me.
Thanks! it works for me.
Shame I didn't fix the actual crashes in the first place
Still, there is a workable solution till someone can debug windows
October 25, 2012, 08:55:41 AM
2.7.6 died as well.
*however*
it tell me the GPU was sick and was trying to restart. alas, it failed on restarting. 2.8.4 never told me that.
I'm assuming I have something else going wrong that's causing this. Not sure what yet.
M
Still, a hardware failure is a hardware failure. Time to reassess your clocks, cooling, power or whatever else.*however*
it tell me the GPU was sick and was trying to restart. alas, it failed on restarting. 2.8.4 never told me that.
I'm assuming I have something else going wrong that's causing this. Not sure what yet.
M
I know. I keep looking, haven't found anything yet. I tell you though, I'm not going to miss GPU mining.
M
It will get boring, troubleshooting is half the fun
October 25, 2012, 07:00:15 AM
2.7.6 died as well.
*however*
it tell me the GPU was sick and was trying to restart. alas, it failed on restarting. 2.8.4 never told me that.
I'm assuming I have something else going wrong that's causing this. Not sure what yet.
M
Still, a hardware failure is a hardware failure. Time to reassess your clocks, cooling, power or whatever else.*however*
it tell me the GPU was sick and was trying to restart. alas, it failed on restarting. 2.8.4 never told me that.
I'm assuming I have something else going wrong that's causing this. Not sure what yet.
M
I know. I keep looking, haven't found anything yet. I tell you though, I'm not going to miss GPU mining.
M
October 25, 2012, 06:11:36 AM
I rarely look at cgminer running, but last time I looked, I saw this:This was witnessed in 2.8.5; I actually saw it twice within 15 minutes (the second time there wasn't a share discarded in the few seconds after the longpoll). The pool isn't great on connectivity, so the communication failures don't surprise me, especially just before a longpoll, however, I am curious as to whether or not cgminer should have said "oh, communication is working now" when it got the longpoll instead of waiting a second or two to check/determine communication was restored. Obviously the share that was discarded would have been rejected anyway, I only ask because I wonder if there might be something missing/inefficient in the communication failure code.
Code:
[2012-10-24 12:04:00] Pool 0 communication failure, caching submissions
[2012-10-24 12:04:03] LONGPOLL from pool 0 detected new block
[2012-10-24 12:04:05] Share became stale while retrying submit, discarding
[2012-10-24 12:04:05] Pool 0 communication resumed, submitting work
October 25, 2012, 06:09:06 AM
This night, crashed and ... cgminer restarted!!! (windows xp). fine.
Thanks! it works for me.
Thanks! it works for me.
October 25, 2012, 03:04:07 AM
Did you try Cgminer 2.8.5?
Also if the driver crashed, I doubt it is Cgminer's fault. Probably AMD's crappy drivers.
Also if the driver crashed, I doubt it is Cgminer's fault. Probably AMD's crappy drivers.
cgminer works the cards pretty hard. I don't recall having the problem until I upgraded to 2.8.4. I'll try 2.8.5 this weekend when I'm around to babysit it. I don't want it crashing again while I'm at my day job.
M
2.7.6 died as well.
*however*
it tell me the GPU was sick and was trying to restart. alas, it failed on restarting. 2.8.4 never told me that.
I'm assuming I have something else going wrong that's causing this. Not sure what yet.
M
October 24, 2012, 08:05:22 PM
Did you try Cgminer 2.8.5?
Also if the driver crashed, I doubt it is Cgminer's fault. Probably AMD's crappy drivers.
Also if the driver crashed, I doubt it is Cgminer's fault. Probably AMD's crappy drivers.
cgminer works the cards pretty hard. I don't recall having the problem until I upgraded to 2.8.4. I'll try 2.8.5 this weekend when I'm around to babysit it. I don't want it crashing again while I'm at my day job.
M
2.7.6 died as well.
*however*
it tell me the GPU was sick and was trying to restart. alas, it failed on restarting. 2.8.4 never told me that.
I'm assuming I have something else going wrong that's causing this. Not sure what yet.
M
October 24, 2012, 10:40:52 AM
Will give it a go on the RPi
Getting driver crashes using scrypt with 2.8.5. Catalyst 12.10 with the inbuild APP SDK, fresh install. Card is a Asus 7970 DCII at default clocks. Bitcoins mine without issue. During the scrypt mining, I am getting graphical corruption, smal blue squares near window borders fwiw.
October 23, 2012, 10:44:21 PM
Will give it a go on the RPi
October 23, 2012, 08:37:09 PM
cgminer paused again for me today. I didn't see it until 8 hours later.
that's the bad news.
the good news is I dug through the windows event log and found the video driver crashed right at the time it stopped. I assume cgminer caused the crash, but it didn't recover from it, and it didn't crash, so I can't put it in a loop.
for now I went back to 2.7.6 on that machine to see if it stays unpaused.
M
that's the bad news.
the good news is I dug through the windows event log and found the video driver crashed right at the time it stopped. I assume cgminer caused the crash, but it didn't recover from it, and it didn't crash, so I can't put it in a loop.
for now I went back to 2.7.6 on that machine to see if it stays unpaused.
M
Did you try Cgminer 2.8.5?
Also if the driver crashed, I doubt it is Cgminer's fault. Probably AMD's crappy drivers.
cgminer works the cards pretty hard. I don't recall having the problem until I upgraded to 2.8.4. I'll try 2.8.5 this weekend when I'm around to babysit it. I don't want it crashing again while I'm at my day job.
M
October 23, 2012, 08:14:33 PM
cgminer paused again for me today. I didn't see it until 8 hours later.
that's the bad news.
the good news is I dug through the windows event log and found the video driver crashed right at the time it stopped. I assume cgminer caused the crash, but it didn't recover from it, and it didn't crash, so I can't put it in a loop.
for now I went back to 2.7.6 on that machine to see if it stays unpaused.
M
that's the bad news.
the good news is I dug through the windows event log and found the video driver crashed right at the time it stopped. I assume cgminer caused the crash, but it didn't recover from it, and it didn't crash, so I can't put it in a loop.
for now I went back to 2.7.6 on that machine to see if it stays unpaused.
M
Did you try Cgminer 2.8.5?
Also if the driver crashed, I doubt it is Cgminer's fault. Probably AMD's crappy drivers.
Jump to: