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

[jondecker76]

fresh install r383

if I change profile or try to kill 2
can't kill mining workers
always some zombies:

mchal    3158  0.9  0.0      0     0 ?        Zl   10:27   2:01 [python] <defunct>
michal    3363  0.8  0.0      0     0 ?        D    10:27   1:54 [python]
michal    3468  0.9  0.0      0     0 ?        Zl   10:27   2:05 [python] <defunct>
michal    3601  0.9  0.0      0     0 ?        D    10:27   2:04 [python]


then new profile cant start, just hanging there:

smartcoin Management System r383(stable) Sat Jul 9 14:01:42 EDT 2011
--------------------------------------------------------------------------------
A configuration change has been detected.  Loading the new profile....
Starting miner Miner.1!
Starting miner Miner.2!
Starting miner Miner.3!
Starting miner Miner.4!

I cant kill zombies even with root, have to restart.

anybody idea what I can do?

Can you post the contents of ~/.smartcoin/smartcoin.log?
What zombies are you referring to?  All miners are launched within a single screen session, named 'miner'
killall screen should get rid of all of them.

mchal    3158  0.9  0.0      0     0 ?        Zl   10:27   2:01 [python] <defunct>
michal    3363  0.8  0.0      0     0 ?        D    10:27   1:54 [python]
michal    3468  0.9  0.0      0     0 ?        Zl   10:27   2:05 [python] <defunct>
michal    3601  0.9  0.0      0     0 ?        D    10:27   2:04 [python]

what command is this the output from?
What distro are you running?

[1714060418]

1714060418

[1714060418]

1714060418

[1714060418]

1714060418

[plantucha]

Can you post the contents of ~/.smartcoin/smartcoin.log?
What zombies are you referring to?  All miners are launched within a single screen session, named 'miner'
killall screen should get rid of all of them.

mchal    3158  0.9  0.0      0     0 ?        Zl   10:27   2:01 [python] <defunct>
michal    3363  0.8  0.0      0     0 ?        D    10:27   1:54 [python]
michal    3468  0.9  0.0      0     0 ?        Zl   10:27   2:05 [python] <defunct>
michal    3601  0.9  0.0      0     0 ?        D    10:27   2:04 [python]

what command is this the output from?
What distro are you running?
[/quote]

Distro: Ubuntu Natty
I reinstalled phoenix from svn 108
and it work again.
 

[plantucha]

Code:

smartcoin Management System r383(stable) Sat Jul 9 16:32:58 EDT 2011
--------------------------------------------------------------------------------
Host: localhost
GPU[0]: Temp: 74.00 load: 99%
GPU[1]: Temp: 79.00 load: 99%
GPU[2]: Temp: 69.00 load: 99%
GPU[3]: Temp: 73.00 load: 99%
CPU Load : 2.64%

Profile: Failover
--------BTCGuild--------
GPU[0]: [204.83 Mhash/sec] [16 Accepted] [0 Rejected] [RPC (+LP)]
GPU[1]: [204.56 Mhash/sec] [10 Accepted] [0 Rejected] [RPC (+LP)]
GPU[2]: [204.66 Mhash/sec] [22 Accepted] [0 Rejected] [RPC (+LP)]
GPU[3]: [204.64 Mhash/sec] [11 Accepted] [0 Rejected] [RPC (+LP)]
Total : [818.69 MHash/sec] [59 Accepted] [0 Rejected]

Grand Total: [818.69 Mhash/sec] [59 Accepted] [0 Rejected] [0% Rejected]

Code:

Profile: Automatic
smartcoin Management System r383(stable) Sat Jul 9 16:47:00 EDT 2011
--------------------------------------------------------------------------------
Host: localhost
GPU[0]: Temp: 75.00 load: 99%
GPU[1]: Temp: 80.00 load: 99%
GPU[2]: Temp: 69.00 load: 99%
GPU[3]: Temp: 72.00 load: 99%
CPU Load : 2.79%

