Smartcoin Linux mining administration. [MULTI-MACHINE SUPPORT NOW IN!]

[jondecker76]

I am running on r455(experimental), updated through the internal update tool.
I am running smartcoin for several hours before receiving this error:

Maximum number of clients reached

I am not sure what happened. This happens on two of my rigs at different time.

Thats an Xlib error. X only allows for a maximum of 255 clients.
Its cause can be just about anything, from custom temperature monitoring scripts, certain browsers and even the gnome screensaver.  Do a google search for "Maximum number of clients reached" - its pretty common and there is a ton of information on how to troubleshoot the problem.
Personally, I would start with the simple things, such as disabling the screen saver, do a reboot then see what happens from there.

Let me know what you find out!

[plantucha]

Update r455(experimental) available:
- grep errors are suppressed
- Fixed a small bug that resets the failover counters on smartcoin restart

sensitivity still too high for me.
I have to mine on manual profile with failover every 2-3 hours miners killed => loosing more with failover

it looks like everybody has different threshold, can we set some number in settings or turn it off?
or use different algorithm?
for example:
if it detect locked GPU check again in 5 minutes and again in another 5 minutes
if all 3 checks are positive reboot PC.

also option - just kill smartcoin or reboot PC will be nice.
Because just kill smartcoin only stops not locked GPUs working.
while reboot will unlock locked GPU and autostart mining again.

[jondecker76]

I checked the queries being executed by RunSQL and in my case it's a total of 35 queries per refresh (failover profile with 3 workers), 14 of which are queries fetching donation_start and donation_time from the settings table. Like I mentioned earlier, I have very little experience with shell scripting, but this sounds like it should be easy to optimize. It appears DonationActive is called multiple times per refresh so couldn't you just call it once at the start of smartcoin_ops.sh and store the return value in a global variable?

You could also JOIN the device table into the query at the end of GenCurrentProfile and include device.name in the result. That would mean you could get rid of the "SELECT name FROM device WHERE pk_device=$device;" query in ShowStatus. That's one less query per worker per refresh.

I'm sure there are other optimizations that could be done. This is just based on a 20 minute browse of the source code.

Regardless, the error checking you added to RunSQL seems sane. I would probably add a short delay (0.1 seconds perhaps) in the loop so that if the database is locked, it has time to be released before the next attempt is made.

Just my 2 cents.

PS. I hope you had a great time at Cedar Point. I wish there was something of that scale here in Sweden

Did you get a change to look at this? Doing just the two optimizations I mentioned above would in my case almost halve the number of queries being executed every refresh.

