Topic: Smartcoin Linux mining administration. [MULTI-MACHINE SUPPORT NOW IN!] - page 18. (Read 105029 times)

I didn't named CPU  'GPU[0]' , since it was not needed by miner, I didn't set new device .

Then I picked just one of GPUs  'GPU[0]' because it was not going to fill out any variable in miners formula


Cgminer page: http://forum.bitcoin.org/index.php?topic=28402.0

Btw:
Cgminer has newest phat kernel support => faster than phoenix for GPU

Here is output from cgminer:
with GPU support is just listed GPU 0 ...X
similar like CPUs just X more rows


launching code

-t   Number of miner CPU threads

-a      Specify sha256 implementation:
        c               Linux kernel sha256, implemented in C
        4way            tcatm's 4-way SSE2 implementation
        via             VIA padlock implementation
        cryptopp        Crypto++ C/C++ implementation
        sse2_64         SSE2 implementation for x86_64 machines (default: sse2_64)

Update r425 stable and experimental available.
- Worker rejected percentage now will display at least 0 until calculations start
- Start of cpu device support. Devices can now be flagged as to their type

Main focus for a while is going to shift to supporting more miners as everything else has been very stable.  This will require some internal design changes, such as abstracting the hashrate value to a determined base and converting other hashrates outside of this base on the fly (phoenix will report in MHash and poclbm reports in KHash for example).  I also have to find a way to get the accepted/rejected information from other miners, as most miners don't calculate them.

actually, you can enter any number you wish, it doesn't have to be an opencl device number, its just what it is normally used for (you can enter 1000 here, if you wanted to).  In the miner setup, if the <#device#> tag is used, this is where that number comes from.  In a miner launchstring that doesn't use the <#device#> tag, its irrelevant anyways.

As far as profiles go,  a device still has to be used in cases like what you are trying to do. It keeps the logic of the program together. The device table its self is abstract - a device is simply something capable of doing hashes as far as bitcoin is concerned so it isn't locked to openCL devices  (I'm also confused as to why you named the cpu 'GPU[0]'?  You can give it any nickname you want - 'AMD6400' for example - this is also true for GPU devices, they just happened to be named 'GPU[X]' by the autodetection code.  You can rename one of your GPU devices 'AMD 5850' if you want even.)

I'm committing changes shortly that let you specify a device type ('gpu' or 'cpu'). This has always existed in the database, but was  hard coded until now to always be 'gpu'.  By marking a device as a non-gpu type, it will keep the aticonfig commands from trying to get information from the non-gpu device.

Can you post sample output from minerd and cgminer?  As well as the command usually used to launch them?    I can add support to show their hashrate along with everything else, if I have this information.

cgminer (compiled without GPU support) or minerd doesn't require any device number
however in profile I MUST choose defined device GPU[X] although it is not necessary for CPU miner
=>
miner is actually working, but showing <<>>    ==> failover changing profile

Can't add correct device number. For some reason it is taking only opencl devices.

also i want to use cgminer or minerd because implemented -aclu 4way and -aclu sse2_64

phoenix is runnig my CPU only 3mhash/s   , minerd = 25mhash/s

so mayby in future..

ok.

You only require root privileges if X windows is already running as the 'root' user.  For example, if you do not have auto-login enabled.  If however, you do have auto-login enabled, then you can run 'aticonfig' as your logged in user.

Update r421 stable and experimental available.
- Failover sensitivity lowered a bit (it now takes 8 consecutive iterations of seeing a profile listed as "down" before marking it failed)
- Failover data in the database is now cleared each restart of smartcoin

dishwara:
If you would have let it continue to run, the extra failover profiles would have dropped off within a few minutes.  The reason is, the failover data in the database isn't reset between restarts, and in recent versions the failover detection is more sensitive - so what likely happened is:
1) Startup took long enough that it tripped the first profile as failed
2) the next failover profile was still marked as failed in the database probably from a previous failure, which caused the 3rd profile to fall into order.
3) After they would have shown they weren't down for a minute or so, they would have fallen back off the list


I have always considered whether this is desired behavior or not.  Now seeing how it has confused you (and possibly other users),  I'm committing a change right now that reduces the failover detection sensitivity a bit, and also failover data in the database is reset each restart of smartcoin.

Before updating, i report a problem in r383.
I created 3 profiles & gave it in fail over order.
It worked correctly once i tried.
But today after my system restart the failover profile runs not one pool but all the 3 pools i gave in fail over order.
I even changed the order, which didn't stop it from mining in all the pools in failover order.
so switched back to auto one.

Hope new updates solve those problems.