Profile: Automatic
--------BTCGuild--------
GPU[0]: [67.89 Mhash/sec] [17 Accepted] [0 Rejected] [RPC (+LP)]
GPU[1]: [71.79 Mhash/sec] [12 Accepted] [0 Rejected] [RPC (+LP)]
GPU[2]: [75.36 Mhash/sec] [15 Accepted] [0 Rejected] [RPC (+LP)]
GPU[3]: [70.68 Mhash/sec] [10 Accepted] [1 Rejected] [RPC (+LP)]
Total : [285.72 Mhash/sec] [54 Accepted] [1 Rejected]
--------Bitcoins.lc--------
GPU[0]: [71.89 Mhash/sec] [8 Accepted] [3 Rejected] [RPC (+LP)]
GPU[1]: [67.77 Mhash/sec] [13 Accepted] [1 Rejected] [RPC (+LP)]
GPU[2]: [68.14 Mhash/sec] [13 Accepted] [1 Rejected] [RPC (+LP)]
GPU[3]: [71.26 Mhash/sec] [12 Accepted] [1 Rejected] [RPC (+LP)]
Total : [279.06 Mhash/sec] [46 Accepted] [6 Rejected]
--------MineCo--------
GPU[0]: [68.51 Mhash/sec] [5 Accepted] [0 Rejected] [RPC (+LP)]
GPU[1]: [68.38 Mhash/sec] [11 Accepted] [3 Rejected] [RPC (+LP)]
GPU[2]: [67.90 Mhash/sec] [14 Accepted] [1 Rejected] [RPC (+LP)]
GPU[3]: [68.52 Mhash/sec] [8 Accepted] [0 Rejected] [RPC (+LP)]
Total : [273.31 MHash/sec] [38 Accepted] [4 Rejected]

Grand Total: [838.09 Mhash/sec] [138 Accepted] [11 Rejected] [7.971% Rejected]

Is here any reason why Automatic profile mining 20 Mhash/sec more?
is it just rounding in formula or dbase distributing load better?
Rejection rate with automatic profile is horrible, more workers, more rejections,
maybe it is compensation for higher hashrate.


Also I added another GPU and CPU load go from 0.8% to 2.6%, is it normal?

[jondecker76]

Is here any reason why Automatic profile mining 20 Mhash/sec more?
is it just rounding in formula or dbase distributing load better?
Rejection rate with automatic profile is horrible, more workers, more rejections,
maybe it is compensation for higher hashrate.

I have found that I get a slight increase in hashing with multiple instances.  I have seen the explanation that multiple instances help fill in very small times where the CPU might be waiting for the GPU before sending it new work, hence the slight increase in hashing with multiple instances as the CPU always has somewhere to send work to without waiting.