Yeah, at some point I will look into optimization, but not until all the planned features are in (optimization is almost always the last step in the development cycle). Unfortunately, its not a clean and easy thing to do in bash (It'll get messy with a bunch of global variables) - but either way, at the moment we aren't even coming close to it becoming a bottleneck at this point. After the latest changes are tested and stable, and I get multi machine support in, then I'll start looking into making optimizations.

[jondecker76]

Update r455(experimental) available:
- grep errors are suppressed
- Fixed a small bug that resets the failover counters on smartcoin restart

sensitivity still too high for me.
I have to mine on manual profile with failover every 2-3 hours miners killed => loosing more with failover

it looks like everybody has different threshold, can we set some number in settings or turn it off?
or use different algorithm?
for example:
if it detect locked GPU check again in 5 minutes and again in another 5 minutes
if all 3 checks are positive reboot PC.

also option - just kill smartcoin or reboot PC will be nice.
Because just kill smartcoin only stops not locked GPUs working.
while reboot will unlock locked GPU and autostart mining again.

I can't reproduce anything locally...
Can you give me more information on whats happening?  You mention both the failover system and the lockup detection, but I'm not sure which one you are talking about.  They are 2 separate independent systems (I.e. the lockup system runs no matter which profile is selected, and the failover system only runs when the failover profile is active).  Are you sure you don't have a locked up GPU?  I couldn't imagine a miner running with absolutely no change in its output for 5 minutes straight. 
Also, the new failover will trip a fail condition if stales go over 10% - do you know if this may be the case also?
Is there anything in the logs that may also give a clue?
Perhaps watching the miner output directly (screen -r miner) will give a clue as well - if the miner output sits there with absolutely no change, that pretty much means a locked GPU

[plantucha]

Update r455(experimental) available:
- grep errors are suppressed
- Fixed a small bug that resets the failover counters on smartcoin restart

sensitivity still too high for me.
I have to mine on manual profile with failover every 2-3 hours miners killed => loosing more with failover

it looks like everybody has different threshold, can we set some number in settings or turn it off?
or use different algorithm?
for example:
if it detect locked GPU check again in 5 minutes and again in another 5 minutes
if all 3 checks are positive reboot PC.

also option - just kill smartcoin or reboot PC will be nice.
Because just kill smartcoin only stops not locked GPUs working.
while reboot will unlock locked GPU and autostart mining again.

I can't reproduce anything locally...
Can you give me more information on whats happening?  You mention both the failover system and the lockup detection, but I'm not sure which one you are talking about.  They are 2 separate independent systems (I.e. the lockup system runs no matter which profile is selected, and the failover system only runs when the failover profile is active).  Are you sure you don't have a locked up GPU?  I couldn't imagine a miner running with absolutely no change in its output for 5 minutes straight. 
Also, the new failover will trip a fail condition if stales go over 10% - do you know if this may be the case also?
Is there anything in the logs that may also give a clue?
Perhaps watching the miner output directly (screen -r miner) will give a clue as well - if the miner output sits there with absolutely no change, that pretty much means a locked GPU

manual profile= smartcoin off , running own script
failover was working fine
lockup detection killing miners 2-3 hours    (too sensitive)
rejection rate 0.4%
nothing in logs: just generic   . kiling miners....overclocking...
GPU not locked. it was only once, now I'm making sure it is not.


 I couldn't imagine a miner running with absolutely no change in its output for 5 minutes straight. 

better example what I mean: 

(now - don't LOL yourself to death, this is my first pseudo-code in my life)

start
A=0
detect lockup routine                                 (whatewer formula you are using)
if lockup detected A=A+1                         
If lockup NOT detected go to start             
wait 5 min
detect lockup routine
if lockup detected A=A+1
If lockup NOT detected go to start
wait 5 min
detect lockup routine
if lockup detected A=A+1
If lockup NOT detected go to start
if A=3  then reboot PC                          (lockup is 3x positive in 15 min = it is probably really GPU locked) 
end


testing just once: there will be higher chance false positive or negatives even your formula will be supersmart
only what can happend if it is really GPU locked then will be locked 15 minutes before pc reboots

(5 min is just example, but in case of failover GPUs down, higher rejection..etc) it take 2-3min to system stabilize, so Failover will be not interfering with Lockup detection.

or now maybe even better easier version :
 if is failover starts, turn off lockup detection for 5 min

[jondecker76]

Update r455(experimental) available:
- grep errors are suppressed
- Fixed a small bug that resets the failover counters on smartcoin restart

sensitivity still too high for me.
I have to mine on manual profile with failover every 2-3 hours miners killed => loosing more with failover

it looks like everybody has different threshold, can we set some number in settings or turn it off?
or use different algorithm?
for example:
if it detect locked GPU check again in 5 minutes and again in another 5 minutes
if all 3 checks are positive reboot PC.

also option - just kill smartcoin or reboot PC will be nice.
Because just kill smartcoin only stops not locked GPUs working.
while reboot will unlock locked GPU and autostart mining again.

I can't reproduce anything locally...
Can you give me more information on whats happening?  You mention both the failover system and the lockup detection, but I'm not sure which one you are talking about.  They are 2 separate independent systems (I.e. the lockup system runs no matter which profile is selected, and the failover system only runs when the failover profile is active).  Are you sure you don't have a locked up GPU?  I couldn't imagine a miner running with absolutely no change in its output for 5 minutes straight. 
Also, the new failover will trip a fail condition if stales go over 10% - do you know if this may be the case also?
Is there anything in the logs that may also give a clue?
Perhaps watching the miner output directly (screen -r miner) will give a clue as well - if the miner output sits there with absolutely no change, that pretty much means a locked GPU

manual profile= smartcoin off , running own script
failover was working fine
lockup detection killing miners 2-3 hours    (too sensitive)
rejection rate 0.4%
nothing in logs: just generic   . kiling miners....overclocking...
GPU not locked. it was only once, now I'm making sure it is not.


 I couldn't imagine a miner running with absolutely no change in its output for 5 minutes straight. 

better example what I mean: 

(now - don't LOL yourself to death, this is my first pseudo-code in my life)

start
A=0
detect lockup routine                                 (whatewer formula you are using)
if lockup detected A=A+1                         
If lockup NOT detected go to start             
wait 5 min
detect lockup routine
if lockup detected A=A+1
If lockup NOT detected go to start
wait 5 min
detect lockup routine
if lockup detected A=A+1
If lockup NOT detected go to start
if A=3  then reboot PC                          (lockup is 3x positive in 15 min = it is probably really GPU locked) 
end


testing just once: there will be higher chance false positive or negatives even your formula will be supersmart
only what can happend if it is really GPU locked then will be locked 15 minutes before pc reboots

(5 min is just example, but in case of failover GPUs down, higher rejection..etc) it take 2-3min to system stabilize, so Failover will be not interfering with Lockup detection.

or now maybe even better easier version :
 if is failover starts, turn off lockup detection for 5 min

Actually, the lockup detection is super simple, in pseudo: (keep in mind each iteration is 5-8 seconds)

Code:

if(miner_output_last_iteration == miner_output_this_iteration)
     counter=counter+1
else
     counter=0
endif
if(counter>50)
     # card is locked
     exit
endif

Also consider that the "miner_output" is what is viewable in that miners screen tab - including the hash rate, accepted/rejected counters, and even the messages such accepted/rejected messages, new work messages, connection messages, etc) - so 5 minutes of absolutely no change in output is a very very long time.  Also realize, that in the case of failover or profile change, the miner output does change as far as the lockup detection goes, so the counter is reset - giving 5 minutes for things to stabilize already. Did you watch the miner screen instances to verify that they are not hung at all?  How are you making verifying your GPU isn't locked?  If its taking 2-3 hours, its definitely not  sensitivity issue.


Also, I'm still confused as to what you are saying is happening. You mention manual profile, and failover - which one?  I guess what I need to know is:
- What profile are you running when this happens
- Are you saying that when a true failover condition happens, that its being detected as a lockup condition 5 minutes later? (in fact, I can see where this can happen, as the failed instance continues to run so it can see when it "comes back up"). If this is the case, I think I see a solution

[jaebird]

@jondecker76,

I've been mining now for quite some time with this setup and it is working great. I like where you are going with the card lockup detection. Is the plan for it to call a script on lockup to allow us to decide what we want to do, ie Reboot or exit smartcoin?

Also, I use openvpn and connectbot on my android phone to monitor/admin miner "boxes" (I say boxes figuratively since there are no pc cases involved I'm wondering if you can detect a screen size of 60x22 or smaller and abbreviate the output so it does not line wrap. For example experimental = exp, Accepted = Acc, Rejected = Rej. My screen size and my eyes make 60x22 a good size to see text but the line wraps mess up the nice formatting.

Thanks again.

jaebird

[jondecker76]

Update r456(Experimental) available
- Fixes false lockup detection on failovers.  What was happening, is when a failover event happens, all previous failed profiles continue to run along with the new ones that fall into the list.  On the failed profiles, every now and then the miner would output a message such as "Could not connect, will retry...". After a while, the entire screen would be filled with this message, and even though the message is pushed out again at regular intervals, the screen appears to never change, and triggers the lockup detection.  This fix works by enabling lockup detection only on instances that are not part of a down profile (lockup detection will still work however, as there will still be a failover profile that is working running at the bottom of the list)

Thanks plantucha for finding this bug!

[jondecker76]

@jondecker76,

I've been mining now for quite some time with this setup and it is working great. I like where you are going with the card lockup detection. Is the plan for it to call a script on lockup to allow us to decide what we want to do, ie Reboot or exit smartcoin?

Also, I use openvpn and connectbot on my android phone to monitor/admin miner "boxes" (I say boxes figuratively since there are no pc cases involved I'm wondering if you can detect a screen size of 60x22 or smaller and abbreviate the output so it does not line wrap. For example experimental = exp, Accepted = Acc, Rejected = Rej. My screen size and my eyes make 60x22 a good size to see text but the line wraps mess up the nice formatting.

Thanks again.

jaebird

Yes, I will make hooks to custom scripts to run on failover conditions and lockup conditions.  I like the approach of giving the user the ability to do exactly as they please on these conditions, instead of smartcoin assuming.  

I have also been thinking of ways to make screen size smaller. Using abbreviations isn't a bad Idea, and would quite easy to do. Perhaps I'll make a template file or user setting that can be edited by the user to look something like:

Code:

[<#hashrate#> MHash/sec] [<#accepted#> Accepted] [<#rejected#> Rejected] [<#rejection_percent#>% Rejected]

so that if you prefer, you can change the output template to something like:

Code:

[H:<#hashrate#>] [A:<#accepted#>] [R:<#rejected#>] [%<#rejection_percent#>]

for a much narrower output.  I think I'll add this to the list of planned features!

[jondecker76]

Update r457(experimental) now available
- Improved logging on lockup detection (it will put a screen capture of the instance which caused the failover right into the log)
- you can now have a custom lockup script execute automatically on a lockup condition. Here you can send yourself an email, reboot your machine, restart smartcoin, etc. Just add a custom script, "lockup.sh" to your smartcoin install directory.

Lockups are pretty easy to test (if you want to test your lockup script). Just purposely overclock your card to the point it locks up pretty quickly. After 5 minutes or so, the lockup should be detected and you should see your lockup script get executed.

[plantucha]

Update r456(Experimental) available
- Fixes false lockup detection on failovers.  What was happening, is when a failover event happens, all previous failed profiles continue to run along with the new ones that fall into the list.  On the failed profiles, every now and then the miner would output a message such as "Could not connect, will retry...". After a while, the entire screen would be filled with this message, and even though the message is pushed out again at regular intervals, the screen appears to never change, and triggers the lockup detection.  This fix works by enabling lockup detection only on instances that are not part of a down profile (lockup detection will still work however, as there will still be a failover profile that is working running at the bottom of the list)

Thanks plantucha for finding this bug!

I was about to describe it better.
But you think and coding faster than I can write.
Thanx

[plantucha]

@jondecker76,

I've been mining now for quite some time with this setup and it is working great. I like where you are going with the card lockup detection. Is the plan for it to call a script on lockup to allow us to decide what we want to do, ie Reboot or exit smartcoin?

Also, I use openvpn and connectbot on my android phone to monitor/admin miner "boxes" (I say boxes figuratively since there are no pc cases involved I'm wondering if you can detect a screen size of 60x22 or smaller and abbreviate the output so it does not line wrap. For example experimental = exp, Accepted = Acc, Rejected = Rej. My screen size and my eyes make 60x22 a good size to see text but the line wraps mess up the nice formatting.

Thanks again.

jaebird

Yes, I will make hooks to custom scripts to run on failover conditions and lockup conditions.  I like the approach of giving the user the ability to do exactly as they please on these conditions, instead of smartcoin assuming.  

I have also been thinking of ways to make screen size smaller. Using abbreviations isn't a bad Idea, and would quite easy to do. Perhaps I'll make a template file or user setting that can be edited by the user to look something like:

Code:

[<#hashrate#> MHash/sec] [<#accepted#> Accepted] [<#rejected#> Rejected] [<#rejection_percent#>% Rejected]

so that if you prefer, you can change the output template to something like:

Code:

[H:<#hashrate#>] [A:<#accepted#>] [R:<#rejected#>] [%<#rejection_percent#>]

for a much narrower output.  I think I'll add this to the list of planned features!

you don't even have to abbreviate


MHash/sec =MHash/s

[<#temp#> °C]
[<#accepted#> OK]
[<#rejected#> Bad]

so it will looks like this:

Code:

Smartcoin r457e Tue Jul 19 01:15:56 EDT 2011
----------------------------------------------
Host: localhost
G0: 69.00°C  [load: 99.00%] [fan0 100.00%]
G1: 70.00°C  [load: 99.00%] [fan1 100.00%]
G2: 70.00°C  [load: 99.00%] [fan2 100.00%]
G3: 71.00°C  [load: 99.00%] [fan3 100.00%]
CP  55.00°C  [load: 00.78%] [fanC 059.00%]

Profile: Failover
--------BTCGuild--------
G0: 202.97 Mhash/s [2 OK] [0 Bad] [RPC+LP]
G1: 202.93 Mhash/s [1 OK] [0 Bad] [RPC+LP]
G2: 202.96 Mhash/s [3 OK] [0 Bad] [RPC+LP]
G3: 202.99 Mhash/s [1 OK] [0 Bad] [RPC+LP]
CP: 020.80 MHash/s [0 OK] [0 Bad]

Total : 
832.65 MHash/s [7 OK] [0 Bad] [0% Bad]

[jondecker76]

Update r468e now available!
- There is a new setting under edit settings.. "Miner output format string". As discussed a couple of posts back, it will let you define how the miner output is displayed on the screen. Use the tags <#hashrate#>, <#accepted#>, <#rejected#>, <#rejected_percent#> where you want these displayed.
- Each miner instance now has rejection percentage calculation


I'd still love to hear from anyone that modifies the "Miner output format string" setting and hear how it worked for them (jaebird - try making a narrower format string )

[plantucha]

Another killing problem:
CPU not overclocked temp 55°C fully loaded. but before I got new heatsink I run it 68°C without problems.
Just significantly slower than GPU. mayby just cgminer error. or some secret feature  

Code:

07/19/11 04:07:58       Disconnect option selected

07/19/11 06:11:16       ERROR: It appears that one or more of your devices have locked up.  This is most likely the result of extreme overclocking!

07/19/11 06:11:16              It is recommended that you reduce your overclocking until you regain stability of the system

07/19/11 06:11:16              Below is a capture of the miner output which caused the error:

07/19/11 06:11:16        cgminer version 1.2.7 - Started: [2011-07-19 01:14:55]
--------------------------------------------------------------------------------
 [(5s):11.4  (avg):16.3 Mh/s] [Q:1888  A:72  R:1  HW:0  E:4%  U:0.25/m]
 TQ: 5  ST: 6  LS: 6  SS: 0  DW: 40  NB: 28  LW: 9  LO: 9  RF: 0  I: 0
 Connected to http://btcguild.com:8332/ as user plantucha_cpu
 Block 00000000000000000000000000000000  started: [2011-07-19 05:56:07]
--------------------------------------------------------------------------------
 CPU 0: [2.7 Mh/s] [Q:308  A:9  R:0  HW:0  E:3%  U:0.03/m]
 CPU 1: [2.8 Mh/s] [Q:311  A:12  R:0  HW:0  E:4%  U:0.04/m]
 CPU 2: [2.8 Mh/s] [Q:307  A:8  R:0  HW:0  E:3%  U:0.03/m]
 CPU 3: [2.6 Mh/s] [Q:309  A:16  R:0  HW:0  E:6%  U:0.06/m]
 CPU 4: [2.6 Mh/s] [Q:307  A:13  R:1  HW:0  E:4%  U:0.05/m]
 CPU 5: [2.8 Mh/s] [Q:310  A:14  R:0  HW:0  E:5%  U:0.06/m]
--------------------------------------------------------------------------------


[2011-07-19 05:59:19] Share a3275e03 accepted from CPU 2 thread 2

[2011-07-19 06:04:55] LONGPOLL detected new block on network, waiting on fresh w
ork
[2011-07-19 06:05:03] Failed to tq_pop in discard_request
[2011-07-19 06:05:03] Failed to discard requests in flush_requests

07/19/11 06:11:16       User lockup script found. Running lockup script.

07/19/11 06:11:16       Killing Miners....

Screen logs in /temp are empty. Smartcoin probably sweeping after kiling miners.
Maybe have to sweep before new start. not after kill.

Also i don't think CPU lockup detection is necessary, because if CPU is locked....

[plantucha]

Update r468e now available!
- There is a new setting under edit settings.. "Miner output format string". As discussed a couple of posts back, it will let you define how the miner output is displayed on the screen. Use the tags <#hashrate#>, <#accepted#>, <#rejected#>, <#rejected_percent#> where you want these displayed.
- Each miner instance now has rejection percentage calculation


I'd still love to hear from anyone that modifies the "Miner output format string" setting and hear how it worked for them (jaebird - try making a narrower format string )

this is a Real smartcoin snapshot using #tags#, so it fits in ConnectBot@Android

Awesome !!!!

Code:

Smartcoin r469(experimental) Tue Jul 19 11:09:30 EDT 2011
---------------------------------------------------------------
Host: localhost
G0: Temp °C: 69.00 Load: 99%
G1: Temp °C: 70.00 Load: 99%
G2: Temp °C: 71.00 Load: 99%
G3: Temp °C: 71.00 Load: 99%
CPU Load: 0.78%

Profile: Failover
--------BTCGuild--------
G0:     [207.59 MHash/s] [3 OK] [0 BAD] [0% BAD]
G1:     [207.54 MHash/s] [2 OK] [0 BAD] [0% BAD]
G2:     [207.57 MHash/s] [5 OK] [0 BAD] [0% BAD]
G3:     [207.56 MHash/s] [7 OK] [0 BAD] [0% BAD]
CP:     [20.8 MHash/s] [0 OK] [0 BAD] [0.00% BAD]
Total : [851.06 MHash/s] [17 OK] [0 BAD] [0% BAD]

Grand Total : [851.06 MHash/s] [17 OK] [0 BAD] [0% BAD]

[plantucha]

Anyone!
Post best pools for Smartcoin and explanation why:

Generaly have to be :

PROPORTIONAL:          because penalization for pool hopping (failover is involuntary pool hop)
NO FEES                      more you can save, you can donate to 1AnDpiSvcUKejhENUFuigRCZC97cir4uwn to help fund the development of the SmartCoin
LONG POOLing             much better (2-3%) reject ratio
BIG

[jaebird]

Update r468e now available!
- There is a new setting under edit settings.. "Miner output format string". As discussed a couple of posts back, it will let you define how the miner output is displayed on the screen. Use the tags <#hashrate#>, <#accepted#>, <#rejected#>, <#rejected_percent#> where you want these displayed.
- Each miner instance now has rejection percentage calculation


I'd still love to hear from anyone that modifies the "Miner output format string" setting and hear how it worked for them (jaebird - try making a narrower format string )

Output formatting works good (I restarted smartcoin for the settings to change output). Now the main header needs a way to be reduced. Perhaps allow some timestamp formatting or shorten experimental to "e" or "exp", or just allow the whole string to be user modified.

Thanks,
jaebird

[Jen4538]

finally after alot of distress with linuxcoin and smartcoin it finally works ,  well not sure if i did it right but it does work

i configure a miner useing 7 as option it mines at 79.32 mhash which is impressive to me .   then i thought well i try to figure out how to do failover which says i need another profile.  well i dont understand this so i go back to useing 7 as option and accidently created another miner mining another pool useing same gpu.    what is strange now is that the hash rate went up doing this ,   i think now this is a mystery and now wonder if i make more miners in same pool and create two miners to one gpu.   

well meanwhile i need to figure out this failover if i am to use it downstairs  ,   


Jen

[jondecker76]

Another killing problem:
CPU not overclocked temp 55°C fully loaded. but before I got new heatsink I run it 68°C without problems.
Just significantly slower than GPU. mayby just cgminer error. or some secret feature  

Code:

07/19/11 04:07:58       Disconnect option selected

07/19/11 06:11:16       ERROR: It appears that one or more of your devices have locked up.  This is most likely the result of extreme overclocking!

07/19/11 06:11:16              It is recommended that you reduce your overclocking until you regain stability of the system

07/19/11 06:11:16              Below is a capture of the miner output which caused the error:

07/19/11 06:11:16        cgminer version 1.2.7 - Started: [2011-07-19 01:14:55]
--------------------------------------------------------------------------------
 [(5s):11.4  (avg):16.3 Mh/s] [Q:1888  A:72  R:1  HW:0  E:4%  U:0.25/m]
 TQ: 5  ST: 6  LS: 6  SS: 0  DW: 40  NB: 28  LW: 9  LO: 9  RF: 0  I: 0
 Connected to http://btcguild.com:8332/ as user plantucha_cpu
 Block 00000000000000000000000000000000  started: [2011-07-19 05:56:07]
--------------------------------------------------------------------------------
 CPU 0: [2.7 Mh/s] [Q:308  A:9  R:0  HW:0  E:3%  U:0.03/m]
 CPU 1: [2.8 Mh/s] [Q:311  A:12  R:0  HW:0  E:4%  U:0.04/m]
 CPU 2: [2.8 Mh/s] [Q:307  A:8  R:0  HW:0  E:3%  U:0.03/m]
 CPU 3: [2.6 Mh/s] [Q:309  A:16  R:0  HW:0  E:6%  U:0.06/m]
 CPU 4: [2.6 Mh/s] [Q:307  A:13  R:1  HW:0  E:4%  U:0.05/m]
 CPU 5: [2.8 Mh/s] [Q:310  A:14  R:0  HW:0  E:5%  U:0.06/m]
--------------------------------------------------------------------------------


[2011-07-19 05:59:19] Share a3275e03 accepted from CPU 2 thread 2

[2011-07-19 06:04:55] LONGPOLL detected new block on network, waiting on fresh w
ork
[2011-07-19 06:05:03] Failed to tq_pop in discard_request
[2011-07-19 06:05:03] Failed to discard requests in flush_requests

07/19/11 06:11:16       User lockup script found. Running lockup script.

07/19/11 06:11:16       Killing Miners....

Screen logs in /temp are empty. Smartcoin probably sweeping after kiling miners.
Maybe have to sweep before new start. not after kill.

Also i don't think CPU lockup detection is necessary, because if CPU is locked....

Very interesting!  The lockup system detected locked up mining software (a great, but unexpected side effect)
If you look, the last message from cgminer was at 0605.  About 6 minutes later, at 0611, it was declared locked up.  I do believe during this time period, the miner output didn't change (as shown by the errors in the cgminer output). Also notice "00000000000000000000000000000000", which is not normal.
I think that we need to now make some decisions:

1) This shows that it is useful to detect for lockups even on CPU devices, as it will detect locked up mining software (as it did in your case)
2) Perhaps now that there is custom lockup.sh script support, Killing smartcoin is probably too much.  I think restarting the miners instead is a good idea though and the user can decide themselves via their custom script if they wish to shut down smartcoin.
3) To facilitate shutting down smartcoin easily,  I should add a "--kill" command line switch


Do you think this would  be desirable behavior?

[jondecker76]

Anyone!
Post best pools for Smartcoin and explanation why:

Generaly have to be :

PROPORTIONAL:          because penalization for pool hopping (failover is involuntary pool hop)
NO FEES                      more you can save, you can donate to 1AnDpiSvcUKejhENUFuigRCZC97cir4uwn to help fund the development of the SmartCoin
LONG POOLing             much better (2-3%) reject ratio
BIG

I personally switched to X8S a few weeks ago and have been very happy with it.  I know its just variance and luck, but in 2 weeks time with 1200 MHash, X8S has made me over 7 BTC!  Here is a paste of my failover order at the moment (though it has no scientific technical basis)

Code:

7) X8S Me DD!
2) BTCGuild Me!
3) BTCMine Me!
5) TripleMine Me!
6) X8sx2 + tripleminex1
1) Deepbit Me!
8) poclbmtest
9) cgminer test