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

[kano]

Hey All! Thanks for creating an absolutely incredible mining program. You all rock!

I'm writing a monitoring program for my miner, I've IP address restricted access to the port, but I was wondering if there is any way of providing a password on access?

Cheers!

No ... and clear text passwords make most people think something that isn't true (and shouldn't exist in any system)
Curl isn't available for the API since that would clash with cgminer using it with the pools and possibly cause problems there.
Any other encryption requires code at both ends ... though since curl allows ssl and requires an ssl library I guess that library could make it simple at the miner end - but complicate the monitor end.

[kano]

Edit: and thanks immensely for whoever this was
http://blockchain.info/tx-index/16997867/4444a3ccb8c577295c11ee3710ae72416109d05ec99ca8641dde39a8837ed0ef

You're welcome. Now could you get hardware error counting fixed?  Pretty please?

I'm running a debug version of it (yet again) since yesterday trying to find the cause of the loop (that doesn't really cause any problems but I need to know why first )

(I ran it for 3 or 4 days before and couldn't get the error to happen again)

If you (or anyone else) has enough CM1's, I can give you a binary that will turn on the debug when it hits 2000 HW errors and thus give me the debug that will probably say why it gets into the loop (and also gets out of it so it doesn't actually cause any problems)
... though I did a minor change yesterday ... but no idea if that is the cause ... bit not likely

Though I guess I should chase up spiccioli now since he was the one who regularly had the same error I've so far only had once.

[gyverlb]

Hey All! Thanks for creating an absolutely incredible mining program. You all rock!

I'm writing a monitoring program for my miner, I've IP address restricted access to the port, but I was wondering if there is any way of providing a password on access?

Cheers!

There have been other suggestions, but assuming you use Linux you could limit the access only to localhost and then use stunnel or ssh with port forwarding to setup secure connections to the miner.

[Fiyasko]

This thread is getting Very long

[-ck]

This thread is getting Very long

Yes it is, and we shall carry on making it longer.

[-ck]

New version: 2.7.5, 31st August 2012

Survived a whole week without needing to give a hotfix update yay \o/.

This release is just a minor bugfix update. I've changed my build environment so it is less work to build binaries, so I have included an fpgaonly binary as well as the full feature binary. The windows binary is now compressed with 7z since it's getting so large, and will include a different set of DLLs due to it being built differently.


Human readable changelog

- Hopefully fixed the bug where dynamic intensity gets stuck at -10
- Much less pool-not-providing-work fast enough messages.
- Fixed share leakage to backup pools the way it was supposed to work.
- Properly detect SDK2.7 and choose optimal parameters for it.
- Remove the hardcoded worksize for 256 - it had the opposite effect with the new kernels
- Fix the rare occasion there are many new blocks detected in a row.
- Hopefully fixed the load balance and rotate strategies.


Full changelog

- Adjust opencl intensity when adjusting thread count to prevent it getting
pegged at a value below the minimum threads possible.
- miner.h max_hashes -> int64_t
- Keep the local block number in the blocks structs stored and sort them by
number to guarantee we delete the oldest when ageing the block struct entries.
- Use correct sdk version detection for SDK 2.7
- Revert "Pick worksize 256 with Cypress if none is specified."
- Test for lagging once more in queue_request to enable work to leak to backup
pools.
- There is no need to try to switch pools in select_pool since the current pool
is actually not affected by the choice of pool to get work from.
- Only clear the pool lagging flag if we're staging work faster than we're using
it.
- needed flag is currently always false in queue_request. Remove it for now.
- thr is always NULL going into queue_request now.

[Inaba]

2.7.5 crashes occasionally:

[2012-08-31 03:36:40] Accepted 7de59791.15d93a38 BFL 15 pool 0
 [2012-08-31 03:36:40] Accepted 2c6bbc81.dd42014b BFL 16 pool 0
 [2012-08-31 03:36:40] Accepted 1d1efc9b.b8563b1f BFL 16 pool 0
 [2012-08-31 03:36:40] Accepted 518e7a52.f2ccc827 BFL 20 pool 0
 [2012-08-31 03:36:40] Accepted 764d3e7d.cc1a8543 BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted 1764a65f.7da58c1e BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted fc3d419d.66247269 BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted 781d0fcc.7e3675a1 BFL 24 pool 0
 [2012-08-31 03:36:41] Accepted dc8763e5.658a1a1a BFL 24 pool 0
 [2012-08-31 03:36:41] Accepted 010403c4.3e8ba7f8 BFL 30 pool 0
 [2012-08-31 03:36:41] Pool 0 communication failure, caching submissionsSegmentation fault

I tried to get a backtrace of it, but when I run it in the debugger, it doesn't crash and I can't seem to run torify through gdb anyway, which is what I'm running cgminer through.