I don't get any rejection rate problems, no matter how many instances I happen to be running. I have tested this up to 6 instances per card with no real affect on rejections.  I have found, however that worksize is very important when it comes to multiple instances and rejection rate.  Could you go to configure miners->edit and edit the phoenix launch string, changing the work size from 128 to 256, then restart smartcoin.  I'd be interested to hear if it fixes your rejection rate problems (i run worksize 256 and I'm always below 1%).  I've been thinking about changing the default launch string to 256, your confirmation on this could help me make that decision.

Also I added another GPU and CPU load go from 0.8% to 2.6%, is it normal?

Yes, this is normal.  

[padrino]

Is here any reason why Automatic profile mining 20 Mhash/sec more?
is it just rounding in formula or dbase distributing load better?
Rejection rate with automatic profile is horrible, more workers, more rejections,
maybe it is compensation for higher hashrate.

I have found that I get a slight increase in hashing with multiple instances.  I have seen the explanation that multiple instances help fill in very small times where the CPU might be waiting for the GPU before sending it new work, hence the slight increase in hashing with multiple instances as the CPU always has somewhere to send work to without waiting.

I don't get any rejection rate problems, no matter how many instances I happen to be running. I have tested this up to 6 instances per card with no real affect on rejections.  I have found, however that worksize is very important when it comes to multiple instances and rejection rate.  Could you go to configure miners->edit and edit the phoenix launch string, changing the work size from 128 to 256, then restart smartcoin.  I'd be interested to hear if it fixes your rejection rate problems (i run worksize 256 and I'm always below 1%).  I've been thinking about changing the default launch string to 256, your confirmation on this could help me make that decision.

The worksize will affect performance depending on your memory clock generally speaking a worksize of 256 will be best with a memory clock around 300Mhz. I actually run that way because you don't need your GPU memory for much while hashing and this keeps the power consumption and heat lower.

[BenD]

Is here any reason why Automatic profile mining 20 Mhash/sec more?

I have seen the explanation that multiple instances help fill in very small times where the CPU might be waiting for the GPU before sending it new work

I also thought this first. But in my case, hashrate with multiple instances varies a lot (from 820 up to 940). Rejections gather around 3.5%.
My system hangs some seconds between the hashrate-calculations. I think, the "plus" of hashing power comes from that time intervals get inaccurate if it comes to such a hang.
When I mine with only one instance per GPU, there are no hangs and hashrate is about 774 - 775 MHash/s. Rejections are about 1.4%. I think this is more accurate.

By the way, updating to 883 worked without problems. It also restarted itself. However, I had the strange effect that the control screen was r838 and the mining screen was stil 870 . Had to kill smartcoin (option 2) and restart it. Then both were 838.

[sharky112065]

Is here any reason why Automatic profile mining 20 Mhash/sec more?
is it just rounding in formula or dbase distributing load better?
Rejection rate with automatic profile is horrible, more workers, more rejections,
maybe it is compensation for higher hashrate.

I have found that I get a slight increase in hashing with multiple instances.  I have seen the explanation that multiple instances help fill in very small times where the CPU might be waiting for the GPU before sending it new work, hence the slight increase in hashing with multiple instances as the CPU always has somewhere to send work to without waiting.

I don't get any rejection rate problems, no matter how many instances I happen to be running. I have tested this up to 6 instances per card with no real affect on rejections.  I have found, however that worksize is very important when it comes to multiple instances and rejection rate.  Could you go to configure miners->edit and edit the phoenix launch string, changing the work size from 128 to 256, then restart smartcoin.  I'd be interested to hear if it fixes your rejection rate problems (i run worksize 256 and I'm always below 1%).  I've been thinking about changing the default launch string to 256, your confirmation on this could help me make that decision.

The worksize will affect performance depending on your memory clock generally speaking a worksize of 256 will be best with a memory clock around 300Mhz. I actually run that way because you don't need your GPU memory for much while hashing and this keeps the power consumption and heat lower.

On my 6970's 950/300 if I set my worksize to 256 my Mhash/s goes down. I have to run at 128.

[jondecker76]

BenD :
Thats strange, multiple instances on my machine don't vary in hash rate any more or less than single instances (I rarely even see a full MHash in variance no matter how many instances I run). Though this is likely something that can vary a lot depending on local conditions (how much system memory is available, etc.)
I'd be interested in hearing how your results change with a worksize of 256

sharky112065 :
Your statement also backs up that each installation is going to have its own sweet spot.  Either way, experimenting with different settings in the phoenix launch string, and number or instances on your own setup should definitely be a part of initially setting up your system to get the best performance possible.

[jondecker76]

My system hangs some seconds between the hashrate-calculations. I think, the "plus" of hashing power comes from that time intervals get inaccurate if it comes to such a hang.

The hang is actually there on purpose to keep cpu usage, disk usage, etc down.  Right now, it only updates once per 6 seconds or so, so this is normal.

[plantucha]

On my 6970's 950/300 if I set my worksize to 256 my Mhash/s goes down. I have to run at 128.

how you did 950/300 ?
950 I can set any time, but memory is 1050 and I cant change it. how you did it?

[jondecker76]

Experimental update r385 available!
(stable branch is still at r383)

- Failover detection threshold cut in half
- Failed miner launches will no longer fail to open the miner screen session.  This will now greatly aid in troubleshooting!  If smartcoin appears to not be working, you will now be able to detach from smartcoin, and run 'screen -r miner' to view the miner screen session windows. Even if the miners failed to launch, we will now have the error output of the miners themselves, which is very valuable for finding problems.
- Some new pools are added: (Smartcoin now supports 27 pools out of the box!)

• Ars Technica
• TripleMining
• Mainframe
• Bitcoin Monkey
• Best Bitcoin
• Eclipse MC

This update is mostly to test out stable vs. experimental updates, but has some very nice features.


If you want to test out, and see the difference between stable and experimental branches: (assuming that you are using the stable updates right now)
1) Do an update from the control tab
You should see that the stable version will not update to r385
2) In the control tab, go to 4) Edit Settings, and edit the development branch setting from 'stable' to 'experimental'
3) Now do another update.
This time you will see that since you are now following the experimental updates, r385 will now update.
4) Restart smartcoin and enjoy the new changes!

I will flag these updates for the stable branch once I get some feedback from people running the experimental updates that there is no problems.

[Rob P.]

Jon,

Nice work on this, I'm just echoing what everyone here on the forums has said.  Just really great stuff.

I have several commands I need to run before firing up SmartCoin.  Appears this is where I'd want to do them:

Code:

Log "******************* NEW SMARTCOIN SESSION STARTED *******************" 
Log "Starting main smartcoin screen session..." 1

I'm thinking of just adding

Code:

Log "******************* NEW SMARTCOIN SESSION STARTED *******************" 
Log "Starting main smartcoin screen session..." 1
$CUR_LOCATION/startup.sh

startup.sh would just sit in the SmartCoin installation directory and would be a shell script with any initialization commands in it.

For me this startup.sh would be:

Code:

#!/bin/sh

DISPLAY=:0 aticonfig --od-enable --adapter=all
DISPLAY=:0 aticonfig --od-setclocks=990,300 --adapter=0
DISPLAY=:0 aticonfig --od-setclocks=990,300 --adapter=1
DISPLAY=:0 aticonfig --pplib-cmd "set fanspeed 0 80"

Thoughts?

