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

Hi ckolivas,

a few weeks back I ran into some communication failures and high reject numbers at BTCGuild after a LP-change

I escalated the problem to Eleuthria https://bitcointalksearch.org/topic/m.839599 and he said he would contact you about it

Apparently the problem doesn't come up with everyone just with low-latency miners and pools with Poolservj running

I'm running into the same problems with Clipse's pool but have NO problems when mining on Deepbit for instance (tried out a lot of different pools in the last few days)

I submitted CGMiner output on BTCGuild here https://bitcointalksearch.org/topic/m.839444

and this is the output from Clipse's pool


I hope you can make sense of it and I am curious if others are having the same problems....

WTF is ATT and is it cross platform software with source?

Any other linux apps then which can undervolt it?  

 Maybe just ask Ray Adams (ATT developer) how he did it? It's actually pretty funny that ATT is the only one app that can underclock memory of 6xxx series to 300 mhz or lower. Something is plain wrong here. Eh, maybe because he's russian? 

No, they're the limits of software manipulation without device specific hacks that are only available to certain vendors (i.e. not me).

Thanks! Working now. There's another issue tho - I can't change voltage for 6870 in cgminer, for 5770 its working fine. This is the only one issue which stops me from moving to linux.
 Btw it's possible to integrate similiar overclocking system as in ati tray tools, so it will be possible to underclock memory to 300 mhz and lower with cgminer for 6xxx series? Maybe ATT dev using some simple trick for it.

my only question is did you intend to call them Windows Lusers? hahaha

The version number was the only thing missing from the binary. I've reuploaded it (it's the same but just shows 2.3.3).

Installed 2.3.3 and it still shows "cgminer version 2.3.2" for the Ubuntu binary. Also been getting some weird screen lag on my display GPU, but it's still set at dynamic intensity like it's always been. The display GPU is getting about half the hashrate that it usually gets too.

EDIT: It looks like this was triggered by my trying out a new pool and changing from d,7 intensities and -g 1 to d,8 and default threads. Switching back to a p2pool node with d,7 and -g 1 again fixed it.

Version 2.3.3 - April 15, 2012

Human readable summary:
- Over temperature GPUs that should have had mining suspended but did not, should now be fixed.
- Windows lusers that had the ATI Display Library fail and stop reporting fan speed, which would then cause cgminer to just abruptly stop, should now have cgminer spontaneously restart from scratch if it detects this mode of AMD failure. It is a gamble, but should work based on feedback from people that had this problem.
- There is now a restart cgminer option within cgminer.
- When mining with more than 8 devices, the display will only show a summary instead of corruption.

Full changelog:
- Don't even display that cpumining is disabled on ./configure to discourage
people from enabling it.
- Do a complete cgminer restart if the ATI Display Library fails, as it does on
windows after running for some time, when fanspeed reporting fails.
- Cache the initial arguments passed to cgminer and implement an attempted
restart option from the settings menu.
- Disable per-device status lines when there are more than 8 devices since
screen output will be corrupted, enumerating them to the log output instead at
startup.
- Reuse Vals[] array more than W[] till they're re-initialised on the second
sha256 cycle in poclbm kernel.
- Minor variable alignment in poclbm kernel.
- Make sure to disable devices with any status not being DEV_ENABLED to ensure
that thermal cutoff code works as it was setting the status to DEV_RECOVER.
- Re-initialising ADL simply made the driver fail since it is corruption over
time within the windows driver that's responsible. Revert "Attempt to
re-initialise ADL should a device that previously reported fanspeed stops
reporting it."
- Microoptimise poclbm kernel by ordering Val variables according to usage
frequency.

It's true. So I just restart cgminer every seven days, usually on saturdays lol

Bug's been mentioned. Working on it now.

I updated cgminer from version 2.3.1 to 2.3.2 on a few of my windows 7 machines recently, and let it run for over 8 days straight (which is around when ADL normally fails). Now instead of just ADL failing, cgminer completly stops hashing and refuses to respond to any keyboard input, but the API still works.

Basically the issue is you have a corrupt sdk installation, usually a mixture of files from multiple SDKs and not a complete installation of any one. You've gotta clear it all out somehow...

I get the same error in on 12.1, 12.2, and 12.3 I even thought maybe I didn't unzip my files in root or something and redid all the SDKs but no luck.

2.4 Looks like it will almost work then Segfaults just about as it looks like its going to LP. Is there more debugging info I can provide somehow? -n just goes right to segfault with 2.5, and 2.4 actually looks like it works when you -n but doesn't once you start it up.

Sigh..

Not quite It's:
PGA, Name, ID

The PGA number starts at 0 and goes up to the number of PGA devices -1
The ID matches the order on the screen - and it's the cgminer internal sequential device_id

The point of PGA is that you send PGA only commands and they refer to the PGA devices in device_id order but not skipping numbers.
Thus it's always just a simple number range starting at 0.

So on my rig (2x6950 + 2xIcarus):
GPU=0,...|
GPU=1,...|
PGA=0,Name=ICA,ID=2,...|
PGA=1,Name=ICA,ID=3,...|

Kano,

You've got in the devs list, 'ID' and 'BFL'/'ICA' etc. to give us some number. What's the difference between these numbers? Are they equivilent, or might you get something like:
ID 0, BFL 0
ID 1, BFL 1
ID 2, ICA 0
...

And when you request data with gpu|N or PGA|N, is that N 'ID' or 'BFL'/'ICA' etc?

Thanks

Okay thanks. I have reviewed the code in question and indeed it would not cut out. I have fixed this bug in the current git tree.

No, it never stops, shares are submitted with same speed at same temp. I've tested identical config with 2.2.1 and it worked without any issues.

Restart with all stats carried over might be more than a little messy, and much more prone to failure...

Yes, I would like to see this ;-) Also, restart with all stats still available if possible ;-)

I will donate 10 BTC for this feature ;-)