Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 794. (Read 5806015 times)

legendary
Activity: 910
Merit: 1000
Quality Printing Services by Federal Reserve Bank
I found some hardware that I can reproduce the slowdown on and have found the offending change. It was actually unintentional. I've pushed the fix to git and it will be in the next version.

Thank you for the fix. I lost about 14% with the update to cgminer-1.5.7
Running  Gentoo Linux, vid card is 6950, x11-drivers/ati-drivers-11.6 and ati-stream-sdk-v2.3  

EDIT: cgminer-1.5.8 is about 3% slower
EDIT: cgminer-1.5.8 is back to normal 371Hhs
legendary
Activity: 1316
Merit: 1005
Multiple 69xx; Linux 2.6.38; Cat 11.6/SDK 2.4; cgminer 1.5.8 == fantastic.

I wasn't thrilled with Cat 11.7/8 processor usage and saw no discernible performance improvement with SDK 2.5 over 2.4. The 1.5.8 build maintains the same Mhash/s but utility is about 0.5% higher over several hours. No changes have been made to clock speeds or any other hardware settings since 1.5.3.
legendary
Activity: 1862
Merit: 1014
Reverse engineer from time to time
Partially because of my laziness, i will stay with what i've got for now. I.e 1.5.3
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Conman, can you tell me how to get pkg-config? I did the usual: mingw-get install pkg-config, but no dice.
See: http://www.mingw.org/wiki/FAQ
for: How do I get pkg-config installed?

It's still not easy to get it compiling under mingw32, but at least the dependencies are sorted out.
legendary
Activity: 1862
Merit: 1014
Reverse engineer from time to time
Conman, can you tell me how to get pkg-config? I did the usual: mingw-get install pkg-config, but no dice.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
1.5.8 keeps crashing on me at random times.. and then i cant restart it without a reboot.

If it requires a reboot, then that's NOT cgminer but the driver that's crashing. A few people have found their overclocks have had to be relaxed with the latest versions of phatk. Personally I fixed all my instability issues by tossing out the 11.8 and 11.7 drivers and going back to 11.6.
sr. member
Activity: 476
Merit: 250
moOo
1.5.8 keeps crashing on me at random times.. and then i cant restart it without a reboot.
sr. member
Activity: 467
Merit: 250
Pool switching should be fixed, performance should be better. GPU SICK/DEAD confusion should be fixed.

GPU SICK/DEAD is fixed - thank you for the quick response. Smiley
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Thanks for your work ckolivas, unfortunately the 6970s performance problem still exists. No change..

Whatever that is, it's something else... Whatever it is... seems to be related to your move to the new phatk kernel. My 6970s on the other hand, like it a lot. Something to do with you mixing cards perhaps? Really no idea offhand
full member
Activity: 174
Merit: 100
Thanks for your work ckolivas, unfortunately the 6970s performance problem still exists. No change..
full member
Activity: 154
Merit: 100
@ckolivas: Hi! Great work as usual. I just have a suggestion, maybe you can put the change log into the first page/first post since it's where each one of us turn into.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
So I worked on fixing bugs only in this quick release, especially with the performance regression in there. Interestingly, 6970s didn't mind at all having the 4K output buffers, but other cards did.

Version 1.5.8 (download links in first post):

- Minimise how much more work can be given in cpu mining threads each interval.
- Make the fail-pause progressively longer each time it fails until the network
recovers.
- Only display the lagging message if we've requested the work earlier.
- Clean up the pool switching to not be dependent on whether the work can roll
or not by setting a lagging flag and then the idle flag.
- Only use one thread to determine if a GPU is sick or well, and make sure to
reset the sick restart attempt time.
- The worksize was unintentionally changed back to 4k by mistake, this caused a
slowdown.

EXECUTIVE SUMMARY:
Pool switching should be fixed, performance should be better. GPU SICK/DEAD confusion should be fixed.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I found some hardware that I can reproduce the slowdown on and have found the offending change. It was actually unintentional. I've pushed the fix to git and it will be in the next version.
sr. member
Activity: 467
Merit: 250
anyway, I get the same speeds with both kernels in 1.5.6 - 143.5ish
and I get the same speeds with both kernels in 1.5.7 - 141
Is this built by yourself in linux, a binary in linux, built by yourself in windows, or a binary in windows? If it's the binary in windows, there were some slight differences in the compilation of it. That's the only thing I can think of that was different. The performance is usually only strongly linked to the kernel and not the code within cgminer which makes your results most unusual.

Linux, Fedora14, 686, grabbed from git. configured like:

Quote
CFLAGS="-O3 -Wall -msse3 -I./compat/jansson -I/usr/src/AMD-APP-SDK-v2.4-lnx32/include -g" LDFLAGS="-L/usr/src/AMD-APP-SDK-v2.4-lnx32/lib/x86/ -g"  ./configure

