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

[Jen4538]

Can this problem solved?




Smartcoin believes the GPU is mining even though it submitted shares a long time ago & temperature is in 60C(idle or less) range than other cards.
The total hash rate displaying is 2580+, which i get usually.

Hey dishwara,

what distro are you using? And which mainboard? I recently sticked the 5th card into my system (ubuntu 11.04 headless on MSI 890FXA-GD70) and since then it's like using a 386 DX2 

A really laggy, sometimes not even responding system.

lower aggression down , thats what i had to do when i finished my 5 card 5830 setup on same motherboard .    mine is set at 10 right now and its working well for me .   

Jen

[Alan Lupton]

The problem is the whole system! I don't even reach the point when mining is possible. Again, as I said, like using a 386 CPU or a newer CPU with cache off.

[plantucha]

Can you please add support for CPU mining?
My CPU just idle, so why not to add some more Mhash?
with CPUminerd i can get 25Mhash/s now,
with sse3 in the new version it will be even more.

I can add CPU miner to miners, but cant add CPU device
i offers just opencl GPUs.

Now I just starting script outside Smartcoin,
of course if pool is broken, GPU happily redirecting
CPU working to no avail.

thanks

[Fletch]

- procmail dependency eliminated!
- Errored sql queries will retry  until they succeed (without locking mechanism)

Shouldn't it retry the query only if it gets the "database is locked" error? I mean, if a more serious error occurred, it would just keep pounding the database in an endless loop, would it not?

I'm still curious what is causing the locking issues in the first place. It really shouldn't be an issue for low traffic database stuff such as this.

[jondecker76]

- procmail dependency eliminated!
- Errored sql queries will retry  until they succeed (without locking mechanism)

Shouldn't it retry the query only if it gets the "database is locked" error? I mean, if a more serious error occurred, it would just keep pounding the database in an endless loop, would it not?

I'm still curious what is causing the locking issues in the first place. It really shouldn't be an issue for low traffic database stuff such as this.

Newer committed code retries queries 25 times before considering them dead.  Detailed logging happens on failure showing the exact nature of the failure.

Regarding low traffic database stuff - I hardly consider this low traffic. And in fact, I just did a test to see just what the query rate is:

with these changes...

Code:

Index: sql_ops.sh
===================================================================
--- sql_ops.sh	(revision 407)
+++ sql_ops.sh	(working copy)
@@ -33,6 +33,7 @@
 		echo "$res"
 
         fi
+	echo "$Q" >> ~/test.txt
 }
 
 
Index: smartcoin_status.sh
===================================================================
--- smartcoin_status.sh	(revision 407)
+++ smartcoin_status.sh	(working copy)
@@ -336,12 +336,19 @@
 echo "INITIALIZING SMARTCOIN....."
 
 clear
+echo "" > ~/test.txt
+
 while true; do
+	dte=`date "+%D %T"`
+	echo "$dte" >> ~/test.txt
 	LoadProfileOnChange
 	UI=$(ShowStatus)
 	clear
 	ShowHeader
 	echo -ne $UI
+	dte=`date "+%D %T"`
+	echo "$dte" >> ~/test.txt
 	sleep $statusRefresh
+	exit
 done

I ran smartcoin... Here is the resulting file: (test.txt)

Code:

