Author

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

legendary
Activity: 1795
Merit: 1208
This is not OK.
Also, I started adding the temp to the log when a unit throttles...
I'm thinking about adding code with slows the unit a bit as it reaches it's individual throttle temp. Like waiting 500ms before sending new work or something. Maybe. Dunno.
legendary
Activity: 1795
Merit: 1208
This is not OK.
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.

I've done that, get the following:

ID: BFL0   Dev Max: 0.024049   Dev Min: 0.000366   Dev Av: 0.009301
ID: BFL1   Dev Max: 15.335547   Dev Min: 0.000389   Dev Av: 0.012155
ID: BFL2   Dev Max: 15.335506   Dev Min: 3.8E-5   Dev Av: 0.011484
ID: BFL3   Dev Max: 15.33545   Dev Min: 0.00036   Dev Av: 0.027547
ID: BFL4   Dev Max: 0.02345   Dev Min: 0.00036   Dev Av: 0.009153
ID: BFL5   Dev Max: 0.023163   Dev Min: 0.000404   Dev Av: 0.008941

So I put get times immedately before and after the serial port read function inside BFgets.
Dev max is (surpisingly) the max time a read took
Dev min is (surpisingly) the min time a read took
Dev av is (surpisingly) the overall average, that is all the read times summed, then divided my the read count.

So it's pretty apparent that when the single throttles, comms just stop.
legendary
Activity: 952
Merit: 1000
You create a .bat file with a loop that runs CGMiner, and when CGMiner closes itself after 5000 shares, the loop restarts CGMiner. Lather, rinse, repeat.

I would be careful about this. You may want to add a TIMEOUT or use the ping technique to make sure threads are closed, and that the OS has released handles, otherwise the new cgminer instance won't properly grab them. 5 or 10 seconds should do the trick.

When I did this, I added a 30 delay after startup to start, and a timeout of 10 second in the loop.
newbie
Activity: 63
Merit: 0
You create a .bat file with a loop that runs CGMiner, and when CGMiner closes itself after 5000 shares, the loop restarts CGMiner. Lather, rinse, repeat.

I would be careful about this. You may want to add a TIMEOUT or use the ping technique to make sure threads are closed, and that the OS has released handles, otherwise the new cgminer instance won't properly grab them. 5 or 10 seconds should do the trick.
legendary
Activity: 952
Merit: 1000
is really annoying for the 7 days bug !

i wonder if possible to add auto restart feature for windows CGminer

so every 7 days it will auto restart itself !


well you should be able to with task schedule

You can also use:
--shares       Quit after mining N shares (default: unlimited)

in a loop

i dont know how to use window scheduler and

--shares       Quit after mining N shares (default: unlimited) 

you mean the miner will quit after mining example : 5000 share and it will auto restart and mining again ?


You create a .bat file with a loop that runs CGMiner, and when CGMiner closes itself after 5000 shares, the loop restarts CGMiner. Lather, rinse, repeat.
member
Activity: 99
Merit: 10
MMM EXTRA - THE RIGHT STEP TOWARDS THE GOAL
is really annoying for the 7 days bug !

i wonder if possible to add auto restart feature for windows CGminer

so every 7 days it will auto restart itself !


well you should be able to with task schedule

You can also use:
--shares       Quit after mining N shares (default: unlimited)

in a loop

i dont know how to use window scheduler and

--shares       Quit after mining N shares (default: unlimited) 

