Bitcoin Forum
August 19, 2019, 09:06:09 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 »
1  Bitcoin / Hardware / Re: [Guide] Comprehensive ASICMiner Blade Setup on: August 25, 2013, 01:13:50 PM
how to autostart stratum proxy at headless raspbian?

I tried this:

# /etc/rc.local
# Stratum proxy autostart script
/home/pi/stratum/stratum-mining-proxy/mining_proxy.py -o pool-us.50btc.com -sp 3332 -gp 8334
/home/pi/stratum/stratum-mining-proxy/mining_proxy.py -o stratum.btcguild.com -sp 3330 -gp 8335
#


it doesnt work

if i just write in ssh  /home/pi/stratum/stratum-mining-proxy/mining_proxy.py -o pool-us.50btc.com -sp 3332 -gp 8334
and in another ssh terminal  /home/pi/stratum/stratum-mining-proxy/mining_proxy.py -o stratum.btcguild.com -sp 3330 -gp 8335

it works fine.

why? is my location wrong? is my syntax wrong?


2  Other / CPU/GPU Bitcoin mining hardware / Re: Smartcoin Linux mining administration. [MULTI-MACHINE SUPPORT NOW IN!] on: August 06, 2011, 08:12:48 PM
Ok... I was believing his initial post, because he described very exactly what he is doing.  Embarrassed

Anyway, the new kernel sound intresting for me, but can I change this in linuxcoin also and how can I determine which is used inside linuxcoin allready?

1. you can ask linuxcoin creator
or
2. Look in folder with phatk kernel, compare size , compare date

but you don't need to,
you can simply just copy new kernel folder and put it in original folder
if you have already new kernel => no change
if you have old kernel => you will compute faster
no regression was reported so it's relatively safe.



3  Other / CPU/GPU Bitcoin mining hardware / Re: Smartcoin Linux mining administration. [MULTI-MACHINE SUPPORT NOW IN!] on: August 06, 2011, 07:40:03 PM
I've got 3xATI 6990 in my RIG.

as somebody already said:
His picture in the signature shows now: 2314 Mhash/s
Some calculation reveals: 2314 Mhash/6 cores = 385,6 Mhash per core.
Don't believe some blury pictures.


but
if you wanna go faster try kernel phatk 2.1 or later 2.2
https://bitcointalk.org/index.php?topic=7964.0
4  Other / CPU/GPU Bitcoin mining hardware / Re: Smartcoin Linux mining administration. [MULTI-MACHINE SUPPORT NOW IN!] on: August 06, 2011, 05:01:33 PM
Run one more update - this should bring you to r643 (r607 is termed a "breakpoint update", which means its an update which requires a smartcoin restart before updating beyond this point. I will be making this more clear in the future, and possibly even automating the process of restarting smartcoin and continuing the update).
After this update, a restart of smartcoin should fix the problem. There is new database validation and sanity checking code in changes made after r607 which will automatically fix this issue.

Please report back and let me know how it goes
Yes, thank you. Now the message seem not appearing any more.


Sometimes I have another message in the line right after a GPU-name: <<<idle>>>
And in some rare cases, allmost if I use as GPU-MHz something above 900 MHz (using AMDOverdriveCtrl or aticonfig instead) the CPU goes up to 100% and all GPUs are changing to <<<idle>>>. In this case I found as only solution a complete reboot via putty/ssh.

If I leave it on GPU 900MHz and Mem 840Mhz this does not happen, only sometimes a single GPU is short time on <<<idle>>>.

If I do mining via script and not via smartcoin this behavior do not appear.

What does this mean and how can I prevent this?