07/12/11 06:32:13
SELECT value FROM settings WHERE data='donation_start';
SELECT value FROM settings WHERE data='donation_time';
SELECT fk_profile FROM current_profile WHERE fk_machine=1;
SELECT value FROM settings WHERE data='donation_start';
SELECT value FROM settings WHERE data='donation_time';
SELECT fk_profile FROM current_profile WHERE fk_machine=1;
SELECT value FROM settings WHERE data='donation_start';
SELECT value FROM settings WHERE data='donation_time';
SELECT pk_miner FROM miner WHERE fk_machine=1 AND default_miner=1;
SELECT pk_profile, name, down FROM profile WHERE fk_machine='1' ORDER BY failover_order, pk_profile;
SELECT fk_device, fk_miner, fk_worker from profile_map WHERE fk_profile='7' ORDER BY fk_worker ASC, fk_device ASC
SELECT COUNT(*) FROM worker;
SELECT value FROM settings WHERE data='donation_start';
SELECT value FROM settings WHERE data='donation_time';
SELECT fk_profile FROM current_profile WHERE fk_machine=1;
SELECT value FROM settings WHERE data='donation_start';
SELECT value FROM settings WHERE data='donation_time';
SELECT pk_miner FROM miner WHERE fk_machine=1 AND default_miner=1;
SELECT pk_profile, name, down FROM profile WHERE fk_machine='1' ORDER BY failover_order, pk_profile;
SELECT fk_device, fk_miner, fk_worker from profile_map WHERE fk_profile='7' ORDER BY fk_worker ASC, fk_device ASC
SELECT value FROM settings WHERE data='dev_branch';
SELECT value FROM settings WHERE data='AMD_SDK_location';
SELECT value FROM settings WHERE data='dev_branch';
SELECT value FROM settings WHERE data='dev_branch';
SELECT value FROM settings WHERE data='phoenix_location';
SELECT value FROM settings WHERE data='AMD_SDK_location';
SELECT name,device from device WHERE pk_device=1;
SELECT value FROM settings WHERE data='phoenix_location';
SELECT value FROM settings WHERE data='dev_branch';
SELECT name,device from device WHERE pk_device=1;
SELECT name, path,launch FROM miner WHERE pk_miner=1;
SELECT value FROM settings WHERE data='dev_branch';
SELECT value FROM settings WHERE data='AMD_SDK_location';
SELECT name, path,launch FROM miner WHERE pk_miner=1;
SELECT value FROM settings WHERE data='phoenix_location';
SELECT value FROM settings WHERE data='dev_branch';
SELECT value FROM settings WHERE data='AMD_SDK_location';
SELECT name,device from device WHERE pk_device=1;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT value FROM settings WHERE data='phoenix_location';
SELECT value FROM settings WHERE data='AMD_SDK_location';
SELECT name, path,launch FROM miner WHERE pk_miner=1;
SELECT value FROM settings WHERE data='dev_branch';
SELECT name,device from device WHERE pk_device=2;
SELECT value FROM settings WHERE data='phoenix_location';
SELECT value FROM settings WHERE data='AMD_SDK_location';
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name, path,launch FROM miner WHERE pk_miner=1;
SELECT name,device from device WHERE pk_device=2;
SELECT value FROM settings WHERE data='dev_branch';
SELECT value FROM settings WHERE data='phoenix_location';
SELECT value FROM settings WHERE data='AMD_SDK_location';
SELECT name, path,launch FROM miner WHERE pk_miner=1;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name FROM machine WHERE pk_machine=1
SELECT name,device from device WHERE pk_device=2;
SELECT value FROM settings WHERE data='phoenix_location';
SELECT value FROM settings WHERE data='dev_branch';
SELECT value FROM settings WHERE data='AMD_SDK_location';
Select name,device,type from device WHERE fk_machine=1 AND disabled=0 ORDER BY device ASC
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name, path,launch FROM miner WHERE pk_miner=1;
SELECT name,device from device WHERE pk_device=3;
SELECT value FROM settings WHERE data='AMD_SDK_location';
SELECT value FROM settings WHERE data='phoenix_location';
SELECT name, path,launch FROM miner WHERE pk_miner=1;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT value FROM settings WHERE data='phoenix_location';
SELECT name,device from device WHERE pk_device=3;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name,device from device WHERE pk_device=3;
SELECT name, path,launch FROM miner WHERE pk_miner=1;
SELECT name, path,launch FROM miner WHERE pk_miner=1;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT value FROM settings WHERE data='donation_start';
SELECT value FROM settings WHERE data='donation_time';
SELECT fk_profile FROM current_profile WHERE fk_machine=1;
SELECT value FROM settings WHERE data='donation_start';
SELECT value FROM settings WHERE data='donation_time';
SELECT value FROM settings WHERE data='donation_start';
SELECT value FROM settings WHERE data='donation_time';
SELECT fk_profile FROM current_profile WHERE fk_machine=1;
SELECT value FROM settings WHERE data='donation_start';
SELECT value FROM settings WHERE data='donation_time';
SELECT pk_miner FROM miner WHERE fk_machine=1 AND default_miner=1;
SELECT pk_profile, name, down FROM profile WHERE fk_machine='1' ORDER BY failover_order, pk_profile;
SELECT fk_device, fk_miner, fk_worker from profile_map WHERE fk_profile='7' ORDER BY fk_worker ASC, fk_device ASC
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name FROM device WHERE pk_device=1;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name FROM device WHERE pk_device=1;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name FROM device WHERE pk_device=1;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name FROM device WHERE pk_device=2;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name FROM device WHERE pk_device=2;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name FROM device WHERE pk_device=2;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name FROM device WHERE pk_device=3;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name FROM device WHERE pk_device=3;
SELECT user,pass,pool.server, pool.port, pool.name from worker LEFT JOIN pool ON worker.fk_pool = pool.pk_pool WHERE pk_worker=4;
SELECT name FROM device WHERE pk_device=3;
SELECT down,failover_count FROM profile WHERE pk_profile='7';
UPDATE profile SET failover_count='3' WHERE pk_profile='7';
07/12/11 06:32:33

