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

[-ck]

Ofcourse. Just use cgminer.exe -c pool1.cfg -c pool2.cfg

or use multiple -o, -u, -p statements. Works fine here. (.ie cgminer.exe -o http://url_pool1:port -u username_pool1 -p pass_pool1 -o http://url_pool2:port -u username_pool2 -p pass_pool2)

Nice, I'll give that a shot.  So, the second -o/u/p set is not used at all unless the first is down?  Will it automatically failback to the original?  Can you have a third or fourth set as well?

Just wondering

You can have as many as you like, and it will trickle work to the 2nd and 3rd when the 1st is relatively slow, or fail over completely to the 2nd when the 1st dies. Alternatively you can change the pool strategy to load balance where it shares work between all of them, etc... check the readme or top post in this forum. Also you can do all of this live while it's running just by pressing P and checking the options.

[1714502743]

1714502743

[1714502743]

1714502743

[1714502743]

1714502743

[1714502743]

1714502743

[os008]

Hi,
Is there a big difference between version 1.5.1 and 1.5.3 please? I had too much trouble compiling CGMiner, so i've dropped the idea of building it myself.

[d3m0n1q_733rz]

Hey guys, check this out!
http://developer.amd.com/libraries/acmlgpu/Pages/default.aspx
Soon enough, we may be able to bridge the gap between CPU and GPU mining with the same kernel.   
I must say, things are looking promising.

[-ck]

Current 110810 kernel on git has 1368 ALU OPs for 58XX and 1696 for 69XX, that's neither phatk 2.2 nor my latest result (which is 1364 / 1688), but a bit faster than the last official CGMINER kernel. I mailed my latest version to Con for review .

The added __attribute__((vec_type_hint(u))) is unknown to the compiler and throws a warning, but IS mentioned in the OpenCL 1.1 manual ... strange.

Dia

Correct, it's not 2.2, nor your most recent. It was an honest attempt at integrating *both* of them, but I think now that  I missed a few things.

I had noticed the Kernel Analyzer threw an error about vec_type_hint, but it compiles without issue on linux. I don't have native windows (only virtualized) to test anything there. In testing, I was unsure as to whether vec_type_hint made an improvement, but I was certain that it wasn't the opposite.

After running it for a while on my 6970s, I find even this change is of no benefit either  It's ever so slightly slower it appears. Not sure what to do now about all this.

[ah42]

After running it for a while on my 6970s, I find even this change is of no benefit either  It's ever so slightly slower it appears. Not sure what to do now about all this.

I'll just be quiet and go back in my hole for a bit. :/

[-ck]

After running it for a while on my 6970s, I find even this change is of no benefit either  It's ever so slightly slower it appears. Not sure what to do now about all this.

I'll just be quiet and go back in my hole for a bit. :/

Don't be disheartened. I'm forever hacking up code and then deleting it. You wouldn't believe how much code I've thrown out so far working on cgminer. Not every experiment is successful.

[d3m0n1q_733rz]

After running it for a while on my 6970s, I find even this change is of no benefit either  It's ever so slightly slower it appears. Not sure what to do now about all this.

I'll just be quiet and go back in my hole for a bit. :/

Don't be disheartened. I'm forever hacking up code and then deleting it. You wouldn't believe how much code I've thrown out so far working on cgminer. Not every experiment is successful.

I'll attest to that.  I've fiddled around with the SSE4 code for what seemed like endless nights increasing and decreasing hash rates and came to realize the my second to the last post had the best hashing rate and that my last was slower than the original.  But I'm curious to see if we'll ever come up with something that uses the CPU and GPU together in the same calculations via the math library I posted earlier.  It'll be interesting to see what comes out of it.
I'm still trying to figure out how to specify compiler options for cl code.  I was going to test out the unsafe math optimization and see what comes out of it.  There are actually quite a few optimizations to play around with for speeding up memory transfers via non-temporal writes, increasing data size, prefetching, using the differences between the initial constants instead of the actual values to shrink the table, etc.
It's really like trying to solve a puzzle with many different answers.  Only, you're trying to solve it better than anyone else has already.

[kripz]

Just compiled and now im getting abnormally high rejects on one of my PCs. Nothing has changed and was fine prior to the update.

cgminer version 1.5.3 - Started: [2011-08-13 20:50:28]
--------------------------------------------------------------------------------
 [(5s):193.0  (avg):191.4 Mh/s] [Q:34  A:73  R:87  HW:0  E:215%  U:1.31/m]

Could this be related to the kernel tweaking?

5770 running 11.6 on Debian 32bit.

[Remember remember the 5th of November]

Just compiled and now im getting abnormally high rejects on one of my PCs. Nothing has changed and was fine prior to the update.

cgminer version 1.5.3 - Started: [2011-08-13 20:50:28]
--------------------------------------------------------------------------------
 [(5s):193.0  (avg):191.4 Mh/s] [Q:34  A:73  R:87  HW:0  E:215%  U:1.31/m]

Could this be related to the kernel tweaking?

5770 running 11.6 on Debian 32bit.

Are you solo mining with cgminer? If so, that is the case.

[drgr33n]

Just compiled and now im getting abnormally high rejects on one of my PCs. Nothing has changed and was fine prior to the update.

cgminer version 1.5.3 - Started: [2011-08-13 20:50:28]
--------------------------------------------------------------------------------
 [(5s):193.0  (avg):191.4 Mh/s] [Q:34  A:73  R:87  HW:0  E:215%  U:1.31/m]

Could this be related to the kernel tweaking?

5770 running 11.6 on Debian 32bit.

Are you solo mining with cgminer? If so, that is the case.

Nice name Will be exciting to watch !!

[twmz]

In experimenting with bitpenny and p2pool which both set work unit target difficulty to something other than 1, it is apparent that cgminer does not honor the target that is include in the getwork response and instead submits every share that passes difficulty 1 even if the actual target difficulty is higher.  For example, on bitpenny, shares are all difficulty 8.  This leads to most shares being rejected because they are not valid difficulty 8 shares.  In the grand scheme of things, this doesn't hurt anything, except it makes the stats and output of cgminer fairly broken because the reject rate is very high and the log is filled with mostly rejected invalid shares.

I understand that the kernels appear to return any share that looks like it passes the difficulty 1 target.  Instead of changing the kernels (which probably would slow them down), you could just double-check the returned hash to see if it is truely valid before submitting it.  This appears to be what phoenix and the latest version of luke's (and maybe the mainline) poclbm do.

[-ck]

What version of cgminer are you testing that does that? Because that's precisely what it does in submit_nonce:

   /* Do one last check before attempting to submit the work */
   if (!fulltest(work->data + 64, work->target))
      return true;

Or am I missing something

[twmz]

What version of cgminer are you testing that does that? Because that's precisely what it does in submit_nonce:

   /* Do one last check before attempting to submit the work */
   if (!fulltest(work->data + 64, work->target))
      return true;

Or am I missing something

Sorry, I am still on 1.4.something.  I avoided 1.5.x because of the several reports of problems with it and because you were out of town.  I'll try that now.

[-ck]

New release 1.5.4:

Source:
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.4.tar.bz2
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.4.tar.lrz

Linux x86_64 ubuntu binary:
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.4-x86_64-built.tar.bz2
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.4-x86_64-built.tar.lrz

Hopefully we can get a windows version from someone somewhere soon :O

Summary: cgminer should now use the backup pools much less frequently, should drop in performance on a longpoll much less, communicate with the server less, have higher efficiency, and hopefully have less problems with dying GPUs. It also supports the --monitor command (linux only at this stage).


Full Changelog:

- Add new option: --monitor <cmd> Option lets user specify a command <cmd> that
will get forked by cgminer on startup. cgminer's stderr output subsequently gets
piped directly to this command.
- Allocate work from one function to be able to initialise variables added
later.
- Add missing fflush(stdout) for --ndevs and conclusion summary.
- Preinitialise the devices only once on startup.
- Move the non cl_ variables into the cgpu info struct to allow creating a new
cl state on reinit, preserving known GPU variables.
- Create a new context from scratch in initCQ in case something was corrupted to
maximise our chance of succesfully creating a new worker thread. Hopefully this
makes thread restart on GPU failure more reliable, without hanging everything
in the case of a completely wedged GPU.
- Display last initialised time in gpu management info, to know if a GPU has
been re-initialised.
- When pinging a sick cpu, flush finish and then ping it in a separate thread in
the hope it recovers without needing a restart, but without blocking code
elsewhere.
- Only consider a pool lagging if we actually need the work and we have none
staged despite queue requests stacking up. This decreases significantly the
amount of work that leaks to the backup pools.
- The can_roll function fails inappropriately in stale_work.
- Only put the message that a pool is down if not pinging it every minute. This
prevents cgminer from saying pool down at 1 minute intervals unless in debug
mode.
- Free all work in one place allowing us to perform actions on it in the future.
- Remove the extra shift in the output code which was of dubious benefit. In
fact in cgminer's implementation, removing this caused a miniscule speedup.
- Test each work item to see if it can be rolled instead of per-pool and roll
whenever possible, adhering to the 60 second timeout. This makes the period
after a longpoll have smaller dips in throughput, as well as requiring less
getworks overall thus increasing efficiency.
- Stick to rolling only work from the current pool unless we're in load balance
mode or lagging to avoid aggressive rolling imitating load balancing.
- If a work item has had any mining done on it, don't consider it discarded
work.

[Endeavour79]

Thanks!!

Can we have a Windows build please ?!

[phase]

Thanks Con, up & running, working like a charm

[govindas]

Looks like the 1.5.3 configure script inadvertently dropped support for alternate cURL library path support via --with-libcurl:

Yes, because it's the crappy way to do it. The right way is to export a variable to specify the PKG_CONFIG_PATH to the correct *.pc file. See my RPMs for reference...

Sorry for bringing this up again but how do i compile  >=1.5.3  without installing curl?

[-ck]

Looks like the 1.5.3 configure script inadvertently dropped support for alternate cURL library path support via --with-libcurl:

Yes, because it's the crappy way to do it. The right way is to export a variable to specify the PKG_CONFIG_PATH to the correct *.pc file. See my RPMs for reference...

Sorry for bringing this up again but how do i compile  >=1.5.3  without installing curl?

You cannot.

[-ck]

What version of cgminer are you testing that does that? Because that's precisely what it does in submit_nonce:

   /* Do one last check before attempting to submit the work */
   if (!fulltest(work->data + 64, work->target))
      return true;

Or am I missing something

Sorry, I am still on 1.4.something.  I avoided 1.5.x because of the several reports of problems with it and because you were out of town.  I'll try that now.

"forrestv" just informed me the fulltest function was disabled due to endian issues (I think) in the original cpuminer code that cgminer grew out of. Since cgminer pretty much only builds on little endian machines now anyway, it has been re-enabled, but only in the git tree. So this test is not active yet in the current release (1.5.4).

[-ck]

HEADS UP TO GIT USERS.

The default branch is now "master" once more. Please use that instead of the branch called cgminer.