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

That's odd. I have intensity 8 set in the conf file.
But you're right of course. Manually setting intensity 8 after starting made the paused thread go live again.

I do have a script that uses the API to alter settings on GPU #2 after startup because it will crash on startup if I put the same settings in the conf file. See conf file has missing arguments for #2. For some reason maybe that API tweaking is causing GPU #0 to think it's intensity is dynamic...? Or not. IDK.

1. no

2. because the dyn interval timing means something when only 1 thread is running otherwise they overlap ... if you want high throughput increase the interval

3. it shouldn't...

Some questions about Dynamic Intensity.

1.  Did Dynamic always disable a thread?

2.  Why does it disable a thread?

3.  Why does setting GPU 1 to Dynamic disable a thread on GPU 0?

Thanks,
Sam

Set an intensity

I have a minor problem here that maybe someone knows how to fix up. I'm still using 2.6.1 on Linux with 3x 5830 cards.

I have 6 threads, 3 x2 each gpu. For the last few weeks thread 1 always shows as "paused". I notice on reboot it will log "enabled", "disabled", "enabled" a few times but after it stabilizes the result on the GPU info screen is that Thread 1 is Alive, paused. So it works ok with thread 0 doing all the work but why? Rebooting doesn't fix it. No settings in conf that indicate it should be paused.

Here is the log of startup where this business goes on:
After this it doesn't change and thread 1 shows as:
Any ideas?

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.

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.

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.

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

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

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.

i do that in batch every restart from cgminer.

It seems cgminer use the newest *.cl

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

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 ?

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.

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.

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

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)

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.

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.