Which brings me to another request:  Can you make cgminer tor friendly, so you don't have to torify it?  I would love an option to be able to point cgminer to a tor server natively for all it's communications.  Would save a ton of hassle.

[kano]

Edit: and thanks immensely for whoever this was
http://blockchain.info/tx-index/16997867/4444a3ccb8c577295c11ee3710ae72416109d05ec99ca8641dde39a8837ed0ef

You're welcome. Now could you get hardware error counting fixed?  Pretty please?

I'm running a debug version of it (yet again) since yesterday trying to find the cause of the loop (that doesn't really cause any problems but I need to know why first )

(I ran it for 3 or 4 days before and couldn't get the error to happen again)

If you (or anyone else) has enough CM1's, I can give you a binary that will turn on the debug when it hits 2000 HW errors and thus give me the debug that will probably say why it gets into the loop (and also gets out of it so it doesn't actually cause any problems)
... though I did a minor change yesterday ... but no idea if that is the cause ... bit not likely

Though I guess I should chase up spiccioli now since he was the one who regularly had the same error I've so far only had once.

I have 40 or so here. If there is a bug it should turn up fast

No, the bug doesn't show up at all without adding the HW: counter fix.

It's only when I start identifying HW errors in the Icarus code (for CM1 also of course) that the HW: number jumps up a few thousand rarely (unexpectedly)
The mining side effect is so small that no one would notice it at all without the HW: counter.
Thus I want to know why it happens before I put the code out.
If you have time, come visit #cgminer FreeNode IRC and I'll give you a version that has the HW: counter but also spits out a lot of debug if it happens (so I can work out why)

[-ck]

2.7.5 crashes occasionally:

[2012-08-31 03:36:40] Accepted 7de59791.15d93a38 BFL 15 pool 0
 [2012-08-31 03:36:40] Accepted 2c6bbc81.dd42014b BFL 16 pool 0
 [2012-08-31 03:36:40] Accepted 1d1efc9b.b8563b1f BFL 16 pool 0
 [2012-08-31 03:36:40] Accepted 518e7a52.f2ccc827 BFL 20 pool 0
 [2012-08-31 03:36:40] Accepted 764d3e7d.cc1a8543 BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted 1764a65f.7da58c1e BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted fc3d419d.66247269 BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted 781d0fcc.7e3675a1 BFL 24 pool 0
 [2012-08-31 03:36:41] Accepted dc8763e5.658a1a1a BFL 24 pool 0
 [2012-08-31 03:36:41] Accepted 010403c4.3e8ba7f8 BFL 30 pool 0
 [2012-08-31 03:36:41] Pool 0 communication failure, caching submissionsSegmentation fault

I tried to get a backtrace of it, but when I run it in the debugger, it doesn't crash and I can't seem to run torify through gdb anyway, which is what I'm running cgminer through.

Which brings me to another request:  Can you make cgminer tor friendly, so you don't have to torify it?  I would love an option to be able to point cgminer to a tor server natively for all it's communications.  Would save a ton of hassle.

I'm guessing you're getting the crashes once again when running through tor? I don't know the first thing about tor... yet.

[kano]

2.7.5 crashes occasionally:

[2012-08-31 03:36:40] Accepted 7de59791.15d93a38 BFL 15 pool 0
 [2012-08-31 03:36:40] Accepted 2c6bbc81.dd42014b BFL 16 pool 0
 [2012-08-31 03:36:40] Accepted 1d1efc9b.b8563b1f BFL 16 pool 0
 [2012-08-31 03:36:40] Accepted 518e7a52.f2ccc827 BFL 20 pool 0
 [2012-08-31 03:36:40] Accepted 764d3e7d.cc1a8543 BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted 1764a65f.7da58c1e BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted fc3d419d.66247269 BFL 20 pool 0
 [2012-08-31 03:36:41] Accepted 781d0fcc.7e3675a1 BFL 24 pool 0
 [2012-08-31 03:36:41] Accepted dc8763e5.658a1a1a BFL 24 pool 0
 [2012-08-31 03:36:41] Accepted 010403c4.3e8ba7f8 BFL 30 pool 0
 [2012-08-31 03:36:41] Pool 0 communication failure, caching submissionsSegmentation fault

I tried to get a backtrace of it, but when I run it in the debugger, it doesn't crash and I can't seem to run torify through gdb anyway, which is what I'm running cgminer through.

Which brings me to another request:  Can you make cgminer tor friendly, so you don't have to torify it?  I would love an option to be able to point cgminer to a tor server natively for all it's communications.  Would save a ton of hassle.

If you simply enable core dumps it will at least tell you (with gdb) roughly where it is crashing with 'bt'
If you compile it -g and without -O2 the bt will even tell you the line of code and allow you to access the variables at each stack level.
i.e. you don't run it in gdb, you simply gdb the core file to see all the details of the state when it crashed.