As some people are telling that 910:840 and agression=7 is the best (refer this: https://bitcointalk.org/index.php?topic=25798.0;all - the guy who told this has exactly the same config as I have), I would like to do that also, because he makes about 450 MH/s each GPU and I make only 350.

what model GPU do you have?
5  Other / CPU/GPU Bitcoin mining hardware / Re: Smartcoin Linux mining administration. [MULTI-MACHINE SUPPORT NOW IN!] on: August 05, 2011, 10:49:10 PM
i ssh'd in, and it was running fine, so I must have missed it (or you may have reset it).
Just to test, I manually cycled through a few of your manual profiles and was unable to reproduce Sad
Could have just been a fluke?  I'll do some failover tests my manually blocking out a pool with iptables on my machine just to make sure there isn't some new problem, but for now its hard to say what caused the problem you witnessed.

now i can see
I'm looking at screen with logs
not monitor screen

0-$ control  1$ localhost  (2*$Log)

so i'm reporting feature not bug Smiley
My bad

before ctrl+a switched between control an monitor, now control and log Smiley

ctrl a 1
fixed it





6  Other / CPU/GPU Bitcoin mining hardware / Re: Smartcoin Linux mining administration. [MULTI-MACHINE SUPPORT NOW IN!] on: August 05, 2011, 07:54:09 PM
lately , since about 2 versions back
monitor screen doesn't work well.

sometimes in case of failover it take to 1 minute to display 2 profiles,
it just showing starting miners.

and now miners are running ok.
server receiving everything but monitor screen stuck for 3 hours now
and showing only starting miners.

I didn't touch it so you can see yourself @ssh.
7  Bitcoin / Pools / Re: [~500Gh/s] Bitcoins.lc - No invalid blocks, Instant payout, EU, IPv6, 0% fee, LP on: August 03, 2011, 01:12:50 PM

See, this is what I'm talking about.
It is even on same forum page and I totally missed it.
My bad.

Also post somewhere VISIBLY that pool origin is Sweden.
country #1 in mostly everything.
It will look much more credible than Santa Lucia.
8  Bitcoin / Pools / Re: [~500Gh/s] Bitcoins.lc - No invalid blocks, Instant payout, EU, IPv6, 0% fee, LP on: August 03, 2011, 12:55:27 PM
"Bitcoins.lc is hosted in Sweden, in an advanced virtual hosting environment"

Isn't it same reason why Bitomat lost wallet?

http://siliconangle.com/blog/2011/08/01/third-largest-bitcoin-exchange-bitomat-lost-their-wallet-over-17000-bitcoins-missing/

Excuse me? Not even close. They we're using EC2 (Amazon's elastic cloud) and it's not in any way related to the hosting environment we're (My company) running since a few years back.
The environment is based upon XenServer (Enterprise version of Xen, an open source virtualization platform)

Also, we do have off site backups, per hour, encrypted.


On a personal note, i highly doubt that bitomat actually lost anything... It's more then possible that they just took the money and blamed Amazon.

well, maybe you have to put more information outside.
I understand, website is most simple and design for total newbies,
but how about some more info not just in this thread,
because nobody I know willing read 50 forum pages.



9  Bitcoin / Pools / Re: [~500Gh/s] Bitcoins.lc - No invalid blocks, Instant payout, EU, IPv6, 0% fee, LP on: August 03, 2011, 09:53:14 AM
"Bitcoins.lc is hosted in Sweden, in an advanced virtual hosting environment"

Isn't it same reason why Bitomat lost wallet?

http://siliconangle.com/blog/2011/08/01/third-largest-bitcoin-exchange-bitomat-lost-their-wallet-over-17000-bitcoins-missing/
10  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: August 03, 2011, 09:16:19 AM
In keeping up with this thread, I have seen two or three posts saying that shares/minute is a better indicator of performance than MHash/second.  However, I don't understand this argument.

I understand that higher MHash/s doesn't do any good if the GPU is unstable and shares aren't found or shares are rejected, but assuming a person keeps the GPU stable, doesn't the shares/minute vary with luck and difficulty while the MHash/s is what is actually being processed (regardless of luck and difficulty)?