Now this shows, that in 0.20 seconds, 110 database queries are executed.  Multiply by 5 to get queries per second.  550 queries per second is definitely not "low traffic" database stuff (expecially for a CLI utility!)

The locking problem happens because, as you have stated, select queries can happen concurrently, and in fact, if you look at the test.txt i just posted, most all of the queries in the status script are select queries.
The problem is that sqlite requires exclusivity when doing update/insert statements (such as when you add/edit/delete something from the control screen or the update patch system alters the schema).  When trying one of these insert/update statements and there is currently a select statement querying the database, the insert/update can't get exclusivity, and errors out.  And as you can see, with 500+ queries per second, if you try an insert/update statement, the chances of a select statement happening from other code is at that very moment is very high (though this has been purely timing based, as the status loop currently doesn't run full-out with a built-in delay)

In the end though, it seems like the newer approach is working like it should be, so all is good!

[jondecker76]

Can you please add support for CPU mining?

In theory, CPU mining should work.  Give this a try:
1) Configure Miners -> Add
then add an identical copy of the default phoenix miner, but with a reasonable aggression (5?)
2) Configure Devices -> Add
enter the details of your CPU (name it something like CPU[0]), and make sure the device number is correct.

I don't see why it wouldn't work.  I purposely try to detect only GPU's at install, as most people wont' want to run CPU mining.  I think it may even pound the CPU so much, that you may have problems even handling the incoming SSH connection (which Is why I suggested using a lower aggression in phonix) - but feel free to give it a try and let us know if it works!

[jondecker76]

Alan:

Perhaps your new 5th GPU is bad?  Have you seen if it runs isolated on its own?  I don't think its smartcoin related, as I've personally seen an 8 GPU system running smartcoin with no problem. Do you have enough system memory?  Did you double check the devices stored in the database?

[jondecker76]

