Bitcoin Forum
December 13, 2017, 02:40:15 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 [97] 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 »
1921  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" (~350 GH/s) on: June 21, 2011, 08:36:10 PM
Was that around June 14th? Thats when the maximumpps shorting system was implemented.
maybe if you link to your stats page it will be easier to research, like this:
http://eligius.st/~artefact2/blocks/1QEkXwhhHbaBCfmEHY7bh8QNPVkFtorQkK
Now for that address, you can see the maximum pps shorting did it's job during these rounds:
1h2m   4s   3,338/145,196=   2.2990 %   0.29390580 BTC (should be 1.1495)
16m43s   854/39,560=   2.1587 %   0.07508482 BTC (1.07935)
3h22m34s   5,498/470,841=   1.1677 %   0.48443702 BTC (.58385)
1h38m18s   5,022/239,107=   2.1003 %   0.44257700 BTC (1.05015)
29m49s   1,578/72,605=   2.1734 %   0.13906552 BTC (1.0867)
1h23m24s   3,817/176,193=   2.1664 %   0.33638325 BTC (1.0832)
For a total shorting of around 4BTC which wasn't made up for (by even .01BTC) in the longer round below that awarded the expected amounts of 50 BTC * % contributed:
4h   34m   14s no reimbursement
1h   33m   52s no reimbursement   
4h   6m   41s no reimbursement
9h   33m   13s no reimbursement
3h   22m   34s no reimbursement
2h   9m   54s no reimbursement
Coupled with the almost 7 BTC that the pool acknowledges it owes him but presumably has not yet made plans to pay him, I can see why this miner left and never returned to eligius.
If you have any disagreement on the math, PLMK where my mistake was.
There's a reason why all the top hashers have been with eligius less than 1 week:
After someone screws you out of BTC, would you keep mining with them?
Hopefully he won't do it to the new users, but you've all been warned. . .
There was an evidence denial posted recently, so, I'm reposting the evidence (see above) which was never refuted.
The poster didn't use basic discussion principles, so I can't really respond other than trying to steer him back to the factual evidence under discussion.
Here's the stats summary for the unpaid rewards on that typical miner loss I examined above:
http://eligius.st/~artefact2/us/1QEkXwhhHbaBCfmEHY7bh8QNPVkFtorQkK
http://eligius.st/~artefact2/eu/1QEkXwhhHbaBCfmEHY7bh8QNPVkFtorQkK
I vote for gimeee's mney to be taken and donated to the pool.
Admitting the theft is at least a step forward to reversing it.
Even if it were only one miner being stolen from, that's enough reason for me to avoid Eligius until it comes clean.

Did I say donating it to the pool? I meant giving it to me.
1922  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" (~350 GH/s) on: June 21, 2011, 08:23:57 PM
Was that around June 14th? Thats when the maximumpps shorting system was implemented.
maybe if you link to your stats page it will be easier to research, like this:
http://eligius.st/~artefact2/blocks/1QEkXwhhHbaBCfmEHY7bh8QNPVkFtorQkK
Now for that address, you can see the maximum pps shorting did it's job during these rounds:
1h2m   4s   3,338/145,196=   2.2990 %   0.29390580 BTC (should be 1.1495)
16m43s   854/39,560=   2.1587 %   0.07508482 BTC (1.07935)
3h22m34s   5,498/470,841=   1.1677 %   0.48443702 BTC (.58385)
1h38m18s   5,022/239,107=   2.1003 %   0.44257700 BTC (1.05015)
29m49s   1,578/72,605=   2.1734 %   0.13906552 BTC (1.0867)
1h23m24s   3,817/176,193=   2.1664 %   0.33638325 BTC (1.0832)
For a total shorting of around 4BTC which wasn't made up for (by even .01BTC) in the longer round below that awarded the expected amounts of 50 BTC * % contributed:
4h   34m   14s no reimbursement
1h   33m   52s no reimbursement   
4h   6m   41s no reimbursement
9h   33m   13s no reimbursement
3h   22m   34s no reimbursement
2h   9m   54s no reimbursement
Coupled with the almost 7 BTC that the pool acknowledges it owes him but presumably has not yet made plans to pay him, I can see why this miner left and never returned to eligius.
If you have any disagreement on the math, PLMK where my mistake was.
There's a reason why all the top hashers have been with eligius less than 1 week:
After someone screws you out of BTC, would you keep mining with them?
Hopefully he won't do it to the new users, but you've all been warned. . .
There was an evidence denial posted recently, so, I'm reposting the evidence (see above) which was never refuted.
The poster didn't use basic discussion principles, so I can't really respond other than trying to steer him back to the factual evidence under discussion.
Here's the stats summary for the unpaid rewards on that typical miner loss I examined above:
http://eligius.st/~artefact2/us/1QEkXwhhHbaBCfmEHY7bh8QNPVkFtorQkK
http://eligius.st/~artefact2/eu/1QEkXwhhHbaBCfmEHY7bh8QNPVkFtorQkK