IOW, when a person goes from 310 MHash/s to 320 MHash/s and shares/minute drops from 4.15 to 4.10, it seems logical to me to assume that the 320 MHash/s is better and the change in shares/minute is luck/difficulty related (at least assuming when comparing two relatively short runs [less than a day for sure, a couple days? I'm not sure]).

I'm not saying I don't believe shares/minute is a good thing to pay attention to as well, though.  Obviously if the same scenario involved going from 280 MHash/s to 330 MHash/s and suddenly getting 3 shares/minute instead of 4 shares/minute an issue with the miner or stability would be indicated.

That said, am I misinterpreting something, or is the suggestion that shares/minute is more important than MHash/s oversimplified?
The reason for taking shares/min into account rather than just MHash/s is because MHash/s is only part of the equation.  You have to take into account accuracy and efficiency.  You can compute hashes all day, but unless you're computing the right ones it's not going to do you any good.  So cgminer found a way to still maintain a decent hashing speed while also making sure that the hashes it computes are actually worth a darn.  See the full picture?

Man, you have to be minister or priest in church.
Great talk about full picture, only totally misleading.
some of your bright ideas I have to quote again:

"unless you're computing the right ones it's not going to do you any good."  Grin
or
"making sure that the hashes it computes are actually worth a darn"   Grin


11  Other / CPU/GPU Bitcoin mining hardware / Re: Smartcoin Linux mining administration. [NEW LOCKUP DETECTION & FAILOVER SUPPORT] on: August 02, 2011, 10:02:13 PM
anybody tested
SDK 2.5 ?
12  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: August 02, 2011, 12:17:20 PM
Can I skip that step somehow so it just mines with the CPU?

nothing personal Ali, it was just your post to let me become mad!

This thread is filled with CPU miners complaining about stuff, I do not get why you people still care that much about CPU mining?! My CPUs get 3MH/s each even my crappy 2 year old nvidia graphics does 28MH/s using less power... want it? 5 btc + shipping! If it is a game, pay for it before you play with it, you know ck's BTC address! You won't ever return any amount of investment with CPU mining. Let me do the math for you, ~2 valid shares/hour per core, 2 BTC sent to ck for fixing up some cpu related stuff in cgminer == 4.6 CPU-Years without increase in difficulty to pay the 2 BTC at current difficulty... think of the environment, you waste +95W for 2 BTC a year (reference is Athlon II X4 in this case and difficulty is not raised)...

Buy a $200 gpu and have it payed in 3-5 month including your powerbills... or buy the 2 BTC for $20

well fo number of reasons

because my

1. cpu make 20Mh/s
2. cpu is already in rig and doing nothing (load 1%)
3. in 5 years will cost 1BTC many thousands $ so even making almost nothing or loosing - will be profit in future if you keep it
4. because this is only decent cpu miner
5. On my rig is  GPU mining 20% more effective with combination Phoenix + Smartcoin
    it has more Mhash/s and failover with more options. Cgminer is running for CPU only under Smartcoin, so I don't care about Cgminer GPU hashing at all.

13  Other / CPU/GPU Bitcoin mining hardware / Re: Smartcoin Linux mining administration. [NEW LOCKUP DETECTION & FAILOVER SUPPORT] on: August 01, 2011, 03:44:18 AM
Update r633e now available:
- New installer uses the new AutoDetection routine (the same one that runs on remote machines). It also uses the new settings code.
- When adding a new machine, default settings are now filled out
- The status screen now only grabs settings information for the current machine





All that is left to do now for full multi-machine support is figure out how to get the miner screen instance to launch on a remote host.  I may play with that a bit today, but I expect to have it figured out in a day or two


Something new with failover?
As you see profile 1 CPU fail. And same time in profile 2 is CPU happily hashing with full hashpower.

Code:
Smartcoin r633e 23:39:46
----------------------------------------
Host: localhost
GPU[0]: Temp: 71.00 load: 99%
GPU[1]: Temp: 73.00 load: 99%
GPU[2]: Temp: 77.00 load: 99%
GPU[3]: Temp: 70.00 load: 99%
CPU Load Avgs: 6.59 6.63 6.60

Profile: Failover
--------BTCGuild--------
GPU[0]: [103.79 MHash/s] [194 OK] [1 Bad] [.515% Bad]
GPU[1]: [103.74 MHash/s] [199 OK] [4 Bad] [2.010% Bad]
GPU[2]: [103.78 MHash/s] [171 OK] [1 Bad] [.584% Bad]
GPU[3]: [103.79 MHash/s] [215 OK] [1 Bad] [.465% Bad]
CPU:    <<<FAIL>>
Total : [415.10 MHash/s] [779 OK] [7 Bad] [.898% Bad]

Failover to: Mt.Red
--------MtRed--------
GPU[0]: [105.89 MHash/s] [185 OK] [3 Bad] [1.621% Bad]
GPU[1]: [103.74 MHash/s] [248 OK] [4 Bad] [1.612% Bad]
GPU[2]: [103.79 MHash/s] [197 OK] [1 Bad] [.507% Bad]
GPU[3]: [103.78 MHash/s] [211 OK] [1 Bad] [.473% Bad]
CPU:    [17.6 MHash/s] [33 OK] [0 Bad] [0% Bad]
Total : [434.80 MHash/s] [874 OK] [9 Bad] [1.029% Bad]

Grand Total : [849.90 MHash/s] [1653 OK] [16 Bad] [.967% Bad]
{/code]
14  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: July 31, 2011, 12:36:32 AM
Hey, I've been working on the hashing asm, as I said before, by removing redundancies of functions and register moves, using logic to modify source and destinations to take advantage of processor hardware optimizations and doing some of the easy math myself so the processor doesn't have to.  Here's what I've done so far.  It's not much, but it works.  Don't go changing the github source just yet though.  For now, copy-paste this to replace your existing sha256_sse4_amd64.asm file.  For those of you without SSE4.1 (such as AMD users), copy paste this into you sse2_amd64 file instead and search-replace all uses of movntdqa with movdqa so the quick memory moves aren't used.


I'll be attacking the LAB_LOOP next.

where is located sse2_amd64 file for AMD users?

in /x86_64
is only:

sha256_sse4_amd64.asm
sha256_xmm_amd64.asm

I don't see anywhere:
sha256_sse2_amd64.asm

Oops, sorry.  The xmm version is what I meant.  I keep thinking sse2 and sse4 for ease of my mind and maintaining difference of programming instructions.  I'm looking for places to implement SSE3 instructions to run math calculations on dwords simultaneously, but I would have to restructure the entire program to take advantage of it and even then I'm not sure if it would work better or worse.

AMD phenom X6

sse2              17.4 MHash/s
fixed sse2      18.0 MHash/s
4way              20.4 MHash/s
sse4               illegal instruction


edit:
4way works in 1.4.down 
in 1.5.up works too (same speed), but everything is rejected
15  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: July 30, 2011, 11:52:55 PM
Hey, I've been working on the hashing asm, as I said before, by removing redundancies of functions and register moves, using logic to modify source and destinations to take advantage of processor hardware optimizations and doing some of the easy math myself so the processor doesn't have to.  Here's what I've done so far.  It's not much, but it works.  Don't go changing the github source just yet though.  For now, copy-paste this to replace your existing sha256_sse4_amd64.asm file.  For those of you without SSE4.1 (such as AMD users), copy paste this into you sse2_amd64 file instead and search-replace all uses of movntdqa with movdqa so the quick memory moves aren't used.


I'll be attacking the LAB_LOOP next.

where is located sse2_amd64 file for AMD users?

in /x86_64
is only:

sha256_sse4_amd64.asm
sha256_xmm_amd64.asm

I don't see anywhere:
sha256_sse2_amd64.asm




16  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: July 29, 2011, 01:14:34 PM
I'm not sure what you're telling me. That error: null field is coming from your pool, not from cgminer.

then why is it not coming from pool if I'm using 1.4?
17  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: July 29, 2011, 12:42:10 PM
I can confirm. CPU mining doesn't work
1.5.&up i have to go back to 1.4 and it works

with 1.5 only   4% was acepted  96% rejected

- CPU: AMD Phenom X6
- GPU: 4x HD 6790 oced to 900 MHz (Mem 300 MHz)
- ubuntu 64 bit natty
- Catalyst 11.6 with SDK 2.4

Have you tried forcing other CPU algorithms with the "-a" option? Perhaps it is particular to a algorithm running on your CPU architecture? You might need to look at the debug output for some of the rejects to get an idea why they are failing. Also, what pool are you connecting to?

-- RD

Yes I tried
sse4_64 - doesn't work ( AMD CPU doesnt support it)
sse2_64 - ~17Mh/s
4way     - ~21Mh/s
everything else is so small I will not even talk about it.

But as I said, same string works with older version, so it will be code related.

I'm trying to come up with ways to make it AMD compatible.  There is C code for SSE4, but it compiles the same as SSE2 due to the intrinsics being the same and using the same functions.  There would need to be a structural change in how it's implemented in order to take full advantage of the newer SSE instructions and I don't know much about programming in C.
The ASM code uses movntdqa which can be replaced with MOVNTSD in theory.  I don't have an AMD processor to play around with it, but you're free to try.



last git log, but it is same in any 1.5up version

Code:
[2011-07-29 08:32:19] Popping work from get queue to get work
[2011-07-29 08:32:19] Successfully divided work
[2011-07-29 08:32:19] Pushing divided work to get queue head
[2011-07-298 / 1.719] Popping work to work thread
[2011-07-2.1 / 1.819] Popping work to work thread
           6 / 1.8
           7
[2011-07-293 / 2.019] JSON protocol request:
               1.9< HTTP/1.1 200 ok
< Content-Type: application/json
< Connection: keep-alive
[2011-07-29 08:32:19] Discarded cloned work
[2011-07-29 08:32:19] Queueing getwork request to work thread
[2011-07-29 08:32:19] Popping work from get queue to get work
[2011-07-29 08:32:19] Successfully divided work
[2011-07-29 08:32:19] Pushing divided work to get queue head
[2011-07-29 08:32:19] Popping work to work thread
[2011-07-29 08:32:19] Popping work to work thread
      "midstate": "0ff8e6b8afda0bb8cef88f8eff297ff6bd5b98bfc456d5e0b178b9e34bee2de5",
      "data": "00000001b2b92d457e2b78eea04ce3610ac9f07575e368def4cc8156000008100000000095d00c5f783b6729c8b55c0d4223ec43671bbf6055a81a51f7db124a8554a3624e32a
84e1a09ec0400000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
      "hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"
   },
   "error": null
}
[2011-07-29 08:32:19] Pushing work to requesting thread< HTTP/1.1 200 ok
< Content-Type: application/json
< Connection: keep-alive
< X-Long-Polling: /LP
< X-Roll-NTime: Y
< Date: Fri, 29 Jul 2011 12:31:54 GMT
< Content-Length: 591
<
* Connection #0 to host mtred.com left intact
[2011-07-29 08:32:19] JSON protocol response:
{
   "id": 0,
   "result": {
      "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000",
      "midstate": "c76491bd49e962f112793907c80a8e1933bb94b780b5f8c8f6a7debb870b5bf9",
      "data": "00000001b2b92d457e2b78eea04ce3610ac9f07575e368def4cc8156000008100000000007eb0f367c39eaddf1b49dbf8c46e887e8383ce15edc64d67ad352f138d7e8224e32a
84e1a09ec0400000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
      "hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"
   },
   "error": null
}
[2011-07-29 08:32:19] Pushing work to requesting thread
[2011-07-29 08:32:19] Pushing work to getwork queue
[2011-07-29 08:32:19] Popping work to stage thread
[2011-07-29 08:32:19] Pushing work to getwork queue
[2011-07-29 08:32:19] Popping work to stage threadQuit

