kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 02, 2012, 11:27:43 PM |
|
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)
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4228
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 02, 2012, 11:32:08 PM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
nitrox
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 136
Merit: 10
tester
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 02, 2012, 11:33:20 PM |
|
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
Legendary
Offline
Activity: 1713
Merit: 1029
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 12:40:15 AM |
|
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=98222Will provide source upon request. As well, inside the jar are all the .java source files.
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4228
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 12:44:19 AM Last edit: August 03, 2012, 01:35:03 AM by ckolivas |
|
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"
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 02:21:05 AM Last edit: August 03, 2012, 07:47:03 AM by kano |
|
An Xubuntu 11.04 executable in my github downloads called cgminer-2.6.2a of course https://github.com/kanoi/cgminer/downloadsFor 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 02:41:58 AM |
|
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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 02:47:58 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 03:04:43 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 05:17:50 AM |
|
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
|
Donations: 1JVhKjUKSjBd7fPXQJsBs5P3Yphk38AqPr - TIPS the hacks, the hacks, secure your bits!
|
|
|
Vorksholk
Legendary
Offline
Activity: 1713
Merit: 1029
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 05:37:20 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 06:15:00 AM |
|
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
|
Donations: 1JVhKjUKSjBd7fPXQJsBs5P3Yphk38AqPr - TIPS the hacks, the hacks, secure your bits!
|
|
|
rampone
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 339
Merit: 250
dafq is goin on
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 06:25:03 AM |
|
somethings wrong with 2.6.2 and bfls, feels like they run slower somehow, im off to 2.6.1 again
|
http://virwox.com - Bitcoins via CCard, Skrill, paysafe, paypal & SEPA Convert your bitcoin into spendable fiat money in less than 2 days. Poker Players use this method to avoid "unnecessary trouble" with the country they live in ... PM me for details. +1:naz86,b4nana,tinua,smart1986,fhh
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 06:31:05 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 06:47:22 AM |
|
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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
There is no place like 127.0.0.1 In blockchain we trust
|
|
|
420
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 07:42:52 AM |
|
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
|
Donations: 1JVhKjUKSjBd7fPXQJsBs5P3Yphk38AqPr - TIPS the hacks, the hacks, secure your bits!
|
|
|
sharky112065
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 07:48:37 AM |
|
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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) Thank you; made me laugh. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
|
|
|
rav3n_pl
Legendary
Offline
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 12:23:34 PM |
|
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 (OP)
Legendary
Offline
Activity: 4228
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 12:27:01 PM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
rav3n_pl
Legendary
Offline
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2012, 12:33:06 PM |
|
oops, looks like something eat me one core and miner not have enough priority. It works same now ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Sorry! It (miner) is not very cpu hungry (taking about 1-2%), but better to rise it priority to "above normal".
|
|
|
|
|