I vote for gimeee's mney to be taken and donated to the pool.
1923  Bitcoin / Pools / Re: Attention: mining pool operators on: June 21, 2011, 08:05:08 PM
Mod here. Why must people make threads that I just have to lock later?
1924  Bitcoin / Pools / Re: [~3000 Gh/s Mining Pool] HTTPS,API, instant payouts,LP,+1% for NO INVALID BLOCKS on: June 21, 2011, 06:36:44 PM
Now that I'm out of newbie-hell on the forums I'd like to suggest that this now 160 page "forum" disguised as a single thread has now grown to the point (along with slush's thread) to a sub-forum of 'Pools"

http://forum.bitcoin.org/index.php?topic=17462.msg223800#msg223800

Thoughts?

I'd really like to be able to use a RSS reader focused on deepbit pool only.  Can't do that with a single thread...

Boards within boards within boards...

No different than Pools being Bitcoin Forum->Bitcoin->Mining->Pools.
Just make Bitcoin Forum->Bitcoin->Mining->Pools->DeepBit!
There are so many parallel conversations going on that should really be separate threads just to keep them straight...

Not to mention remembering the last page I was at...

I get that when a pool starts you wouldn't create one right away as they might be some fly-by-night deepbit wanna-be.  But there is a critical mass at which its time to give them their own bucket.

Theymos will have to do it. I don't mind seeing subforums for the three largest pools (the ones I have stickied atm), but I don't have the power to make them.
1925  Bitcoin / Pools / Re: [~3000 Gh/s Mining Pool] HTTPS,API, instant payouts,LP,+1% for NO INVALID BLOCKS on: June 21, 2011, 06:24:48 PM
Now that I'm out of newbie-hell on the forums I'd like to suggest that this now 160 page "forum" disguised as a single thread has now grown to the point (along with slush's thread) to a sub-forum of 'Pools"

http://forum.bitcoin.org/index.php?topic=17462.msg223800#msg223800

Thoughts?

I'd really like to be able to use a RSS reader focused on deepbit pool only.  Can't do that with a single thread...

Boards within boards within boards...
1926  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" (~320 GH/s) on: June 21, 2011, 06:12:25 PM
Hey GimEEE,
I'm not being a smart arse here, but I'm wondering if you realise how the score based system Luke Jr uses works? Ignore my post if you do, but I noticed in your post:
Quote
(while not increasing my reward for rounds longer than 90 minutes).
If you mean the EU server, this is how the score based system works - your shares decay over time, you get the same for longer rounds as shorter ones, and shares contributed at the start of the round are  worth less than those at the end (to try to reduce the value of pool hopping).
Also:
Quote
us server pps shorting
Max PPS ran on the US server for only very short period of time. And even if you did run on it for a while, you might see some short term reduction in payout the value of which you'll get back as soon as US is up.
Luke has been totally open about all this (although maybe not as clear as I'd like) and he has a long history here. I'd trust him to get you your coins if they are missing. If I've misunderstood your post, I apologise in advance.
Regarding the maximumpps shorting system, it's totally different from "score based systems" - Here we had a pool operator reducing rewards for rounds less than 90 minutes and keeping the reduction to themselves (or loaning it to themselves if you want to give him the benefit of your optimism), there was a promise that rounds later that were longer would be repaid this loaned BTC, but this repayment was never implemented. there is a typical example of how it affected a user in my post above.
Of course optimism, hope, opinion, and LOTS of WAITING would be good in this case to reach the conclusion that nothing is fishy. Can the shorted miners use all those tools to accept current situation? yes, of course, they could also get a lobotomy and accept it.
Should miners quietly accept the fact that a pool took work under explicit promises, then failed to meet the conditions promised? Apparently you're saying I should. . .
Well, I did several days of waiting and hoping and being optimistic, and it didn't deliver the coins he owed me.

Mod here. Don't be a jackass.
Sorry for not quietly accepting the loss of BTC. . .
I'm the jackass for that.
The pool operator is totally in the right.
(that was sarcasm)

Then use a different pool.
I did, almost all the top miners did, as you'll see none of the current miners were active around June 14th when the shorting took place.
Using a different pool doesn't get my "borrowed without permission" BTC back from Eligius though.

And good for you. I'm the author of DiabloMiner and a forum mod and one of the earliest Bitcoin adopters.

I use Eligius.  Grin
1927  Bitcoin / Mining / Re: Just got off the phone with NewEgg... on: June 21, 2011, 05:58:16 PM
Mod here. Locking the thread because I'm tired of people reporting it frequently.

Oh, and don't screw Newegg just because you had a bad Bitcoin experience, and you can take this entire conversation elsewhere.
1928  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" (~320 GH/s) on: June 21, 2011, 02:54:29 PM
Hey GimEEE,
I'm not being a smart arse here, but I'm wondering if you realise how the score based system Luke Jr uses works? Ignore my post if you do, but I noticed in your post:
Quote
(while not increasing my reward for rounds longer than 90 minutes).
If you mean the EU server, this is how the score based system works - your shares decay over time, you get the same for longer rounds as shorter ones, and shares contributed at the start of the round are  worth less than those at the end (to try to reduce the value of pool hopping).
Also:
Quote
us server pps shorting
Max PPS ran on the US server for only very short period of time. And even if you did run on it for a while, you might see some short term reduction in payout the value of which you'll get back as soon as US is up.
Luke has been totally open about all this (although maybe not as clear as I'd like) and he has a long history here. I'd trust him to get you your coins if they are missing. If I've misunderstood your post, I apologise in advance.
Regarding the maximumpps shorting system, it's totally different from "score based systems" - Here we had a pool operator reducing rewards for rounds less than 90 minutes and keeping the reduction to themselves (or loaning it to themselves if you want to give him the benefit of your optimism), there was a promise that rounds later that were longer would be repaid this loaned BTC, but this repayment was never implemented. there is a typical example of how it affected a user in my post above.
Of course optimism, hope, opinion, and LOTS of WAITING would be good in this case to reach the conclusion that nothing is fishy. Can the shorted miners use all those tools to accept current situation? yes, of course, they could also get a lobotomy and accept it.
Should miners quietly accept the fact that a pool took work under explicit promises, then failed to meet the conditions promised? Apparently you're saying I should. . .
Well, I did several days of waiting and hoping and being optimistic, and it didn't deliver the coins he owed me.

Mod here. Don't be a jackass.
Sorry for not quietly accepting the loss of BTC. . .
I'm the jackass for that.
The pool operator is totally in the right.
(that was sarcasm)

Then use a different pool.
1929  Bitcoin / Pools / Re: Please test: New Experimental Pool "Eligius" (~320 GH/s) on: June 21, 2011, 01:29:51 PM
Hey GimEEE,
I'm not being a smart arse here, but I'm wondering if you realise how the score based system Luke Jr uses works? Ignore my post if you do, but I noticed in your post:
Quote
(while not increasing my reward for rounds longer than 90 minutes).
If you mean the EU server, this is how the score based system works - your shares decay over time, you get the same for longer rounds as shorter ones, and shares contributed at the start of the round are  worth less than those at the end (to try to reduce the value of pool hopping).
Also:
Quote
us server pps shorting
Max PPS ran on the US server for only very short period of time. And even if you did run on it for a while, you might see some short term reduction in payout the value of which you'll get back as soon as US is up.
Luke has been totally open about all this (although maybe not as clear as I'd like) and he has a long history here. I'd trust him to get you your coins if they are missing. If I've misunderstood your post, I apologise in advance.
Regarding the maximumpps shorting system, it's totally different from "score based systems" - Here we had a pool operator reducing rewards for rounds less than 90 minutes and keeping the reduction to themselves (or loaning it to themselves if you want to give him the benefit of your optimism), there was a promise that rounds later that were longer would be repaid this loaned BTC, but this repayment was never implemented. there is a typical example of how it affected a user in my post above.
Of course optimism, hope, opinion, and LOTS of WAITING would be good in this case to reach the conclusion that nothing is fishy. Can the shorted miners use all those tools to accept current situation? yes, of course, they could also get a lobotomy and accept it.
Should miners quietly accept the fact that a pool took work under explicit promises, then failed to meet the conditions promised? Apparently you're saying I should. . .
Well, I did several days of waiting and hoping and being optimistic, and it didn't deliver the coins he owed me.

Mod here. Don't be a jackass.
1930  Bitcoin / Mining software (miners) / Re: Windows won't detect more than 4 GPU is MYTH on: June 21, 2011, 01:24:40 PM
Troll thread detected. This thread is now locked.
1931  Other / CPU/GPU Bitcoin mining hardware / Re: Official DiabloMiner GPU Miner Thread (now with Long Poll and BFI_INT support) on: June 21, 2011, 01:23:21 PM
I had a problem overnight with DiabloMiner and I'm not sure if this is a known problem (couldn't find anything in a quick search).

I have two 5970s (four total GPU cores) and overnight, one of the cores went idle with DiabloMiner. I noticed long enough after it happened that any error messages were not in my scrollback buffer anymore, so I don't know what happened.

Is this a normal problem?  Restarting DiabloMiner fixed it, but I am worried that this wasn't a one time issue. 

I really hope to find a solution for this one because it is really slick to only have to run one instance of DiabloMiner vs multiple instances of phoenix/poclbm.

Assuming that your GPUs are not overheating (keep them 85c or below) and the VRMs are not overheating (which can happen with poor airflow, even at low GPU temps), then you're looking at a driver bug.

Sadly, the driver bug would even happen if you ran pheonix/poclbm. Some people work around it by running twice as many miners at once, because it doesn't freeze both of them. Its a bad hack, but it'll work until AMD fixes their shit.

Temps on the cards are all around 70c.  Not sure how to check the VRMs, but the rig is a caseless rig with several large fans pointing at it.

I'll let it run for another day and see if it recurs.  Note, I switched to DiabloMiner yesterday because of the elegant simplicity of running a single miner that handled all the GPUs and because your miner handled network problems better.  That said, I had been running poclbm and phoenix for more than a month without any problems like this.  Hopefully it is rare.

To your last point, so it's reasonable to run two instances of DiabloMiner at the same time?  I am used to having to do that with phoenix and poclbm to work around their poor handling of network problems and slow-to-response getwork requests.  I suppose I could even setup some cron jobs to restart each instance periodically to make sure that if one of them gets in a bad state, it gets fixed hopefully before the second one gets in a bad state.

I suppose I could also try the newest AMD driver (I am still on 11.5).

You can't check VRM temps on Linux, but if you're only at 70c, I doubt this is the problem.

I've seen phoenix and poclbm users report the infamous bug. I originally thought it was limited to just multi-GPU users, but single GPU users get it as well.

DiabloMiner's networking code never gives up. Which is great for Eligius users because the pool chokes frequently and shares fail to get delivered.

I'm not aware of 11.6 fixing this, but you can always try.
1932  Bitcoin / Pools / Re: [~3000 Gh/s Mining Pool] HTTPS,API, instant payouts,LP,+1% for NO INVALID BLOCKS on: June 21, 2011, 01:08:29 PM
Just me - or is the instant payment button not working at the moment?
Yes, I have this problem too. Maybe Tycho will clarify situation?

Probably disabled it to prevent post-mtgox bullshit.
1933  Other / CPU/GPU Bitcoin mining hardware / Re: Official DiabloMiner GPU Miner Thread (now with Long Poll and BFI_INT support) on: June 21, 2011, 12:49:44 PM
I had a problem overnight with DiabloMiner and I'm not sure if this is a known problem (couldn't find anything in a quick search).

I have two 5970s (four total GPU cores) and overnight, one of the cores went idle with DiabloMiner. I noticed long enough after it happened that any error messages were not in my scrollback buffer anymore, so I don't know what happened.

Is this a normal problem?  Restarting DiabloMiner fixed it, but I am worried that this wasn't a one time issue. 

I really hope to find a solution for this one because it is really slick to only have to run one instance of DiabloMiner vs multiple instances of phoenix/poclbm.

Assuming that your GPUs are not overheating (keep them 85c or below) and the VRMs are not overheating (which can happen with poor airflow, even at low GPU temps), then you're looking at a driver bug.

Sadly, the driver bug would even happen if you ran pheonix/poclbm. Some people work around it by running twice as many miners at once, because it doesn't freeze both of them. Its a bad hack, but it'll work until AMD fixes their shit.
1934  Bitcoin / Mining / Re: To those buying 5830's for resale on: June 21, 2011, 12:45:51 PM
Okay, this thread has gone on long enough. There are no actual posters in this thread, just trolls.

I am tired of getting this thread reported to multiple times a day.

It is now locked.
1935  Other / CPU/GPU Bitcoin mining hardware / Re: Official DiabloMiner GPU Miner Thread (now with Long Poll and BFI_INT support) on: June 20, 2011, 01:03:49 PM
I just tried the newest build, and somehow the hardware errors are around 180 instead of 180000 and speeds are as good as the old version. Whatever you did worked, thanks.

I was using the -g option with various values but I find it increases rejects and for some reason -f1 decreases the speed even though its supposed to increase it for my system.

Are the grouped rejects related to a pool specific protocol like longpoll, is that what you meant?

I have more testing and pool hopping to do later, but for now I am happy with this miner again.

I seem to have fixed the problems with nvidia hw errors, but not the extreme minority of AMD users that get it (which I still believe is a very obscure driver bug).

-g is ignored when using LP.

Grouped rejects happen on all pools no matter if they use LP or not because the client runs multiple getworks in parallel, if the pool hiccups it will hit all of them at once.
1936  Other / CPU/GPU Bitcoin mining hardware / Re: Official DiabloMiner GPU Miner Thread (now with Long Poll and BFI_INT support) on: June 18, 2011, 09:29:29 PM
BTW, yes, 0 accepts and 0 rejects are valid for solo mining. At the current difficulty it will take you about 14 weeks on average to find a block, which then accepts will turn to 1.

Disconnect your crossfire cable if you have crossfire disabled. If you're solo mining, the only thing you need to give to DiabloMiner is -u and -p, -o and -r are already set correctly by default for local solo mining.

From your description in the other thread, it almost sounds like its failing to connect to Bitcoin (which eventually will timeout) during startup.

Also, are you using a dummy plug on your second GPU? With crossfire off, Windows turns cards off, even if they're in use, when there is no monitor plugged in.

I got the bitcoin client working. It's at 48 connections and your miner is hashing. That's about all I know what to look for to be able to tell if it's working. The command I use to connect is diablominer-windows.exe -u XXXX -p XXXX -v 19 -w 192.

I have a monitor hooked up to the second card. As I said in the other thread, if I disconnect the crossfire cable I get bad core usage fluctuations according to msi afterburner. It's more stable with it connected. Crossfire is disabled in catalyst control center as well. All along I've had full load on both cards, other than fluctuations. Do I need a dummy plug? To my understanding a dummy plug is only used if you don't have a monitor hooked up. I can view the desktop on my 2nd monitor as well. Thanks again for all the help.

If you have a monitor always plugged into the second card as well, you don't need a dummy plug.
1937  Other / Beginners & Help / Re: Diablominer Pool and Solo mining question on: June 18, 2011, 05:11:27 PM
I've been battling with learning how this works for about 4 days now. I've managed to get diablominer to work for me using the api.bitcoin.cz pool. I'm not too sure on what I'm seeing at the bottom of the screen. I average around 400 mhash's, at least I think.

I'm assuming that mhash 401.1/402.8 means that 401.1 is realtime because it fluctuates and 402.8 stays the same meaning it's an average. At first I thought that those were the numbers both cards were pushing.

Anyway, I'm running 2 6850's. Crossfire is disabled. Catalyst 11.5b and sdk app 2.4. There are monitors hooked up to both cards. There's a crossfire cable in place. Both gpu's report full load according to msi afterburner. Diablominer reports that it's connected to both cores (barts 1 and 2). I start the program by going to the c drive and shift right clicking the diablominer folder to open a cmd with the path already specified. Then I type out the start command diablominer-windows.exe -u xxxxx -p xxxxx -o api.bitcoin.cz -r 8332 -v 19 -w 192.

All is well and good except for the fact that I read on here that people with single 5870's are pushing around the same hash rate as me.

I've also read on here that people are starting their miners in java directly, but, according to the original diablo3 post, I'm doing it the right way.

So, which way is the right way? Why are my 2 card's producing the same hash rate as a single card?

Another thing is that I've been 100% unsuccessful at solo mining. I have the bitcoin daemon. I start it with the -server command. It starts. I have the config created and it's right (i've tried about 4 different suggestions). When I start diablominer, it gets as far as connecting to the first gpu core and stops.

So, yeah, lol. I'm at a loss here. Any help would be greatly appreciated.



For those interested in the response, see http://forum.bitcoin.org/index.php?topic=1721.msg238127#msg238127 and http://forum.bitcoin.org/index.php?topic=1721.msg238559#msg238559
1938  Other / Beginners & Help / Re: Diablominer Pool and Solo mining question on: June 18, 2011, 05:08:36 PM
I figured out the bitcoin client problem. I just had to download the latest revision. I'm still only hashing at ~400 Mega hashes/sec. Some help would be nice...
You need to run 4 different programs, as 6xxx are 2 gpu's (pretty sure), and you have 2 of them.

Moderators should not hand out bad advice like that. Only one 6xxx is 2 GPUs, the 6990 (which is the replacement for the 5970, the only 2 GPU 5xxx). DiabloMiner supports unlimited GPUs with a single instance, so no, he needs to run 1.
1939  Other / CPU/GPU Bitcoin mining hardware / Re: Official DiabloMiner GPU Miner Thread (now with Long Poll and BFI_INT support) on: June 18, 2011, 05:07:19 PM
My math gives about 469 combined for two 6850s if you can find the right settings, but its more likely to be in the 450s because you're on SDK 2.4. A 6870 is about as fast as a 5850 at their respective stock clocks, a 6850 is about 1/3rd slower than a 6870 at their respective stock clocks, and a 5850 is about 1/4th slower than a 5870.

So 450s for two overclocked 6850s is in the right ballpark if a overclocked 5870 is doing 450.

Thanks for the info man. I needed some closure lol. I think my main problem is the power supply in my computer under volting causing fluctuation performance (600w coolermaster). I'm going to try unplugging my 2 dvd burners and my second hdd to see what happens. So do you recommend reverting to an earlier revision of sdk?

BTW, yes, 0 accepts and 0 rejects are valid for solo mining. At the current difficulty it will take you about 14 weeks on average to find a block, which then accepts will turn to 1.

Disconnect your crossfire cable if you have crossfire disabled. If you're solo mining, the only thing you need to give to DiabloMiner is -u and -p, -o and -r are already set correctly by default for local solo mining.

From your description in the other thread, it almost sounds like its failing to connect to Bitcoin (which eventually will timeout) during startup.

Also, are you using a dummy plug on your second GPU? With crossfire off, Windows turns cards off, even if they're in use, when there is no monitor plugged in.
1940  Other / CPU/GPU Bitcoin mining hardware / Re: Official DiabloMiner GPU Miner Thread (now with Long Poll and BFI_INT support) on: June 18, 2011, 03:20:57 PM
I'm pushing ~450mh/s on 2 6850's oc'd to 875 on the cores. Does that sound right? Based on what I've read on this forum, people with single 5870's push the same thing. So, in theory, I should be pushing at least 650 and at most 800. I'm running one of your recommended settings -v 19 -w 192 after hours of fishing for the sweet spot. I made a post in the newbie section, http://forum.bitcoin.org/index.php?topic=18632.0, because I was unable to post here. There's more info on the way I have things set up, in that thread. Another question I have is, is it safe to assume that your program reporting accept: 0 reject: 0 hw error: 0 is normal on solo mining? I'm guessing that it wont start processing a block until it finds one, so those numbers will remain at zero, right? I know, I'm a nub, but, you gotta crawl before you walk, lol.

My math gives about 469 combined for two 6850s if you can find the right settings, but its more likely to be in the 450s because you're on SDK 2.4. A 6870 is about as fast as a 5850 at their respective stock clocks, a 6850 is about 1/3rd slower than a 6870 at their respective stock clocks, and a 5850 is about 1/4th slower than a 5870.

So 450s for two overclocked 6850s is in the right ballpark if a overclocked 5870 is doing 450.
Pages: « 1 ... 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 [97] 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 »
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!