Update r407(experimental) available
- Does a more graceful job of handling failed SQL queries (failed queries haven't been an issue, this is added "just in case")

If I don't hear of any problems on this recent round of updates in the next day or so, I'll set the flag for the stable branch to be able to update

[Fletch]

Now this shows, that in 0.20 seconds, 110 database queries are executed.  Multiply by 5 to get queries per second.  550 queries per second is definitely not "low traffic" database stuff (expecially for a CLI utility!)

My god. That explains the unusually high load averages (~0.6) I'm seeing when running SmartCoin. What could possibly be going on that would require you to run 500+ queries against SQLite every second? I know very little about shell scripting, but isn't there any way to throttle the execution so that it doesn't run in "realtime"? Put a few "sleeps" here and there maybe?

[jondecker76]

Kennel:

Yes, that is exactly what I do - the status script is "throttled" by doing one refresh every 5 seconds or so - so the 500+ queries per seconds isn't all the time - its a short burst of a hundred queries that lasts 0.2 second once every 5 seconds.. (The 500 queries per second is just an extrapolated value to show that if the loop ran without a delay, thats about what it would be). This is why in the past, I would get unexplainable bug reports, as its by pure timing/bad luck/coincidence that the database locked error would show up (you would have to perform an add/edit/delete or a schema update patch execute in this small .2 second window - though it seemed unlikely, it was happening quite a few times)

If I were using c++, I would store an internal representation of the database and work against that, but bash doesn't have the kind  of  data structures needed to do this, so all queries are "live". With time, I'm sure I can optimize it some more.  Though it may not seem like it, smartcoin is much more complex that it would initially appear! (When I first started the project, I had no idea that it would be as complex as it is - but thats a good thing )

[jondecker76]

Taking off for the day - me and the wife are going to Cedar Point for the day! (The greatest amusement park in the world!  Haven't been there in a couple of years)
I'll be back tomorrow to answer any questions or problems that pop up today

[Alan Lupton]

Alan:

Perhaps your new 5th GPU is bad?  Have you seen if it runs isolated on its own?  I don't think its smartcoin related, as I've personally seen an 8 GPU system running smartcoin with no problem. Do you have enough system memory?  Did you double check the devices stored in the database?

I have 6 cards, and changed the riser cables back and forth and the order of the cards back and forth. All cards ran before perfectly in two separated systems.

[dishwara]

Can this problem solved?

Smartcoin believes the GPU is mining even though it submitted shares a long time ago & temperature is in 60C(idle or less) range than other cards.
The total hash rate displaying is 2580+, which i get usually.

Hey dishwara,

what distro are you using? And which mainboard? I recently sticked the 5th card into my system (ubuntu 11.04 headless on MSI 890FXA-GD70) and since then it's like using a 386 DX2 

A really laggy, sometimes not even responding system.

I am using Ubuntu 11.04 classic(thats what i selected in auto login). MSI big bang marshal. some times some mother boards won't work with 1x extenders. For some slots, particularly 8x slot you may need 16x extender cable.
For my mother board, i can't use 1x extender on pcie_3 & pcie_7, both needs 16x extenders as the slot itself works in 8x mode when other slots filled with cards. Due to limitation of PSU, i am running 4* 6970 & 2 *5870 on this mother board.

[Alan Lupton]

I only use 16x risers. And I modded them because of the power consumption from the mainboard main plug. Anyway, I think I'll reinstall ubuntu with all five cards onboard.

[dishwara]

no need to reinstall.
But if you remove cards & add cards, you MUST run

Code:

sudo aticonfig --initial -f --adapter=all
sudo reboot

Every time some changes happens in graphic cards, then it needs to be reconfigured.
same as installing drivers in Windows, but better in Linux or Ubuntu as you only need to run a single command & reboot, instead of a lengthy installation process as in Windows.

[Rob P.]

thats what i had to do when i finished my 5 card 5830 setup on same motherboard .    mine is set at 10 right now and its working well for me .   

Any chance you'd post a pic of your 5 card 5830 rig.  I'm about to do the same thing...

[Rob P.]

Now this shows, that in 0.20 seconds, 110 database queries are executed.  Multiply by 5 to get queries per second.  550 queries per second is definitely not "low traffic" database stuff (expecially for a CLI utility!)

The locking problem happens because, as you have stated, select queries can happen concurrently, and in fact, if you look at the test.txt i just posted, most all of the queries in the status script are select queries.
The problem is that sqlite requires exclusivity when doing update/insert statements (such as when you add/edit/delete something from the control screen or the update patch system alters the schema).  When trying one of these insert/update statements and there is currently a select statement querying the database, the insert/update can't get exclusivity, and errors out.  And as you can see, with 500+ queries per second, if you try an insert/update statement, the chances of a select statement happening from other code is at that very moment is very high (though this has been purely timing based, as the status loop currently doesn't run full-out with a built-in delay)

In the end though, it seems like the newer approach is working like it should be, so all is good!

When does it make sense to just go back to MySQL?  Seems like most of your headaches would be solved.  Just curious since I know you started there, and then went lightweight, only to find out you had locking issues...

[jaebird]

thats what i had to do when i finished my 5 card 5830 setup on same motherboard .    mine is set at 10 right now and its working well for me .   

Any chance you'd post a pic of your 5 card 5830 rig.  I'm about to do the same thing...

I don't suppose you care about a 4 card 5830 rig... 

[Fletch]

Yes, that is exactly what I do - the status script is "throttled" by doing one refresh every 5 seconds or so - so the 500+ queries per seconds isn't all the time - its a short burst of a hundred queries that lasts 0.2 second once every 5 seconds.. (The 500 queries per second is just an extrapolated value to show that if the loop ran without a delay, thats about what it would be). This is why in the past, I would get unexplainable bug reports, as its by pure timing/bad luck/coincidence that the database locked error would show up (you would have to perform an add/edit/delete or a schema update patch execute in this small .2 second window - though it seemed unlikely, it was happening quite a few times)

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

[Alan Lupton]

Code:

sudo aticonfig --initial -f --adapter=all
sudo reboot

done nearly 30 times now. But thanks.