[jondecker76]

Rob P:
Thanks for the nice comments and the suggestion!




Update r392(experimental) available!
(stable is still at r383)
- Users can have their own initialization script that will automatically execute at startup. If the file 'init.sh' exists in the smartcoin installation directory, it will be executed upon starting smartcoin. (be sure to have execute permissions set on the script)

- Administrator email setting added. You will be prompted for the email address during the update. (This isn't used yet, but soon I plan on adding settings so that you choose which events fire off emails to alert you of problems, such as failover events, high temperature, daily reports, etc...)

- When the installer is finished, it will tell you if a restart is required or not (not all updates will require them!)

[jaebird]

I just updated... actually reinstalled! I noticed a few dependencies missing from LinuxCoin 0.2.1b

1. locate (sudo apt-get install locate)
2. lockfile (sudo apt-get install procmail, however it installs stuff you don't need as well)

@jondecker76:

Why not use lockfile-progs instead, at least the package in debian is cleaner

Thanks,
jae

[jondecker76]

jaebird -

I'm still up in the air about the best lockfile method to use for now.  One reason is, that I am strongly reconsidering the move to sqlite3.  I'm starting to hit the point where speed limitations are going to become very apparent.  I'm afraid that once multi-machine support is in, someone with 4+ machines will choke things up at the sqlite bottleneck. So the lockfile may become irrelevant if the move back to MySQL happens

[jaebird]

jaebird -

I'm still up in the air about the best lockfile method to use for now.  One reason is, that I am strongly reconsidering the move to sqlite3.  I'm starting to hit the point where speed limitations are going to become very apparent.  I'm afraid that once multi-machine support is in, someone with 4+ machines will choke things up at the sqlite bottleneck. So the lockfile may become irrelevant if the move back to MySQL happens

I understand, using a DB like MySQL or PostgreSQL also gives access to read-only views for other types of info display aka www

On another note: sometimes my 5830's just lock up, there is no update to the status line and aticonfig still shows 99% usage. In cases like this i usually need to do a reboot to get them back. I'm wondering if you are planning on adding this type of failure detection?

Thanks,
Jae

[jondecker76]

Yes, I do have plans for checking for lockups like this, and in fact I've been doing some tests on the best way to do it.

On a side note, overclocking just 1-2mhz less might be enough to stop the problem all together

[epg]

Yes, I do have plans for checking for lockups like this, and in fact I've been doing some tests on the best way to do it.

On a side note, overclocking just 1-2mhz less might be enough to stop the problem all together

I had this same problem with my 5830 cards as well (stuck at 99%, not hashing). My solution was as you suggested, by pushing back the overclock until the cards were stable and didn't hang anymore.

[jondecker76]

I've been having some Failover fun today, and thought i would share my results...

Normally, most people will create manual profiles in which each profile will run one instance per card to a specific pool, then assign a failover order to them.  This is definitely the standard usage case, and it works great!

Just to play around today, I made 3 profiles:
TripleMineMe! (one instance on each card to my Triplemine worker)
X8SME! (once instance on each card to my X8S worker)
X8Sx2 + TripleMinex1 (one instance each on GPU[0] and GPU[1] to my X8S worker, and one instance on GPU[2] to my triplemine worker)

I then updated my failover order to:
X8Sx2 + TripleMinex1
X8SME!
TripleMineMe!
...
...
All my other profiles



Now when I run failover profile, I send hashes from 2 cards to X8S and hashes from 1 card to Triplemine.  If a failover is detected (I.e. ANY of the instances are listed as DOWN)
Then it fails over to try X8S.  Since the first profile had both X8S and Triplemine, then this will either run, or failover to the triplemine profile.

Basically, what a failover profile like this means is
"Hash to both X8S and Triplemine. If one of them fails, send all the hashes to the other one, but give X8S priority"
or, for the programmers out there:

Code:

if(x8s_is_up && triplemine_is_up) {
  hash_to_both
elseif(x8s_is_up)
  hash_to_x8s
else
  hash_to_triplemine
}

Just wanted to make sure people were aware that the failover and profile systems are a little more flexible and powerful than it may initially appear, and it can be fun to set up failovers like this

[Fletch]

This is a bit confusing during install (on Ubuntu 64 bit):

Please make sure the path below is correct, and change if necessary:
/home/miner/AMD-APP-SDK-v2.4-lnx64/lib/x86_64
/home/miner/AMD-APP-SDK-v2.4-lnx64/lib/x86

As you can see, the suggested line contains _64 at the end, but the line that you get to edit doesn't. Should I change it to _64 or not?

Edit: Also, the installer asks for en email address to which notifications are sent, but does Smartcoin actually send any notifications? If so, in which script is that done?