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

Thanks.  I just compiled 2.6.2 and it's running now.

Hmm, then in your case, that sounds like an OS issue delaying the BFL->cgminer reply while it handles the switch
So that's a 'how long is a piece of string' problem regarding timeouts since the OS could decide for whatever memory/CPU/Disk reason to continue to delay it for seconds or even more ...

Anyway, try 2.6.2 and see if it still happens

I suppose it's possible it's throttling, but I doubt it.  It's been rainy and cool here lately.

I've got UltraVNC running on the cgminer system since it's in another room, and I seem to notice it just as I switch over to the UltraVNC client window (which was already running) as it "wakes up."

An Xubuntu 11.04 executable in my github downloads called cgminer-2.6.2a of course
https://github.com/kanoi/cgminer/downloads

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 GPU or 2xIcarus
Note the BFL comment above by ckolivas
For me it works perfectly after a 60 second hiccup at the start.

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

Edit: and I have also added a WinXP cgminer-2.6.2a.exe

This ONLY has BFL + ICA (as below) thus it doesn't need a computer with OpenCL on it
It doesn't automatically identify the BFL or ICA you need to specify them with -S
CFLAGS="-O2 -W -Wall" ./configure --enable-icarus --enable-bitforce

You will most likely also need the windowsdlls.zip file there in my downloads since my *.dll might be slightly different to ckolivas
Last time I made a windows exe for someone they needed my versions of the *.dll so you may need them also

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"

If anyone is having trouble getting cgminer to mine Litecoins, I put together a program for Windows users that generates the .bat file for you, all you need to know is your GPU model (5970, 6990M) and pool info, my program will find the shader rating for you.

https://bitcointalksearch.org/topic/project-development-cgeasy-100-generate-cgminer-config-for-ltc-mining-easy-98222

Will provide source upon request. As well, inside the jar are all the .java source files.

HD7950OC
something is wrong,
BTC with no problems ~ 530MH/s
but can not set it up to digging LTC.
winsows 7 x64, driver 12.6, SDK 2.7
now i go to bed, after 3 hours i must do to work ....
(+_+)

http://i45.tinypic.com/29aseft.jpg

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.

My 100ms comes from the fact that you cannot wait less than that in linux with the current (original) method used to talk to the BFL.
Sending work to the BFL will take a bit over 4ms
The reply will be less than that since it is less data.
The Icarus W value is a bit over 6ms
All up we are well under 20ms - so even if the BFL takes a ridiculous 80ms to 'decide' to reply we are still under 100ms
I also ran it for many days with my problematic BFL with the maximum speed bitstream and never got a timeout
If the device really does come close to 100ms to return a reply to anything that is ready to reply, BFL should be shot.
... 100ms = 83M hashes (on the standard bitstream)

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

If I had the time/could be bothered I'd put timers around each of the send/receive and find the max/min/avg values. But that ain't gonna happen in the next week or so.
3s is arbitary. So is 3s for the watchdog, 5s for the stats interval, and any number of other time selections cgminer is littered with. Where did your 100ms come from? Careful analysis?
3s was just a suggestion, and no it won't catch everything. No value apart from infinite will, then we run into other troubles. But we can try mitigating problems, no?

Anway, 2.5.0 is running rock solid for me, so I'm sticking to that for now.

Bump anyone?

Yes the sync problem is clearly another fun bit of BFL ...

Nope, 1s or 3s is arbitrary and does not solve the problem (i.e. it may occur less but not solve it)
The issue also appears to be that reading the temp during work can hang until the throttle completes
... and a throttle can be ... more than 3s easily enough ...
Don't pick random numbers, give a specific reason for the numbers.

(Edit: yes I saw Jesus' solution, set it to 1s and pretend that fixes it)

Edit2: anyway the problem is all to do with dealing with throttling but also to allow handling an error also.
Throttling is rare for most people and errors are even rarer.
But as soon as you get them, it suddenly becomes an issue of how to decide which it is - since you can't completely ignore real errors to handle the throttling (e.g. if the BFL stops and needs to be power cycled you don't want the rig to hang if you have more than one BFL)

helped

may be need throttles write as "Hardware error counter" and restart mining.

CGMiner 2.6.1 crashed for the second time now after changing the pool (via API)... This has never happened before. I forgot to enable debug output, so I cannot supply more information atm.

I'm wondering if this could be related to the fixes in 2.6 regarding the "flooding the primary pool with requests"-bug.

In that case cgminer needed to wait 1s for the temp result to return.
Instead it timed out, leaving the 'get temp' command in the BFL input buffer
Next the get results command was sent to the BFL and the repsonse read... which was from the previous 'get temp' command.
From then on all the responses were out of sync until the read buffer was cleared.

I'd suggest 2 things:
1) Increase the timeout to, say, 3s.
2) Have command re-read the port if they get an unxpected reply. Maybe re-read up to 3 times before giving up.

I also have one Single that has been giving me issues like this. I had it running on 2.6.1 for 4 days, and it was until today that it started giving me issues. I reverted to 2.5.0 and it still gives me the occasional error, but as pointed above, it's mainly from the throttling. After it throttles and CGMiner 2.5.0 stops whining with the errors, it then starts working again.

If you enable the API, the API command 'devdetails' will tell you which port/device each FPGA is on

From windows, the easiest way to do that is firstly to have --api-listen on the command line or
"api-listen" : true,
in your config file
and then from a command prompt in the cgminer directory type:
java API devdetails
(of course you need java installed - go to www.java.com if you don't)