using -a 4way
with 1.4 are no such a  "error": null calls   
and rejection is 0%



18  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: July 29, 2011, 03:55:41 AM
I can confirm. CPU mining doesn't work
1.5.&up i have to go back to 1.4 and it works

with 1.5 only   4% was acepted  96% rejected

- CPU: AMD Phenom X6
- GPU: 4x HD 6790 oced to 900 MHz (Mem 300 MHz)
- ubuntu 64 bit natty
- Catalyst 11.6 with SDK 2.4

Have you tried forcing other CPU algorithms with the "-a" option? Perhaps it is particular to a algorithm running on your CPU architecture? You might need to look at the debug output for some of the rejects to get an idea why they are failing. Also, what pool are you connecting to?

-- RD

Yes I tried
sse4_64 - doesn't work ( AMD CPU doesnt support it)
sse2_64 - ~17Mh/s
4way     - ~21Mh/s
everything else is so small I will not even talk about it.

But as I said, same string works with older version, so it will be code related.


Also I noticed after couple hours is CPU mining hashing going slowly down
For example
on start after 2 minutes  is ~21Mh/s
after 8 hours ~13Mh/s

if I stop miner and start miner, it is again ~21Mh/s.
With all versions versions Cgminer.

Predecessor (CPUminer) is holding starting values same all the time. (unfortunately freezing every couple hours)