you mean the miner will quit after mining example : 5000 share and it will auto restart and mining again ?
legendary
Activity: 1361
Merit: 1003
Don`t panic! Organize!
So, is it safe to use 2.6.4 for ltc mining now? I'm on solo and one message I received among the "new block detected on network" was "rejected 040ccc8e blabla Gpu1". Do I have to worry? Should I use an older version? Total noob to cgminer. Used cgeasy to configure (Thanks! great help) to set everything for solo ltc mining.
It is quite normal to get reject just after new block and/or longpool on any version.
legendary
Activity: 1526
Merit: 1001
So, is it safe to use 2.6.4 for ltc mining now? I'm on solo and one message I received among the "new block detected on network" was "rejected 040ccc8e blabla Gpu1". Do I have to worry? Should I use an older version? Total noob to cgminer. Used cgeasy to configure (Thanks! great help) to set everything for solo ltc mining.

Edit: Thanks Rav3n ------------->
hero member
Activity: 988
Merit: 1000
is really annoying for the 7 days bug !

i wonder if possible to add auto restart feature for windows CGminer

so every 7 days it will auto restart itself !


well you should be able to with task schedule

You can also use:
--shares       Quit after mining N shares (default: unlimited)

in a loop
420
hero member
Activity: 756
Merit: 500
is really annoying for the 7 days bug !

i wonder if possible to add auto restart feature for windows CGminer

so every 7 days it will auto restart itself !


well you should be able to with task schedule
member
Activity: 99
Merit: 10
MMM EXTRA - THE RIGHT STEP TOWARDS THE GOAL
is really annoying for the 7 days bug !

i wonder if possible to add auto restart feature for windows CGminer

so every 7 days it will auto restart itself !
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Thanks. It looks like the code was up to date, but I built it before pulling the version number change on the laptop, sorry about that. Reuploaded packages.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
2.6.4 still shows 2.6.3 in the display.
One of my binaries? Which one?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
The crash in libcurl was tracked down with the help of Kano. Interestingly this bug was always there but because previous versions queued so much extra, the number of "curls" in existence never dropped low enough to hit the bug.
Of course, despite being credited to Kano, this was debugged by me, and actually originally fixed in BFGMiner 2.6.3:
Code:
commit 1946c806922a66935856c32b6ca12d10db033b07
Author: Luke Dashjr
Date:   Sun Aug 5 22:50:24 2012 +0000

    Bugfix: Check list_empty in pop_curl_entry after condition wait
    
    pthread_cond_signal wakes AT LEAST one thread, so it's possible the freed up curl has already been taken
lulz - it was the one you copied:
https://github.com/ckolivas/cgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
to here:
https://github.com/luke-jr/bfgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
(see the same commit numbers ...)
Is this the first time you expressed your absolute ignorance of how git works in public?
...
Hmm, when was the last one ... oh yeah I remember ... about 2 weeks ago ...
"I'm not a git export" ... Cheesy
https://bitcointalksearch.org/topic/m.1055547

So you fixed it and then applied ckolivas fix also?
Doubly fixed now in your miner Smiley Twice as fixed Smiley Good for you Smiley Be happy Smiley
legendary
Activity: 2576
Merit: 1186
The crash in libcurl was tracked down with the help of Kano. Interestingly this bug was always there but because previous versions queued so much extra, the number of "curls" in existence never dropped low enough to hit the bug.
Of course, despite being credited to Kano, this was debugged by me, and actually originally fixed in BFGMiner 2.6.3:
Code:
commit 1946c806922a66935856c32b6ca12d10db033b07
Author: Luke Dashjr
Date:   Sun Aug 5 22:50:24 2012 +0000

    Bugfix: Check list_empty in pop_curl_entry after condition wait
    
    pthread_cond_signal wakes AT LEAST one thread, so it's possible the freed up curl has already been taken
lulz - it was the one you copied:
https://github.com/ckolivas/cgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
to here:
https://github.com/luke-jr/bfgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
(see the same commit numbers ...)
Is this the first time you expressed your absolute ignorance of how git works in public?

For the sake of others who aren't programmers and have an obviously good reason to not understand how git works: Every commit in cgminer, including cgminer's master branch, also exists in bfgminer's repository when I do general "tree" merges for any other changes made to cgminer. What is canonical is the main bfgminer branch, is the chain of "first parents". Gitorious has a nice graph view of the tree where you can clearly see the canonical bfgminer branch (left-most), the cgminer branch (2nd left-most), and other feature/bugfix branches being merged in. You can also use your browser's find-in-page feature to locate 1946c80 (the original fix in BFGMiner 2.6.3) and c7bcad (the later cgminer duplication-of-effort).
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
The crash in libcurl was tracked down with the help of Kano. Interestingly this bug was always there but because previous versions queued so much extra, the number of "curls" in existence never dropped low enough to hit the bug.
Of course, despite being credited to Kano, this was debugged by me, and actually originally fixed in BFGMiner 2.6.3:
Code:
commit 1946c806922a66935856c32b6ca12d10db033b07
Author: Luke Dashjr
Date:   Sun Aug 5 22:50:24 2012 +0000

    Bugfix: Check list_empty in pop_curl_entry after condition wait
    
    pthread_cond_signal wakes AT LEAST one thread, so it's possible the freed up curl has already been taken
lulz - it was the one you copied:
https://github.com/ckolivas/cgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
to here:
https://github.com/luke-jr/bfgminer/commit/c7bcad653b79ee54429aec4964f4aa80e49db1d1
(see the same commit numbers ...)
member
Activity: 136
Merit: 10
tester
REPORT :
windows 7 x64
driver 12.6
SDK 12.7
cgminer 2.6.4 - crash several times
--------------------------------------------------------------------------------
Description:
Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x502101d7
Faulting module name: aticaldd.dll, version: 6.14.10.1741, time stamp: 0x4fd61f98
Exception code: 0xc0000005
Fault offset: 0x0003b678
Faulting process id: 0xe7c
Faulting application start time: 0x01cd74abd6926380
Faulting application path: D:\mining\cgminer\cgminer.exe
Faulting module path: C:\Windows\system32\aticaldd.dll
Report Id: 3e1c18e0-e0b6-11e1-8745-001d60c3d47b
--------------------------------------------------------------------------------
back to cgminer 2.6.2 - stable working
hero member
Activity: 591
Merit: 500
New release - 2.6.4, 7th August 2012
Does this one still require that stupid nonexistent file?
hero member
Activity: 481
Merit: 500
2.6.4 still shows 2.6.3 in the display.
Jump to: