|
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.
|
|
|
|
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. |
|
|
|
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#msg259751http://forum.bitcoin.org/index.php?topic=6667.msg259839#msg259839I'm calling GimEEE a troll, and your reaction is exactly what he wanted. Thus, you're feeding the troll. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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 |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. 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. |
|
|
|
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. 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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
I am locking this topic. As per OpenCL specification: 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. |
|
|
|
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. |
|
|
|
Stickied.
How about un-stickying the other one? We don't need 2. I already did before making my post. But hey, whatever. |
|
|
|
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. |
|
|
|
|
Show Posts
