Bitcoin Forum
August 20, 2018, 05:41:36 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 45 46 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 »
1881  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking) on: July 03, 2011, 02:03:28 AM
Update: Finished adding all the old optimizations, increase speed like 1-2%

Although, I seem to be at the limit here. I went from 378 to 379 on SDK 2.1. I think I'll work on undoing more frankenkernel insanity later.
1882  Bitcoin / Mining / Re: Missing threads, blame Theymos on: July 01, 2011, 05:37:18 AM
lol sorry I'm not sure I quite understand your comment. Are you calling me a troll because I questioned the ethical nature of your comments or am I misunderstanding somehow?
http://forum.bitcoin.org/index.php?topic=6667.msg259751#msg259751
http://forum.bitcoin.org/index.php?topic=6667.msg259839#msg259839

Thanks for the research, unfortunately most posters go from the gut with emotion rather than facts.

I hope facts will help stop this authoritarian troll.
Is it just me or does Diablo seem way to immature to manage even a single thread?

Uh-Oh, time to get censored. . .

You do realize every time you report a post I make, it gets reported to me since I' the mod for the mining section? I thought you would have figured that out after second time.
1883  Bitcoin / Mining / Re: Missing threads, blame Theymos on: July 01, 2011, 02:39:15 AM


I almost always fight for the underdog so...

I don't think a moderator should advocate the seizure of GimEEE's bitcoins he was owed as was done in the Eligius pool thread. There may have been more to the story and who knows who was right, but frankly how do you trust a forum when the moderator recommends taking the bitcoins owed for either the pool or himself and continually calls you a troll...

;o) Muahahahahaha



I already acknowledged that there may have been discrepancies in what was owed whom or for what reason. But I seriously question an authoritarian moderator. IMO a moderator should not take sides so blatantly.

Forum rule: Don't feed the trolls.

lol sorry I'm not sure I quite understand your comment. Are you calling me a troll because I questioned the ethical nature of your comments or am I misunderstanding somehow?

http://forum.bitcoin.org/index.php?topic=6667.msg259751#msg259751
http://forum.bitcoin.org/index.php?topic=6667.msg259839#msg259839


I'm calling GimEEE a troll, and your reaction is exactly what he wanted. Thus, you're feeding the troll.
1884  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking) on: July 01, 2011, 02:38:40 AM
I think you mean keepalive support. DiabloMiner supports keepalive, and the use of it does not effect rejections either way.

It sounds like bitcoins.lc screwed something up.

Running with debug now, seeing "Forcing getwork update due to nonce saturation" in bursts of 8-10 at once, does that provide any hints?

Nope, only that you seem to have 4 or 5 GPUs.

6 GPUs on this one, holing off turning on other 2 GPUs until I get this under control.... bitcoins.lc is looking at it to see what they can figure out, thanks for your help. It seems it's not an issue is a run a worker per GPU keeping the per worker hash rate lower.

While I I'm posting quick note on another topic, I remember seeing a post stating -f 0 was not a good idea, I always run that on my poclbm miners, any insight on what it should be for dedicated cards on a headless system?

If it is 6, you should be seeing about 12 in a burst.

-f 1 is recommended, it'll push it up significantly.

As miner per GPU, this won't fix your problem. It sounds like their patch just doesn't work right. I use a single networking thread to process all async getworks, and a single thread to process all async sendworks (ie, two threads total). If it is trying to pair stuff to TCP sessions, then it is 100% broken, and the guy that wrote the patch doesn't understand how HTTP works either.
1885  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking) on: July 01, 2011, 02:27:26 AM
I think you mean keepalive support. DiabloMiner supports keepalive, and the use of it does not effect rejections either way.

It sounds like bitcoins.lc screwed something up.

Running with debug now, seeing "Forcing getwork update due to nonce saturation" in bursts of 8-10 at once, does that provide any hints?

Nope, only that you seem to have 4 or 5 GPUs.
1886  Bitcoin / Mining / Re: Missing threads, blame Theymos on: July 01, 2011, 02:13:34 AM


I almost always fight for the underdog so...