Update r419 available for both Experimental and Stable
- AMD/ATI SDK detection at install is now fixed (no more returning both the 64 bit path and the 32 bit path on some systems)
- Temporary files in /tmp are deleted automatically on restarts
- rejection percentage is now shown for each individual pool

RockDJ

The mining  hardware wiki doesn't show rates with no overclock, it shows average reported max MHash with overclocking involved.

Regarding going by hashrates reported by pools, those are calculated on an average.  With this in mind, give it 10-15 minutes to "catch up" and you will see that they should be pretty colse (they will almost never be exactly the same, as it is calculated at the pool's end)

hi againg guys, now that everything seems to be working, I tried to push a bit the device to obtain better results. But I have some doubts...


I changed the parameters of the device via AMDOverdriveCtrl to this values:

- GPU: 725 MHz
- Memory: 1000 MHz
- Voltage: 1050 V


Phoenix is currently running with those instructions:

BFI_INT VECTORS FASTLOOP=false aggression=19 -k phatk (with -k phatk at the end of the line)


This are the results:

- about 500-550 MHash/s
- Temperature around 82/85 °C (about 180°F) with fanspeed 100%


but I have some questions:

a) performances are better but (with this in mind https://en.bitcoin.it/wiki/Mining_hardware_comparison) are still quite far from the average of 5970. With no Overclocking should be around 650 MHash/s
b) Am I taking any hardware risk with the current parameters that I wrote above? How can I determine the risk?
c) How long can I work with those settings?
c) I'm currently mining in two different pools (BTCFarm e BTCGuild), smartcoin tells me that I have an hashrate of respectively 270 and 265 Mhash/s (-> tot 535) while looking at the stats on both pools web pages the result is respectively 150 e 215 (-> tot 365). WHERE THE HELL ARE THE MISSING 170 Mhash/s??

tigereye

I just committed a change regarding the /tmp directory, perhaps it will help.  smartcoin is meant to be installed and run as user. Here is what I would do:

1) Under user, make sure you clear the data directory:

2) Clear out any temporary data:

3) Follow the install stuff again.  Remove the old smartcoin directory and start again.

4) During the detection of the AMD/ATI SDK detection, there is a bug on some systems which shows two paths on one line.  Since Linuxcoin is 64 bit, make sure to leave only the 64 bit relevant path!

5) If after starting things appear not to run, detach from smartcoin (option 3 on the control screen), then run

This will bring you to the individual  miner instances where you can see directly the error output of phoenix

I've got a strange problem with SmartCoin.

I'm using linuxcoin 0.2b1 and have checked out the trunk of smartcoin into /home/user/smartcoin.

I've confirmed that the DB is created successfully and have populated it with the phoenix miner and two workers on two pools.
The miners don't seem to start - it seems like a screen issue.

On Screen1 I see everything listed as <> and every few seconds I see a bunch of errors fly across the screen. I've managed to screencap it and here's what's listed:

Code:

grep: /tmp/smartcoin-Miner.1: No such file or directory

I've tried running it as 'user' and as 'root' and the problem exists on both.
Now here's the strange thing... after uninstalling, reinstalling, trying with sudo, without sudo, eventually I got it to work with sudo! (I had to run the install script as root which put the db into /root/.smartcoin and then run "sudo ./smartcoin.sh"

When it was working, I modified my startup script to launch that command and rebooted.
Then it stopped working with the same "grep" symptom.
I haven't been able to get it to work since.

Another symptom is, I can't just run "smartcoin"
I have to run ./smartcoin.sh from within the smartcoin directory.

Any suggestions?

kennel:

If you prefix the commands with the appropriate display, you shouldn't need root priveleges. I.e.:


So for anyone using an init.sh - you should probably prefix your aticonfig commands with DISPLAY=:0

Nope I run my scripts as a non root user and it includes setting the fan speeds and over clocking my cards

Doesn't aticonfig require root privileges? In other words, doesn't he need to use sudo with the password in plaintext in the init script?

RockDJ:
Here are a few more suggestions for you

1- If there are any commands that you want to have run automatically when smartcoin starts, create a file "init.sh" in the smartcoin directory.  Then you can add your commands that you want run on startup. I.e.:
(make sure you mark it executable with:

2) Experiment with making your own profiles. Its pretty straight forward once you get the hang of it.

3) Once you have a few of your own profiles built, adjust the failover order from the control screen, then change the profile to failover. This will allow you to have alternate pools/workers to mine to if one fails (from ddos attack for example)

THANKS SO MUCH TO EVERYONE!!!! It works!!!

Now I just need to set up the best values of phoenix and AMDOverdrive to maximize the performance of my HD5970.

Any further suggestion?