19  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: July 29, 2011, 03:45:42 AM
I can confirm. CPU mining doesn't work
1.5.&up i have to go back to 1.4 and it works

with 1.5 only   4% was acepted  96% rejected

- CPU: AMD Phenom X6
- GPU: 4x HD 6790 oced to 900 MHz (Mem 300 MHz)
- ubuntu 64 bit natty
- Catalyst 11.6 with SDK 2.4

Have you tried forcing other CPU algorithms with the "-a" option? Perhaps it is particular to a algorithm running on your CPU architecture? You might need to look at the debug output for some of the rejects to get an idea why they are failing. Also, what pool are you connecting to?

-- RD

Yes I tried
sse4_64 - doesn't work ( AMD CPU doesnt support it)
sse2_64 - ~17Mh/s
4way     - ~21Mh/s
everything else is so small I will not even talk about it.

But as I said, same string works with older version, so it will be code related.




20  Bitcoin / Mining software (miners) / Re: Official CGMINER thread - CPU/GPU miner in C for linux/windows/osx on: July 28, 2011, 09:35:43 PM
CPU Mining doesn't work properly. No accepted shares through CPU. Only GPU works as expected.
After 2 hours run time i can see the following:

Code:
cgminer version 1.5.1 - Started: [2011-07-28 13:37:27]
--------------------------------------------------------------------------------
 [(5s):117.4  (avg):111.8 Mh/s] [Q:1152  A:144  R:34  HW:0  E:12%  U:1.19/m]
 TQ: 1  ST: 5  LS: 0  SS: 0  DW: 455  NB: 14  LW: 1017  LO: 2  RF: 0  I: 4
 Connected to http://mining.eligius.st:8337 as user XYZ
 Block 000151fdeb39b3e1a21b797f87bdd355  started: [2011-07-28 15:32:34]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0: [102.8 / 102.0 Mh/s] [Q:678  A:144  R:11  HW:0  E:21%  U:1.19/m]
 CPU 0: [2.5 / 2.5 Mh/s] [Q:259  A:0  R:6  HW:0  E:0%  U:0.00/m]
 CPU 1: [2.5 / 2.5 Mh/s] [Q:258  A:0  R:7  HW:0  E:0%  U:0.00/m]
 CPU 2: [2.3 / 2.4 Mh/s] [Q:260  A:0  R:7  HW:0  E:0%  U:0.00/m]
 CPU 3: [2.5 / 2.4 Mh/s] [Q:257  A:0  R:3  HW:0  E:0%  U:0.00/m]
--------------------------------------------------------------------------------

- CPU: Athlon II 605e (4x 2,3 GHz)
- GPU: HD 5670 oced to 900 MHz (Mem 300 MHz)
- Gentoo 64 bit stable
- Catalyst 11.6 with SDK 2.4
- latest cgminer GIT version

It could be that blocks are being found before you receive the next one.  It appears that your CPU hashing a rather slow which is understandable for a 2.3 Ghz processor.  But pay close attention to your accepted to rejected ratio on your GPU; with that high of a rejection rate, either something is happening with your network that is causing it not to send at the right time.  If this happens, the work will go stale and be rejected.
There's a number of reasons why the work could have been rejected but I don't think that the miner itself is one of them.

I can confirm. CPU mining doesn't work
1.5.&up i have to go back to 1.4 and it works

with 1.5 only   4% was acepted  96% rejected

- CPU: AMD Phenom X6
- GPU: 4x HD 6790 oced to 900 MHz (Mem 300 MHz)
- ubuntu 64 bit natty
- Catalyst 11.6 with SDK 2.4

Pages: [1] 2 3 4 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!