I don't think a moderator should advocate the seizure of GimEEE's bitcoins he was owed as was done in the Eligius pool thread. There may have been more to the story and who knows who was right, but frankly how do you trust a forum when the moderator recommends taking the bitcoins owed for either the pool or himself and continually calls you a troll...

;o) Muahahahahaha



I already acknowledged that there may have been discrepancies in what was owed whom or for what reason. But I seriously question an authoritarian moderator. IMO a moderator should not take sides so blatantly.

Forum rule: Don't feed the trolls.
1887  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking) on: July 01, 2011, 02:01:25 AM
I didn't see this coming but it seems since bitcoins.lc patched their bitcoind to add support for socket reuse my primary rig running Diablo started getting 15% rejects. It seems my miners running 400Mh/s or so are alright but my main rig running at 2.3Gh/s is having a really hard time, other pools are no problems but bitcoins.lc is hating that speed on one worker. The backend is pushpool.

How would I go about running an instance per GPU or something similar, I hate the idea of doing it but it looks like that might be the only option?

I think you mean keepalive support. DiabloMiner supports keepalive, and the use of it does not effect rejections either way.

It sounds like bitcoins.lc screwed something up.
1888  Bitcoin / Mining / Re: Missing threads, blame Theymos on: July 01, 2011, 01:58:06 AM
So who's to blame here, we need to find a target to point fingers at.
Either the DB got corrupted (say, per post unique IDs were not unique or other mysql sillyness), or SMF writes shitty software.
Theymos's screenshot shows the forum thought I deleted 4 threads, when I deleted 1 post (another GimEEE troll post).
Speaking of which, hey Theymos, why isn't he banned yet? A lot of people have asked, including me.
Evidence or I'm calling troll on you (again, because authoritarian deleted the last time I called you out).
You trolled me above here with inadequate evidence.
Even worse, I'm calling you an authoritarian censor, evidence above in this thread!

There's a right way to settle disputes, and abusing censorship privileges is not right.

You need evidence that you're the laughing stock of the forums? LOL

I almost always fight for the underdog so...

I don't think a moderator should advocate the seizure of GimEEE's bitcoins he was owed as was done in the Eligius pool thread. There may have been more to the story and who knows who was right, but frankly how do you trust a forum when the moderator recommends taking the bitcoins owed for either the pool or himself and continually calls you a troll...

;o) Muahahahahaha



There is a slight problem. GimEEE is not owed any BTC from Eligius. All US server payments have been paid out as far as I know, and GimEEE has none on the EU server. He is just trolling, pure and simple.
1889  Bitcoin / Mining / Re: Missing threads, blame Theymos on: July 01, 2011, 12:53:38 AM
So who's to blame here, we need to find a target to point fingers at.
Either the DB got corrupted (say, per post unique IDs were not unique or other mysql sillyness), or SMF writes shitty software.
Theymos's screenshot shows the forum thought I deleted 4 threads, when I deleted 1 post (another GimEEE troll post).
Speaking of which, hey Theymos, why isn't he banned yet? A lot of people have asked, including me.
Evidence or I'm calling troll on you (again, because authoritarian deleted the last time I called you out).
You trolled me above here with inadequate evidence.
Even worse, I'm calling you an authoritarian censor, evidence above in this thread!

There's a right way to settle disputes, and abusing censorship privileges is not right.

You need evidence that you're the laughing stock of the forums? LOL
1890  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking) on: June 30, 2011, 01:48:51 PM
Is it possible to make it so that if connection is lost, instead of losing any found blocks, store them and try to submit them when connection is resumed? They may end up being rejected, if it was a long period of no ocnnectivity, but it's more likely that they'll be good?

Yes it is possible, seeing as DiabloMiner already does this. DiabloMiner will submit a share no matter what, mere network problems will not stop it.
1891  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking) on: June 30, 2011, 01:48:08 PM
the latest diablo miner is 2mh/s faster than poclbm on my card! I even patched the maj function
edit: but I'm getting a third of my shares rejected lolwat

