Has this thread been abandoned ? Is that it....SCRYPT Enabled, take it or leave it ?
Now hang on a sec. I've been busting my balls since the scrypt code started working on the last few releases. There have been spot fires all over the place with unexpected bugs, bfl fuckage and to top it off, jesus fucking haunting my threads. I have spent, and still AM spending, shit loads of time getting this fucking bastard working properly... (long rant snipped). Take scrypt discussion to the main cgminer thread, it's part of it now, but I have to prioritise support. |
|
|
|
So I tried to get the 2.5 SDK installed alongside 12.1 (yet again) and I get nothing but segfaults. Seriously, how do you get both of them installed? Perhaps then you have a few files from different SDKs installed. That's usually how segfaults occur. You'll have to go through and do a cleanup. The newer AMD drivers automatically install the SDK themselves. |
|
|
|
i edit prevision post:
add: Or is it just a side effect, and the end result is the same as the shares was on the previous version. Only DW is too much, because the new methods of work requests?
Do I understand correctly?
Yes, side effect. Shares same. |
|
|
|
after update 2.6.2>2.6.3 , DW numbers greatly increased.
1 rig with 4 phatk kernel have 9-12% DW (before update 5-10%) with int 8, 2 rig witk 3 diablo 1 poclbm kernels have 30-35% DW (before updade 5-10%) with int 9.
1 conf - driver 11.12 ocl 2.5 from 11.11
2 conf - driver 11.12 7970 edition + sdk from 12.4 drivers (SDK 2.6 if not mistaken)
E: The Efficiency defined as number of shares returned / work item ...... dropped in several times
it's ok?
That's the cost of much smoother getwork behaviour. On the flip side, it will have less chance of dips in the hashrate, leak shares to backup pools, have bursts of work requirements and so on. hm, And if I only use a single pool? Version 2.6.2 would be best for me or who use one pool? It will still have smoother comms with the pool even on a single pool. |
|
|
|
after update 2.6.2>2.6.3 , DW numbers greatly increased.
1 rig with 4 phatk kernel have 9-12% DW (before update 5-10%) with int 8, 2 rig witk 3 diablo 1 poclbm kernels have 30-35% DW (before updade 5-10%) with int 9.
1 conf - driver 11.12 ocl 2.5 from 11.11
2 conf - driver 11.12 7970 edition + sdk from 12.4 drivers (SDK 2.6 if not mistaken)
E: The Efficiency defined as number of shares returned / work item ...... dropped in several times
it's ok?
That's the cost of much smoother getwork behaviour. On the flip side, it will have less chance of dips in the hashrate, leak shares to backup pools, have bursts of work requirements and so on. |
|
|
|
Getting this when I try to start 2.6.3. error while loading shared libraries: libOpenCL.so: cannot open shared object file: No such file or directory With my binaries you need to install opencl, usually from AMD, although the NVIDIA or even the Intel one will suffice. This has ALWAYS been the case. http://developer.amd.com/sdks/AMDAPPSDK/downloads/Pages/default.aspx |
|
|
|
|
New version: 2.6.3 - August 5th 2012
Mostly bugfixes but one significant code rewrite
Human readable changelog
The most significant change in this version is a complete rewrite of the queueing mechanism which gets new work from the pools. The code in that section had gotten out of hand and become a "state machine" that was difficult to model its behaviour and occasionally led to stalls during startup and what-not without work and perhaps queued too much work in general. Now it monitors carefully the amount of queued and available work on a pool-by-pool basis and only queues when needed, but tries hard to make sure it doesn't run empty. You will notice the the TQ value now hovers around zero when all is well, and only jumps up transiently, all going well. Hopefully the efficiency is even higher now too. Detection of pool lag should be more accurate now, and less shares should leak to backup pools now as well.
Autodetect of BFL devices now works on windows too, courtesy of code from jesusminer.
Fixed the inability to disable pools from the menu.
Fixed writing of scrypt parameters to the configuration file.
Can set failover-only mode now from the menu during runtime.
No work is done by backup pools in failover-only mode at startup once again.
The API should be able to bind to the port immediately on linux now instead of having to wait 60 seconds as it used to.
Throttling episodes on bitforce devices will now register as HW errors.
Full changelog
- Count likely throttling episodes on bitforce devices as hardware errors.
- Style cleanups.
- Use FTD2XX.DLL on Windows to autodetect BitFORCE SHA256 devices.
- Make pool_disabled the first in the enums == 0, fixing the pool enabled count
which compares if value is not enabled before enabling it.
- Correct writing of scrypt parameters to config file based on command line
parameters only.
- Use different variables for command line specified lookup gap and thread
concurrency to differentiate user defined versus auto chosen values.
- Queue a request on pool switch in case we have no work from the new pool yet.
- Display failover only mode in pool menu and allow it to be toggled live.
- Reinstate check for system queueing lag when the current pool's queue is maxed
out, there is no staged work, and the work is needed now.
- There is no need for pool active testing to be mandatory any more with queue
request changes.
- Fix harmless warnings.
- Check the current staged and global queued as well before queueing requests.
Discard stales before ageing work in the watchdog thread. Queue requests after
discarding and ageing work in watchdog thread. Display accurate global queued in
curses output. Reuse variable in age_work().
- The queueing mechanism has become a complex state machine that is no longer
predictable. Rewrite it from scratch watching only current queues in flight and
staged work available on a pool by pool basis.
- API remove unused warning in non-GPU compile
- api.c in linux allow to open a closed socket in TIME_WAIT
- Queue an extra request whenever staged work drops below mining thread count in
hash_pop.
- Update debian package configs to v2.6.2
|
|
|
|
Just upgraded to 2.6.2.
When I try to disable a pool from the menu it says "cannot disable last pool". All I do is press P and D and get this message, I don't get a chance to select a pool to disable.
Sam
Switch to another pool, then disable. Tried that, per your suggestion, but still no go. Any other suggestions? Thanks, Sam Looks like a new bug, will fix next version, thanks. |
|
|
|
I've been running 2.6.2 for awhile now, and ran into the BFL error again, but it seemed to recover faster than with 2.6.1-9. cgminer version 2.6.2 - Started: [2012-08-03 11:01:01]
--------------------------------------------------------------------------------
(5s):1742.8 (avg):1607.1 Mh/s | Q:1338 A:18444 R:118 HW:0 E:1378% U:22.2/m
TQ: 4 ST: 2 SS: 10 DW: 151 NB: 111 LW: 18514 GF: 106 RF: 23
Connected to http://us2.eclipsemc.com:8337 with LP as user ---
Block: 000000fef54454de78f71d88e1682ac1... Started: [00:50:34]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
BFL 0: 56.8C | 764.5/803.5Mh/s | A:9223 R:54 HW:0 U:11.11/m
BFL 1: 59.3C | 795.5/803.6Mh/s | A:9224 R:64 HW:0 U:11.11/m
--------------------------------------------------------------------------------
[2012-08-04 00:49:49] Accepted 642b0a10.439f01a5 BFL 1 pool 0
[2012-08-04 00:49:49] Accepted 99bc51ae.af7b0fb2 BFL 0 pool 0
[2012-08-04 00:49:55] Accepted c1141456.8d3bc2e8 BFL 1 pool 0
[2012-08-04 00:49:55] Accepted af80a22c.8ede0eb0 BFL 0 pool 0
[2012-08-04 00:50:00] Accepted 2051832a.8ec1030b BFL 1 pool 0
[2012-08-04 00:50:11] Accepted 2348c318.bfdc7136 BFL 1 pool 0
[2012-08-04 00:50:21] Accepted 1437218f.aa9cdb6a BFL 1 pool 0
[2012-08-04 00:50:21] BFL0: Error: Get temp returned empty string/timed out
[2012-08-04 00:50:26] BFL0: Error: Get result reports: Temperature (celcius): 57.8
[2012-08-04 00:50:26] Accepted 099e869b.522a22ef BFL 1 pool 0
[2012-08-04 00:50:26] Accepted cad1b030.cb2821a3 BFL 1 pool 0
[2012-08-04 00:50:32] Accepted 208e9cf7.a2ce42d5 BFL 0 pool 0
[2012-08-04 00:50:32] Accepted 95a0b59c.aa2bef25 BFL 1 pool 0
[2012-08-04 00:50:34] LONGPOLL from pool 0 detected new block
[2012-08-04 00:50:34] Pool 0 not providing work fast enough
[2012-08-04 00:50:41] Accepted a65f79cb.fd521ce9 BFL 1 pool 0
[2012-08-04 00:50:41] Accepted e3598f3f.79c13014 BFL 1 pool 0
That's great. It means there was perhaps a single throttling incident and the code changes I made allowed it to recover fairly quickly. |
|
|
|
2.6.1 vs 2.6.2 on same settings:
.1 = ~150MH
.2 = ~100MH
copied config file and running from same command line options.
Win7 64
Rolling back to 2.6.1 for now, something is changed in intesity?
Nope, nothing changed in that code. |
|
|
|
|
Whenever you change drivers or SDK with cgminer, if you are to actually get different performance, you MUST delete any .bin files that cgminer has generated from the previously installed drivers/sdk combo.
|
|
|
|
|
New release: 2.6.2, August 3rd 2012
Remember, 2.6.x so far is a certified disaster area for BFL.
Random bugfixes only:
Human readable changelog
BFL devices that would stop working have had numerous workarounds added.
GPUs that would restart quietly on 2.5.0 would go dead on 2.6.1, which should be fixed.
With many pools in a configuration and failover-only, there could have been lag on startup waiting for work.
Don't disable BFL devices if the temperature for cutoff is inadvertently set to 0.
Full changelog
- Scrypt mining does not support block testing yet so don't try to print it.
- Clear the bitforce buffer whenever we get an unexpected result as it has
likely throttled and we are getting cached responses out of order, and use the
temperature monitoring as a kind of watchdog to flush unexpected results.
- It is not critical getting the temperature response in bitforce so don't
mandatorily wait on the mutex lock.
- Check there is a cutoff temp actually set in bitforce before using it as a cut
off value otherwise it may think it's set to zero degrees.
- We dropped the temporary stopping of curl recruiting on submit_fail by
mistake, reinstate it.
- Make threads report in either side of the scanhash function in case we miss
reporting in when restarting work.
- Don't make mandatory work and its clones last forever.
- Make test work for pool_active mandatory work items to smooth out staged work
counts when in failover-only mode.
- Add debugging output when work is found stale as to why.
- Print the 3 parameters that are passed to applog for a debug line in
bitforce.c
- Clear bitforce buffer on init as previously.
- Add some headroom to the number of curls available per pool to allow for
longpoll and sendwork curls.
- Revert "Revert "Change BFL driver thread initialising to a constant 100ms
delay between devices instead of a random arrangement.""
- Revert "Remove bitforce_thread_init"
- Show the correct base units on GPU summary.
- Differentiate between the send return value being a bool and the get return
value when managing them in bitforce scanhash.
- Revert "bitforce: Skip out of sending work if work restart requested"
|
|
|
|
|
Bear in mind it always times out after 100ms anyway if you hadn't specified bitforce: in 2.5.0 so this is not the problem we are facing, although I believe we have a working theory for what's going wrong, so I'll hack together a simple workaround that hopefully fixes it.
|
|
|
|
Having a small problem with cgminer with linux, first time using cgminer with linux so bear with me. $ DISPLAY=:0 ./cgminer -n
[2012-08-02 05:18:45] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2012-08-02 05:18:45] CL Platform 0 name: AMD Accelerated Parallel Processing
[2012-08-02 05:18:45] CL Platform 0 version: OpenCL 1.2 AMD-APP (923.1)
[2012-08-02 05:18:45] Platform 0 devices: 1
[2012-08-02 05:18:45] 0 Barts
[2012-08-02 05:18:45] Failed to ADL_Adapter_ID_Get. Error -10
[2012-08-02 05:18:45] Failed to ADL_Adapter_ID_Get. Error -10
[2012-08-02 05:18:45] GPU 0 AMD Radeon HD 6800 Series hardware monitoring enabled
[2012-08-02 05:18:45] 1 GPU devices max detected
'Dat error. And my 5770 is missing, my 6850 is fine. I used DISPLAY=:0 just like the readme said but it still doesn't show up. $ sudo aticonfig --list-ad
* 0. 01:00.0 AMD Radeon HD 6800 Series
1. 02:00.0 ATI Radeon HD 5700 Series
* - Default adapter
Catalyst 12.6 and SDK 2.7 Bump anyone? Did you configure all the devices to begin with? Do this to reset it so they all work and restart: sudo aticonfig -f --adapter=all --initial |
|
|
|
Could the 'sickness' simply be a low value output in MH/s, causing CGMiner to panic ? No, but that bug WAS in 2.6. 0 which was the main reason for 2.6. 1We have found that this problem you describe happens with driver 12.6 when it doesn't happen with the earlier drivers which were better (specifically the so-called 8.921 release which was the first beta driver supporting 7970s). |
|
|
|
I've got cgminer 2.6.1.9 crash today, it just quit. So, I'm back to 2.5.0 for now  . On the other hand, 2.5.0 is giving me U around 6 more, which is ~0.8% of my total hash rate. I hereby declare 2.6.x a BFL disaster area. |
|
|
|
cgminer dont work with BFL singles count > 13
crash
windows 7 64
Yep, I can confirm this bug as well. Yep good old pdcurses on windows... sigh. It will work in -T mode only with that many devices on windows. EDIT: just to be sure - did it work with that many devices in 2.5.0? |
|
|
|
Were you on windows 2.6.1 or the cgminer.exe from the test directory?
It was 2.6.1 that I compiled myself for windows from source, with only bitforce support enabled (not the cgminer.exe from the test directory). Okay so that doesn't include the rollback that's in the test directory which fixes a known bug. More information is always helpful, thanks. |
|
|
|
I had those errors in 2.6.1 happen again, so I just down-graded to 2.5.0 for now.
Were you on windows 2.6.1 or the cgminer.exe from the test directory? |
|
|
|
|
Show Posts