[TheHarbinger]

Con, I'll grab 2.7.5 after I get some sleep, test it out and report back since I was one of the ones that was having the -10 intensity issue.

Thanks for all your hard work man.

[Subo1977]

what would Cgminer would do, if there are two kernel.cl files in the CGminer directory, and there are no .bin?


excample: phatk120823.cl and phatk120724.cl. wich would be used zu make the *.bin ?

[rav3n_pl]

what would Cgminer would do, if there are two kernel.cl files in the CGminer directory, and there are no .bin?


excample: phatk120823.cl and phatk120724.cl. wich would be used zu make the *.bin ?

You can delete all .bin they will be recreated on start. This is "just" complied .cl

[Subo1977]

what would Cgminer would do, if there are two kernel.cl files in the CGminer directory, and there are no .bin?


excample: phatk120823.cl and phatk120724.cl. wich would be used zu make the *.bin ?

You can delete all .bin they will be recreated on start. This is "just" complied .cl

i do that in batch every restart from cgminer.

It seems cgminer use the newest *.cl

[The00Dustin]

what would Cgminer would do, if there are two kernel.cl files in the CGminer directory, and there are no .bin?


excample: phatk120823.cl and phatk120724.cl. wich would be used zu make the *.bin ?

You can delete all .bin they will be recreated on start. This is "just" complied .cl

i do that in batch every restart from cgminer.

It seems cgminer use the newest *.cl

It uses the CL it was programmed to use.  If you delete that one, it will not use the other.  Same is true for bin files, so if you don't delete them, and you upgrade, but don't rename them, it will still create new ones from the new CL file (or fail if you have deleted it, and possibly fail if you rename the bin files to the new version depending on what has changed).

ETA:  Note that there isn't a new CL version (and hence isn't a new bin version) very often.  Only when mining kernel changes are made.  Typically an older version can be used with renaming because cgminer hasn't changed how it interfaces with them, but it did at least once some number of versions ago.

[os2sam]

what would Cgminer would do, if there are two kernel.cl files in the CGminer directory, and there are no .bin?


excample: phatk120823.cl and phatk120724.cl. wich would be used zu make the *.bin ?

You can delete all .bin they will be recreated on start. This is "just" complied .cl

Yes, you can delete them and they will/should be recreated on next start.

That said I usually create a new directory for each version of CGMiner, just in case I want to roll back to an older version.

If you don't want to do that I would rename the old ones just so that you have a fallback in case CGMiner can't create a new set for some reason.
Sam

[kano]

cut/paste ...

2.7.5
An Xubuntu 11.04 x86_64 executable is in my github downloads called cgminer-2.7.5a
https://github.com/kanoi/cgminer/downloads
(oh and it also works on Fedora 16 and 17)

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

No problems so far on my BFL (my '2xGPU+2xIcarus' is still busy testing HW: code)

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./configure --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt

---

No more windows FPGA binaries needed from me for now, since ckolivas now has cgminer-fpga.exe in his 2.7.5 windows 7zip file

[TheHarbinger]

2.7.5 test update:

Has been running for about 6 hours now and no sign of the -10 intensity bug so far.  This is a good sign, it usually showed up within 30 minutes of CGminer starting previously.

Running one card at intensity 8, and one on dynamic, dynamic card is hooked to a monitor.
Test rig is a WIN7 x64 with 2 5870s not in crossfire, it is a daily use desktop, not a dedicated mining rig.
Connecting to a LAN P2Pool server.

I will let it run for a full 24 hours and do a follow up post.  So far it looks good Con, here's hoping that bug is squashed for good this time.

[Askit2]

So far 2.7.5 has been working for me for 16 hours. No real troubles to report.

Would my high expiry cause a whole work unit worth of work after a LP is recieved on my end to stale (Prev-BLK) on me? I don't mean one share worth I mean 10-15 in a row because of RollNtime. As I understood it at the LP request all my old work that isn't done yet is dumped (Garbage anyways) and the next work started should be from the pool that requested the LP. Did I misunderstand how it works? Using failover of course, I expect load balance could work differently but shouldn't be much.

[-ck]

So far 2.7.5 has been working for me for 16 hours. No real troubles to report.

Would my high expiry cause a whole work unit worth of work after a LP is recieved on my end to stale (Prev-BLK) on me? I don't mean one share worth I mean 10-15 in a row because of RollNtime. As I understood it at the LP request all my old work that isn't done yet is dumped (Garbage anyways) and the next work started should be from the pool that requested the LP. Did I misunderstand how it works? Using failover of course, I expect load balance could work differently but shouldn't be much.

No.

If you get a pause of no accepted shares before longpoll followed by big run of stales after a longpoll that is delays with your pool that is holding off processing the last shares and taking its time to get the longpoll out. I see this with mtred which struggles under the load, but not with other pools.