Because it was already patched.
1892  Bitcoin / Pools / Re: [76 GH/sec] MineCo.in - LP,EU Server,SSL,JSON API,0% TAX on: June 30, 2011, 01:46:19 PM
For me, phoenix never worked reliably with network connections. Long Polling would die after a few hours every time (=> no more LP: work pushed). And sometimes it would fail to get new work from the pool, sitting idle until restart.

So maybe you should try poclbm+phatk and see if it works.

Or use DiabloMiner which has much better networking code.
1893  Bitcoin / Mining software (miners) / Re: 3% faster mining with phoenix+phatk, diablo, or poclbm for everyone on: June 30, 2011, 01:42:04 PM
On normal Radeons at stock clocks and voltages, and are not overheating, have a known error rate (which is something like 1 error per several hundred million instructions)

One error per several hundred million instructions... where are you getting that information from? (an honest question, I'd like to learn more)

A 58xx series, from information I can find, can do between one and four instructions per clock.  If it is clocked at 775000000 cycles per second (775 MHz), that's up to 3.1 billion instructions per second.  So according to your information there would be many errors per second.

I think I meant 1 per several hundred billion. Its in the chip specification somewhere, ask AMD.

Quote
a silicon chip is not supposed to have errors, and will only occur if: incorrect voltage, incorrect temperature range, the silicon chip itself is faulty, something extremely rare such as a cosmic ray bouncing off and [in the case of RAM] 'flipping a bit' perhaps once every few weeks

Bzzt, wrong. GPU hardware does not use the same manufacturing process CPU hardware typically does. GPUs are not mission critical hardware, and rare calculation errors are considered acceptable.

You are correct about "incorrect" voltage, however you assume that it is incorrect at all. The professional versions of these cards run at lower clock rates and lower voltages to reduce the error rate. Consumer cards are not ran at incorrect settings, they are merely ran at settings that lead to acceptable levels of errors.

This is shown up quite well if you run something like Folding or Seti on your GPU, you will notice a lot more invalid work showing up than you do using the CPU variant and has far as I am aware work for these two does not expire within any reasonable length of time unlike bitcoin so these are actually invalid results and not just "stale".

No, its invalid on mining as well. My miner has a HW error counter, it only ticks up when the HW produces a hash it thinks produces H == 0, but when double checked it doesn't.
1894  Bitcoin / Mining software (miners) / Re: 3% faster mining with phoenix+phatk, diablo, or poclbm for everyone on: June 30, 2011, 05:31:16 AM
On normal Radeons at stock clocks and voltages, and are not overheating, have a known error rate (which is something like 1 error per several hundred million instructions)

One error per several hundred million instructions... where are you getting that information from? (an honest question, I'd like to learn more)

A 58xx series, from information I can find, can do between one and four instructions per clock.  If it is clocked at 775000000 cycles per second (775 MHz), that's up to 3.1 billion instructions per second.  So according to your information there would be many errors per second.

I think I meant 1 per several hundred billion. Its in the chip specification somewhere, ask AMD.

Quote
a silicon chip is not supposed to have errors, and will only occur if: incorrect voltage, incorrect temperature range, the silicon chip itself is faulty, something extremely rare such as a cosmic ray bouncing off and [in the case of RAM] 'flipping a bit' perhaps once every few weeks

Bzzt, wrong. GPU hardware does not use the same manufacturing process CPU hardware typically does. GPUs are not mission critical hardware, and rare calculation errors are considered acceptable.

You are correct about "incorrect" voltage, however you assume that it is incorrect at all. The professional versions of these cards run at lower clock rates and lower voltages to reduce the error rate. Consumer cards are not ran at incorrect settings, they are merely ran at settings that lead to acceptable levels of errors.
1895  Bitcoin / Mining software (miners) / Re: 3% faster mining with phoenix+phatk, diablo, or poclbm for everyone on: June 29, 2011, 10:27:00 PM
Diablo showed very very few hardware errors (according to the forums, it was low .. less than 3 in 1000 for any card, and in some one case only 1 in ~2000)

Hardware errors?  Any hardware error means you've pushed the boundaries of either: voltage, clock speed, or heat...  Reduce one

No it doesn't.  Go read carefully.  Hardware checks are turned off intentionally by Diablo (and I believe all GPU mining software)

I'll cut you off there. You cannot shut off error correction via OpenCL, not that there is any to actually shut off.

The only thing I shut off is HW error message spamming when BFI_INT is on (because BFI_INT is a large hack and certain usages confuse the driver). HW error checking is still enabled in the miner, and the counter still ticks up.

1896  Bitcoin / Mining software (miners) / Re: 3% faster mining with phoenix+phatk, diablo, or poclbm for everyone on: June 29, 2011, 10:21:29 PM
No it doesn't.  Go read carefully. there are always going to be occasional hardware errors for this kind of thing

All this writing and all I really said is that hardware errors are normal and does occur with ALL GPUs.

I'm sorry Veldy but you're incorrect

GDDR5 does have error correction however, which is why you can push it past its boundaries and not crash, but will get reduced performance from all the error-corrections.  

Aside from GDDR5 and specific ECC ram, any hardware error would cause huge problems up to and including system lockup. Later operating systems (Win7 in my case) have gotten better at coping though, if you're lucky you get a "Display Driver has Stopped Working" error and not a hard-freeze.

Edit: I'll just edit this post in response to the one below to avoid spamming this thread with offtopic posts to say that we'll just agree to disagree

Consumer GPUs do not use ECC-enabled GDDR5.

The HW errors, however, are caused by naturally unstable hardware. On normal Radeons at stock clocks and voltages, and are not overheating, have a known error rate (which is something like 1 error per several hundred million instructions), and do not have excessive (or really, any) internal checks.

This is not a defect in the hardware. GPUs are for playing video games. Scientific apps that are searching for a needle in a haystack (such as what we do) double check the result.
1897  Bitcoin / Mining software (miners) / Re: another 3% mining increase with poclbm kernel.cl on: June 29, 2011, 09:51:11 PM
I am locking this topic.

As per OpenCL specification:

Quote
6.5.2 __local (or local)
The __local or local address space name is used to describe variables that need to be
allocated in local memory and are shared by all work-items of a work-group. This qualifier can
be used with arguments to functions (including __kernel functions) declared as pointers, or
with variables declared inside a __kernel function.

6.5.4 __private (or private)
All variables inside a function (including __kernel functions), or passed into the function as
arguments are in the __private or private address space. Variables declared as pointers
are considered to point to the __private address space if an address space qualifier is not
specified except for arguments declared to be of type image2d_t and image3d_t which
implicitly point to the __global address space.

In other words, the hardware threads are stomping each others work and producing nonsense.
1898  Other / CPU/GPU Bitcoin mining hardware / Re: DiabloMiner GPU Miner (Long Poll, BFI_INT, and never fail async networking) on: June 29, 2011, 09:42:40 PM
He alternates the buffer so the kernel can be executing on a different buffer at the same time as the buffer read on the other. They can both execute out of order. If it happens to run out of order, anyways.

Oddly, no. I do that by using two (formerly three) threads, each thread having its own queue.

So, that would be 4 (formerly 6) buffers.

The problem is the Radeon driver sometimes does not finish copying the buffer quickly due to system IO load (since SDK 2.1 does not support DMA, nor does 2.4 on Linux). Alternating buffer (which costs me nothing) means I can schedule the kernel execution without having to wait for the previously used buffer to unlock.

So, its executing in parallel, just out strictly out of order.
1899  Bitcoin / Pools / Re: [350 GH/s] "Eligius" (experimental) pool: almost feeless PPS, hoppers welcome on: June 28, 2011, 09:45:12 PM
Stickied.

How about un-stickying the other one? We don't need 2.

I already did before making my post. But hey, whatever.
1900  Bitcoin / Mining / Re: Missing threads, blame Theymos on: June 28, 2011, 09:44:12 PM
So who's to blame here, we need to find a target to point fingers at.

Either the DB got corrupted (say, per post unique IDs were not unique or other mysql sillyness), or SMF writes shitty software.

Theymos's screenshot shows the forum thought I deleted 4 threads, when I deleted 1 post (another GimEEE troll post).

Speaking of which, hey Theymos, why isn't he banned yet? A lot of people have asked, including me.
Pages: « 1 ... 45 46 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!