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

[kano]

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.

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)

[1714049235]

1714049235

[1714049235]

1714049235

[-ck]

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.

[nitrox]

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

[Vorksholk]

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://bitcointalk.org/index.php?topic=98222

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

[-ck]

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"

[kano]

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

[dave3]

As you can see from the log, it is the "Comms error" that actually fixes it.
cgminer flushes the data when it gets a comms error.

Looks like the temperature command timeout is the issue.
It may be that during a throttle, the device doesn't respond and thus the temperature command can wait up to even 10 seconds or more before it will reply (e.g. a throttle to half speed)

Hmm these devices are so badly designed it's not funny (that is by BFL design - to hang the device while it throttles)
I'm guessing, but it looks to be the problem the code needs to handle ...

... allowing it to hang for 10 seconds or more and cgminer must think that is OK when you ask for the temperature ...
That code solution seems so bad .......

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."

[kano]

As you can see from the log, it is the "Comms error" that actually fixes it.
cgminer flushes the data when it gets a comms error.

Looks like the temperature command timeout is the issue.
It may be that during a throttle, the device doesn't respond and thus the temperature command can wait up to even 10 seconds or more before it will reply (e.g. a throttle to half speed)

Hmm these devices are so badly designed it's not funny (that is by BFL design - to hang the device while it throttles)
I'm guessing, but it looks to be the problem the code needs to handle ...

... allowing it to hang for 10 seconds or more and cgminer must think that is OK when you ask for the temperature ...
That code solution seems so bad .......

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."

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

[dave3]

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

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

[420]

What does the intensity flag mean

is lower more intense? higher more intense? doesn't seem right as 8, 9 seem more mhash, lower or higher intensity gave me lower mhash

[Vorksholk]

What does the intensity flag mean

is lower more intense? higher more intense? doesn't seem right as 8, 9 seem more mhash, lower or higher intensity gave me lower mhash

Higher intensity means higher hash rate in general. Intensity is basically how aggressive the miner is on the card.

[420]

What does the intensity flag mean

is lower more intense? higher more intense? doesn't seem right as 8, 9 seem more mhash, lower or higher intensity gave me lower mhash

Higher intensity means higher hash rate in general. Intensity is basically how aggressive the miner is on the card.

im getting driver crash at only 750mhz 1.085 v, 725/1.05v is the stock 5970

[rampone]

somethings wrong with 2.6.2 and bfls, feels like they run slower somehow, im off to 2.6.1 again

[kano]

somethings wrong with 2.6.2 and bfls, feels like they run slower somehow, im off to 2.6.1 again

What did you feel that with ...

[BlackPrapor]

somethings wrong with 2.6.2 and bfls, feels like they run slower somehow, im off to 2.6.1 again

What did you feel that with ...

I believe that place is called buttocks 

[420]

I'm assuming the version, 2.3.1, 2.6.1, 2.6.2 has no bearing on hashrate for my 5000 series (3x5970's)

thats' what it seems through my limited testing of just opening, watching the hash sort of stabilize within 10 minutes

but jumps up and down sometimes, 1900->2000, to 2122. 100mhash jumps, now just 1995 to 222 then to 2063, 1800, 1750, not switching pools or anything
not running anything else on this PC, not using dynamic clock change, only fan change to desired temperature

[sharky112065]

somethings wrong with 2.6.2 and bfls, feels like they run slower somehow, im off to 2.6.1 again

What did you feel that with ...

I believe that place is called buttocks 

Thank you; made me laugh. 

[rav3n_pl]

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?

[-ck]

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.

[rav3n_pl]

oops, looks like something eat me one core and miner not have enough priority.
It works same now
Sorry!

It (miner) is not very cpu hungry (taking about 1-2%), but better to rise it priority to "above normal".