OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[sharky112065]

AH... I see we are Windows bashing again.

Begging your pardon, my post was clearly targeted at someone else but since you decided to hop in:

Some people need Windows because they mine with 69XX cards.

Some people mine with their nVidia cards - doesn't mean they should either. That's all I have to say in regards to 40nm VLIW4 cards.

Begging your pardon, you were not the only person that was targeted at.

I will mine with what I have, as will others.

[kano]

Yes, Vista sucked, but Windows 7 is just as stable as XP and perfectly usable as an everyday OS...

There, without knowing what you just said, you said it.
Windows is a decent everyday OS.
Serious bitcoin mining, however, is much simpler, easier, and less resource-intensive using a leaner, task-oriented OS like your favourite Linux flavor.

What good do automatic updates, insane amounts of background housekeeping stuff, the indexing service, or wide open NETBIOS ports do you for bitcoin mining purposes?
How suitable for mining are all those default Power Management options? How useful are System Restore and Shadow Files?
For all those useless (from mining POV) features you don't even get a functional Remote Desktop server...
...and worst of all, you have to dole out money for the doubtful pleasure of installing Windows on your mining rig.
Insanity.

Well sure, I agree that if you have a solo box that you've dedicated just to mining, then stick one of the million iterations of Linux on it.   Personally though, I have one PC (and some laptops) in my place, and that PC is used for several things.  It's my download box, it's my media server and it's my mining box.  I have Windows 7 on it because it works for all three (Linux probably would as well, but I know Windows inside out so until I have a lot of free time to learn Linux inside out, I'll be sticking with it)



Anyway, whatever, cgminer... carry on !

OK the noob needs some help ...
Firstly, this: is called a smiley.
I'll explain why I used it in my windows xp post since you still haven't worked that out yet.
They are often posted when people are joking about something.
Let me know if you need that term (joking) explained ...

Next lesson: when your a noob and you've posted 11 posts of no useful content and calling people trolls and dicks you really need to learn to chill and pretend you actually aren't a complete noob with some strange complex.

Next: I don't care about calling me a troll in the other thread and saying above that I never get anything right - yeah so what ... just hope you don't ever need to ask me anything coz I certainly wont be replying ... saving you from being trolled by me or given false information - aren't I nice

... but calling D&T a troll and a dick - lol - seriously? - you've posted nothing but useless crap here at bitcointalk so far - that's the funniest thing I've read all day
(yes anyone can go see a single list of every post you've posted so far with 2 clicks)

Oh and lastly, don't forget to reply to this so you can have the last word - I'm sure that's important for you and I'll let you have the last word - as I said above about replying ...



... as for everyone else - c'mon chill - this isn't a I love windows thread (or an I hate windows thread ... unless ckolivas wants it to be ) we've heard enough of Bill Gates virtues to convince everyone to get rid of linux on their rigs

[fred0]

I was thinking that a nice feature for cgminer would be load balance target percentages.

Since shares are split between donation and our own, then (I think) why not load balance using the same mechanism.

For example, one could specify --load-balance 55,45,0 .  This would specify 55% of shares go to pool 0, 45 to pool 1, and pool 2 would get 0% shares(thus being a failover-only pool).

Is this a reasonable feature?

[kentrolla]

update to fix winxp bug PLZ

But I could also add the other obvious reply

There is no fix for windows xp - windows xp is just one very large bug and all the MS fixes since then don't seem to have resolved that ... vista, 7, 8 ...

Yeah. IMHO kano is totally right.

Well, there's a first time for everything, but this isn't one of them.   WinXP is very stable, and has been for a long time.  Yes, Vista sucked, but Windows 7 is just as stable as XP and perfectly usable as an everyday OS.

Honestly you just embarrass yourself by posting generic clichés like that.

I was just joking of course
I think that was obvious.

But the point is that mr kentrolla was last complaining about cgminer not working properly in a virtual windows - so seriously yeah no one's gonna take any notice of that.

Otherwise - if he has some actual windows xp problem, speak up ...

i do have a windows XP problem. It doesnt work on my friend's machine either (hes running winxp 32 bit) 

[RoloTonyBrownTown]

OK the noob needs some help ...
Firstly, this: is called a smiley.
I'll explain why I used it in my windows xp post since you still haven't worked that out yet.
They are often posted when people are joking about something.
Let me know if you need that term (joking) explained ...

Next lesson: when your a noob and you've posted 11 posts of no useful content and calling people trolls and dicks you really need to learn to chill and pretend you actually aren't a complete noob with some strange complex.

Next: I don't care about calling me a troll in the other thread and saying above that I never get anything right - yeah so what ... just hope you don't ever need to ask me anything coz I certainly wont be replying ... saving you from being trolled by me or given false information - aren't I nice

... but calling D&T a troll and a dick - lol - seriously? - you've posted nothing but useless crap here at bitcointalk so far - that's the funniest thing I've read all day
(yes anyone can go see a single list of every post you've posted so far with 2 clicks)

Oh and lastly, don't forget to reply to this so you can have the last word - I'm sure that's important for you and I'll let you have the last word - as I said above about replying ...



...

That's OK.  You've given out so much crappy advice in this thread so far I very rarely read your posts anymore.  Thanks for your concern anyway (and your crappy psychology attempt at the end there isn't going to get me to shut up, but good (not really) effort anyway).

[miscreanity]

I was thinking that a nice feature for cgminer would be load balance target percentages.

Since shares are split between donation and our own, then (I think) why not load balance using the same mechanism.

For example, one could specify --load-balance 55,45,0 .  This would specify 55% of shares go to pool 0, 45 to pool 1, and pool 2 would get 0% shares(thus being a failover-only pool).

Is this a reasonable feature?

This could be useful, particularly in reserving some power for solo mining without it being evenly split among others.

On another note, is there a record for lowest Rejected/Accepted ratio? I'm at 0.12% with A:>5k. I have to say, pool choice can make a big difference.

[mmortal03]

However, this was before I realized the potential capabilities of Advanced Power Options -> Processor Power Management -> Maximum processor state in Windows.  By default, maximum processor state is set to 100%. Using CPU-Z, I've been able to demonstrate that once I increase the intensity setting to 10 or more in CGMINER, my Atom processor in fact scales up from 800 MHz to 1600 MHz along with the increase in CPU usage.  My thinking here is that this may likely have been where the additional increase in wattage had been coming from when I'd originally found that intensity settings higher than 9 were detrimental to profitability.

So, I've just experimented with setting my maximum processor state down to 50%, and, as expected, when testing CGMINER at intensities higher than 9 (up to 12 so far), and my processor now no longer scales up to 1600 MHz in CPU-Z. My thinking is that this should allow me to squeeze a few more megahashes out of this setup without raising my overall wattage quite as much, if at all.

Read the first post.  Intensity 10+ was designed for future cards.  You shouldn't use intensity >8 or 9 with 5000 or 6000 series cards.  8 for lower end and 9 for higher end.

Intensity simply increases the size of each workload.  That it.  GPU work in "batches".  You can't interrupt a GPU once it starts working.

I am not sure the algorithm conman uses but (hypothetical numbers).

1 nonce range = 2^32 = 4 billion hashes.  An 300 MH/s card would take 11 seconds to complete.

An intensity of 8 might say do 300 million hashes and return results.
And inensity of 9 might say do 600 million hashes and return results.
An intensity of 10 might say do 1 billion hashes and return results.

All you are doing is increasing the "batch size" which takes longer to run.  You gain a small boost by eliminating the number of batches and thus overhead to complete a nonce but you also make the card unresponsive for longer and longer periods of time.  

However a hypothetical 1 GH/s card could do intensity 10 in 1 second.  So thus intensity 10 on this card is no different than intensity 8 on your card.

Make sense?  

TL/DR version:
You research is somewhat useless.  You will not find intensity 10+ improves performance with CURRENT cards.  Higher intensity exists simply to allow faster hashing engines.  If tomorrow someone released an FPGA which did 2GH/s on a single chip likely intensity 10 or 11 would be optimal.

Thanks for the detailed explanation.  I follow most of what you are saying.  That considered, are the 8 or 9 extra megahash that cgminer is reporting at the higher intensities actually fools gold? What I mean is that could the reported number by cgminer not be indicative of the numbers that the pool is getting from me, due to the longer periods of unresponsiveness at the higher intensities? I guess I'll have to compare the various intensity settings and the hashrates cgminer is reporting to what the mining server is calculating as the hashrate over a period of time and see if there is a disparity between the test cases.  Shouldn't that be the only place I see evidence of what you're describing, or is there another stat in cgminer I can refer to?

[kano]

I was thinking that a nice feature for cgminer would be load balance target percentages.

Since shares are split between donation and our own, then (I think) why not load balance using the same mechanism.

For example, one could specify --load-balance 55,45,0 .  This would specify 55% of shares go to pool 0, 45 to pool 1, and pool 2 would get 0% shares(thus being a failover-only pool).

Is this a reasonable feature?

This could be useful, particularly in reserving some power for solo mining without it being evenly split among others.

On another note, is there a record for lowest Rejected/Accepted ratio? I'm at 0.12% with A:>5k. I have to say, pool choice can make a big difference.

When I switched back to ozcoin soon after they moved to DGM (beginning of January) I got 1 Reject in the first 15272 Accepted shares - not bad 0.00655 %
I got 4 more in the next 11480 shares after that (0.035%)

Edit: I should add, this is with 2x GA HD 6950 (one sits at 900Mhz and the other at 870Mhz) getting about 724Mh/s
So there were a lot of LP's (the usual cause of Rejects)

[The00Dustin]

Thanks for the detailed explanation.  I follow most of what you are saying.  That considered, are the 8 or 9 extra megahash that cgminer is reporting at the higher intensities actually fools gold? What I mean is that could the reported number by cgminer not be indicative of the numbers that the pool is getting from me, due to the longer periods of unresponsiveness at the higher intensities? I guess I'll have to compare the various intensity settings and the hashrates cgminer is reporting to what the mining server is calculating as the hashrate over a period of time and see if there is a disparity between the test cases.  Shouldn't that be the only place I see evidence of what you're describing, or is there another stat in cgminer I can refer to?

It would appear that you missed this:

So, I've just experimented with setting my maximum processor state down to 50%, and, as expected, when testing CGMINER at intensities higher than 9 (up to 12 so far), and my processor now no longer scales up to 1600 MHz in CPU-Z. My thinking is that this should allow me to squeeze a few more megahashes out of this setup without raising my overall wattage quite as much, if at all.

Your only metric should be U/W mate, MH/W may show better results with increased intensity but in most cases you will be lowering U, and only U matters.

* Vbs bows to U!

U will vary some with luck, but it is as good as (or better than) what the server is calculating hashrate over time with.  As good as because the server's calculation is based on shares per time range (U is shares per minute).  Better because it is for the entire mining session instead of the last X minutes a pool server uses.  Also, on a related note, maybe your processor can get 8MH/s and the 8MH/s extra isn't even coming from the video card.  If that is the case, cutting the CPU frequency in half would lower it to a 4 MH/s gain at a still much more expensive MH/W (although realistically, even if it is the GPU getting that, running the CPU 100% at half frequency will probably still draw enough power to make it a net loss).  Also, maybe U will be lower because more stales will have to be discarded when it takes longer for the GPU to finish the larger batch of work, meaning higher MH/s in real life, but lower U (and lower MH/s calculated by the server).

[jake262144]

Also, maybe U will be lower because more stales will have to be discarded when it takes longer for the GPU to finish the larger batch of work, meaning higher MH/s in real life, but lower U (and lower MH/s calculated by the server).

Precisely.
This fact seems to be oftentimes overlooked when users go only for MHash/s in their GPU tweaking.
If your pool server is constantly showing a significantly lower MHash/s estimate then what your miner tells you, consider dropping intensity a notch.
Using intensity 9 for low-to-medium class 200MHash/s GPUs is already too much, they really benefit from 8.

[bulanula]

Also, maybe U will be lower because more stales will have to be discarded when it takes longer for the GPU to finish the larger batch of work, meaning higher MH/s in real life, but lower U (and lower MH/s calculated by the server).

Precisely.
This fact seems to be oftentimes overlooked when users go only for MHash/s in their GPU tweaking.
If your pool server is constantly showing a significantly lower MHash/s estimate then what your miner tells you, consider dropping intensity a notch.
Using intensity 9 for low-to-medium class 200MHash/s GPUs is already too much, they really benefit from 8.

What about 5870s ? What intensity to use for that ?

[DeathAndTaxes]

Thanks for the detailed explanation.  I follow most of what you are saying.  That considered, are the 8 or 9 extra megahash that cgminer is reporting at the higher intensities actually fools gold? What I mean is that could the reported number by cgminer not be indicative of the numbers that the pool is getting from me, due to the longer periods of unresponsiveness at the higher intensities? I guess I'll have to compare the various intensity settings and the hashrates cgminer is reporting to what the mining server is calculating as the hashrate over a period of time and see if there is a disparity between the test cases.  Shouldn't that be the only place I see evidence of what you're describing, or is there another stat in cgminer I can refer to?

No it isn't fool's gold.  Higher intensity = larger batch and the GPU does have some overhead in setting up and finishing a batch.  So larger batches = less setup & takedowns for same number of hashes.

That being said what matters most is U.  It is possible to have higher hashrate but because you are pushing the card too hard you increase rejects (due to bad calculations).  U is the only metric that matters.  U is what you get paid on.  It is possible (although improbable) that you would get a higher U w/ intensity 10.  For a dedicated rig the lagginess and unresponsiveness of the system doesn't really matter.


If you want to test the effect of intensity the best way is to use multiple GPU and just set each one to a different Itensity (and keep all other settings the same) and measure U (all hail the all-mighty U).  Run them that way for at least 3 or 4 hours (6 would be better) to reduce any effect on variance.  cgminer calculates U over the entire session so longer session is better.  If you don't have identical GPU you can do the same thing w/ multiple sequential tests it will just take longer.

[DeathAndTaxes]

What about 5870s ? What intensity to use for that ?

For 5970 (basically same card) I find very little difference in U (to beat a dead horse deader, the only real measure of performance) between Intensity 8 or 9.  That being said on my dedicated rigs since I don't care about unresponsiveness or desktop lagginess I run them at 9.  Got to get every 0.01 extra shares per minute right?

[Peao]

Guys, I need help.

I recently upgrade from 2.0.7 to 2.2.1 cgminer on my Ubuntu 64 rigs.

I noticed that eventually some GPUs appear OFF (not DEAD, not SICK). This did not happen in version 2.0.7.
This problem has bothered me because it is frequent (about 1-2 times a day @ random rigs), and ultimately hurts my average hash rate.

I searched quickly on this topic, read the README and NEWS file in the directory cgminer but not found anything that seemed to solve this problem.

Could anyone help me with some idea to solve the problem, please?

My command line:
cgminer -o xxx -u yyy -p zzz -I 8 --auto-fan --auto-gpu --gpu-engine 600-725 --gpu-memclock 160 --temp-target 76 --gpu-vddc 0.98

P.S.1: they are not overheating.
P.S.2: sorry, english is not my native language

[DeathAndTaxes]

Guys, I need help.

I recently upgrade from 2.0.7 to 2.2.1 cgminer on my Ubuntu 64 rigs.

I noticed that eventually some GPUs appear OFF (not DEAD, not SICK). This did not happen in version 2.0.7.
This problem has bothered me because it is frequent (about 1-2 times a day @ random rigs - 3x5970, 3x5870, 2x5970, 1x5870&1x5970&1x6950, 2x6990 ...), and ultimately hurts my average hash rate.

I searched quickly on this topic, read the README and NEWS file in the directory cgminer but not found anything that seemed to solve this problem.

Could anyone help me with some idea to solve the problem, please?

My command line:
cgminer -o xxx -u yyy -p zzz -I 8 --auto-fan --auto-gpu --gpu-engine 600-725 --gpu-memclock 160 --temp-target 76 --gpu-vddc 0.98

P.S.1: they are not overheating.
P.S.2: sorry, english is not my native language

Only time I have seen OFF is when the card temp exceeded --temp-cutoff value.  If you don't set a --temp-cutoff I am not sure what it defaults to.

[gnar1ta$]

Only time I have seen OFF is when the card temp exceeded --temp-cutoff value.  If you don't set a --temp-cutoff I am not sure what it defaults to.

--temp-cutoff <arg> Temperature where a GPU device will be automatically disabled, one value or comma separated list (default: 95)

Will it still shut off without using --auto-gpu?  I just realized I have a rig without --auto-gpu because I want the clocks fixed, but does that mean it will burn up when the AC breaks?

[Peao]

I'll add the instruction --temp-cutoff 96 to see if there is any change.

[DeathAndTaxes]

--temp-cutoff <arg> Temperature where a GPU device will be automatically disabled, one value or comma separated list (default: 95)

Will it still shut off without using --auto-gpu?  I just realized I have a rig without --auto-gpu because I want the clocks fixed, but does that mean it will burn up when the AC breaks?

Not sure.  I always use auto-gpu.  I would assume --temp-cutoff is always used even if auto-gpu = false but that might be a dangerous assumption.  Hopefully conman can weigh in.

[bitclown]

i do have a windows XP problem. It doesnt work on my friend's machine either (hes running winxp 32 bit) 

You still haven't mentioned what the problem is. That said, you shouldn't expect modern hardware and software to operate painlessly on your legacy system. I don't see any Linux users demanding 2.4 support, which was the kernel version at the time WinXP was released.

[bulanula]

--temp-cutoff <arg> Temperature where a GPU device will be automatically disabled, one value or comma separated list (default: 95)

Will it still shut off without using --auto-gpu?  I just realized I have a rig without --auto-gpu because I want the clocks fixed, but does that mean it will burn up when the AC breaks?

Not sure.  I always use auto-gpu.  I would assume --temp-cutoff is always used even if auto-gpu = false but that might be a dangerous assumption.  Hopefully conman can weigh in.

Yeah. I happen to be very interested in this as well.

What exactly are the safeguards in place by default ( or not by default and user must set them implicitly ) in case the GPU fan dies completely and I am not present or able to assist ASAP to come and stop the mining from killing the fanless card ?

Thanks !