Make is completely clean.

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
anyway, I get the same speeds with both kernels in 1.5.6 - 143.5ish
and I get the same speeds with both kernels in 1.5.7 - 141
Is this built by yourself in linux, a binary in linux, built by yourself in windows, or a binary in windows? If it's the binary in windows, there were some slight differences in the compilation of it. That's the only thing I can think of that was different. The performance is usually only strongly linked to the kernel and not the code within cgminer which makes your results most unusual.
sr. member
Activity: 467
Merit: 250
Hmm. The threads are on the same GPU. There is indeed some confusion in the code it seems (i.e. a bug). I've only reproduced this once and a restart made it go away. I'll see if I can fix it next version.

Happening across multiple machines, from 2-4 GPU's per box -- happy to give you whatever debug/logs you wish/need, just let me know.

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Hmm. The threads are on the same GPU. There is indeed some confusion in the code it seems (i.e. a bug). I've only reproduced this once and a restart made it go away. I'll see if I can fix it next version.
sr. member
Activity: 467
Merit: 250
updated from 1.5.3 to 1.5.7 today... seeing an odd issue in the logs..it seems to be confusing thread 3 with thread 6..

Quote

[2011-08-22 14:49:01] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:03] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:03] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:04] Accepted 340e3713 GPU 1 thread 1 pool 0
[2011-08-22 14:49:05] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:05] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:07] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:07] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:09] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:09] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:10] Accepted e263f010 GPU 2 thread 8 pool 0
[2011-08-22 14:49:11] Accepted d33a1712 GPU 0 thread 3 pool 0
[2011-08-22 14:49:11] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:11] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:13] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:13] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:15] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:15] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:17] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:17] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:19] Accepted 3576d51b GPU 1 thread 7 pool 0
[2011-08-22 14:49:19] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:19] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:21] Accepted c8e87d27 GPU 2 thread 8 pool 0
[2011-08-22 14:49:21] Accepted 551c6327 GPU 0 thread 6 pool 0
[2011-08-22 14:49:21] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:21] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:23] Accepted 0c766d32 GPU 2 thread 5 pool 0
[2011-08-22 14:49:23] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:23] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:24] Accepted 9bc3ac3b GPU 1 thread 4 pool 0
[2011-08-22 14:49:25] Accepted a3546444 GPU 2 thread 2 pool 0
[2011-08-22 14:49:25] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:25] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:27] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:27] Thread 6 recovered, GPU 0 declared WELL!
[2011-08-22 14:49:28] Accepted 0f407e0e GPU 2 thread 8 pool 0
[2011-08-22 14:49:29] Thread 3 not responding for more than 10 minutes, GPU 0 declared DEAD!
[2011-08-22 14:49:29] Thread 6 recovered, GPU 0 declared WELL!

GPU's all look alive:

Quote
GPU 0: [354.8 / 351.6 Mh/s] [Q:9  A:18  R:0  HW:0  E:200%  U:6.03/m]
Last initialised: [2011-08-22 14:47:12]
Thread 0: 118.7 Mh/s Enabled ALIVE
Thread 3: 118.0 Mh/s Enabled ALIVE
Thread 6: 118.0 Mh/s Enabled ALIVE

GPU 1: [359.7 / 358.8 Mh/s] [Q:11  A:9  R:0  HW:0  E:82%  U:3.02/m]
Last initialised: [2011-08-22 14:47:13]
Thread 1: 109.6 Mh/s Enabled ALIVE
Thread 4: 126.3 Mh/s Enabled ALIVE
Thread 7: 126.6 Mh/s Enabled ALIVE

GPU 2: [355.5 / 349.0 Mh/s] [Q:8  A:31  R:0  HW:0  E:443%  U:10.39/m]
Last initialised: [2011-08-22 14:47:13]
Thread 2: 118.6 Mh/s Enabled ALIVE
Thread 5: 118.2 Mh/s Enabled ALIVE
Thread 8: 118.9 Mh/s Enabled ALIVE

If I reduce the threads-per-GPU to (2) instead of (3) it complains about 3 not responding and 0 recovers.

Ideas?

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
The thing is I never sent it the kill message and cgminer keeps crashing like this. I looked at my cron log where I have a cron that checks for cgminer process and starts a new one if it doenst exist which runs every 5 minutes. I see that it has run every five minutes.
That looks like you've run out of networking capacity to even send anything. Hrm. In this case it might be worth increasing the retry time from 5 seconds to something like 30. -R 30. Meanwhile I'll look at the pool switch code myself as I'm considering getting rid of the 5 minute switch and make it shorter.
newbie
Activity: 5
Merit: 0
The for the great work.
1EZys3JL4ga8EVdvUVdhAmCxWwFoaPNPqz

I must report that the 1.5.7 is a little bit faster (?!) compared to version 1.5.6 in U/s (5.81 /s after 1,5 h vs 5.66 /s / h ).
My GPU is VLIW4 6950@6970 // Win7x64
Jump to: