Phateus posted this graph:  does that look like 316 is the fastest? no, I'm pretty sure 410 is faster (vectors 2, worksize 256) right after the dip in speeds and it obviously doesn't matter that much whether you're running 300ish or 400ish clocks according to the graph Huh, I wonder what hes using for vectors, I assume he means uint4 = V4, etc. That graph is very interesting, it highlights the register spillover problem in the phatk design quite nicely. I also wonder what card that is. 5870 overclocked, and v4 is indeed uint4 Those numbers might not be entirely valid then. (Some?) 1200mhz cards do not seem to have the same timing as 1000mhz cards, so 1/4th might work better. On my 5850, the peak seems to be around 1/3rd instead, and on some 5870s from what I've heard its still 1/3rd. |
|
|
|
Phateus posted this graph: does that look like 316 is the fastest? no, I'm pretty sure 410 is faster (vectors 2, worksize 256) right after the dip in speeds and it obviously doesn't matter that much whether you're running 300ish or 400ish clocks according to the graph Huh, I wonder what hes using for vectors, I assume he means uint4 = V4, etc. That graph is very interesting, it highlights the register spillover problem in the phatk design quite nicely. I also wonder what card that is. |
|
|
|
As for the trolls, I'm ignoring them.
There's a vast difference between trolls and people gathering incontrovertible evidence of the opinions you offered in various forums about religion, homosexuality and a slew of other non-bitcoin related things. I think it's important that people who use your pool understand who you actually are, how your mind works (for some rather stretched definition of the word) and make up their own mind before they contribute anything further to the eligius effort. I am personally so disgusted by your belief system that however much I'd like to not let that get in the way of using your pool if it was the actual best around (it isn't anymore, by a large margin), I simply can't. I hope others will do their own research and come to their own conclusions. Okay so, you have a problem with that, but not that eligius.st is the Catholic Patron Saint of monies? |
|
|
|
|
OSX's OpenCL impl is so screwed up, its not really worth it. Plus, the frontend is not shipping with my most up to date version of DiabloMiner.
|
|
|
|
|
Update: Make kernel arrays an option, default to off, use -a to turn on.
This should help users that had a speed decrease after introducing phatk-like arrays, such as OSX and Nvidia and SDK 2.1 users.
|
|
|
|
As I just said to iopq, some kernels require more than others. Try 1/3rd, it will probably bring back your missing hashes.
Diablo, with cores 860,287 and 980,327 and -v 18 I now get 795-797 so it is 3-4 MHs faster than the previous version. Thanks a lot. spiccioli btw, what makes a kernel depend upon memory speed? I thought that there is no (or very very little) video memory use in hashing the bitcoin chain and, up until now, I always did lower memory clock as much I could to lower energy consumption. Well, it's not such a bad idea to keep the algorithm in memory to unroll back to the GPUs once the unroll is used up. It should be faster than referring to the system memory. Of course, if it could be unrolled straight from the GPU back to the GPU once the unrolls nearly reach their end (1 unroll away), it would be a lot better. But that would involve holding the entire code in a register or so and somehow converting it which doesn't seem all that possible. The program (the kernel) is kept loaded in graphics memory, but the compute units dump the program when it switches to something else (EVERYTHING is a program, even rendering boring 2D desktop shit). Radeons have multiple levels of graphics memory, the memory clock just controls the actual GDDR5 RAM chips (ie, the "lowest" level as far as OpenCL is concerned). Kernel arguments and constants are stored in constant RAM (which for all intents and purposes are as fast as registers), and then theres scratch RAM that belongs to the CU which can be used to backfill register overflow (which isn't controlled by the memory clock, but seems to synchronize timings in some way). There are also multiple levels of caches for the CU and the texture processing units. |
|
|
|
As I just said to iopq, some kernels require more than others. Try 1/3rd, it will probably bring back your missing hashes.
Diablo, with cores 860,287 and 980,327 and -v 18 I now get 795-797 so it is 3-4 MHs faster than the previous version. Thanks a lot. spiccioli btw, what makes a kernel depend upon memory speed? I thought that there is no (or very very little) video memory use in hashing the bitcoin chain and, up until now, I always did lower memory clock as much I could to lower energy consumption. You have a limited number of registers, and the drivers build programs that swap unused registers in and out as needed. I use far less registers than phatk, but it also nails memory timing harder, but goes faster as a result since less registers get swapped out. |
|
|
|
It seems my response got eaten. ]this is just a guideline
the fastest for me at 700 clock speed is 204 memory speed (205 gives artifacts, 210 hangs computer) with a 5750
on a 5850 the fastest with 725 clock speed is 275 memory speed, with 250 and 300 being slower
No, it isn't a guideline. 1/3rd core clock for memory clock sits in a zone that on most Radeon 5xxxes it hits the stock memory timings correctly and incurs no speed loss for applications that don't rely on memory bandwidth. If you're too low or too high, you incur a speed loss or sometimes the card just locks up. Some kernels require better compliance with this than others. They are the lowest ones that don't slow down mining.
spiccioli.
As I just said to iopq, some kernels require more than others. Try 1/3rd, it will probably bring back your missing hashes. |
|
|
|
DiabloD3,
I've downloaded latest DiabloMiner, sadly it went from 793-795 MHs on a dual GPU (5850/5870) rig (860,260/980,280 as clocks) to 445-448 MHs!!
I start it with -v 19 -l url
best regards.
spiccioli
Try -v 2 or -v 18. DiabloD3, it is still slower -v 18: 790/792 MHs -v 2 : 789/792 MHs best regards. spiccioli Btw, why are your memory clocks wrong? They should be 1/3rd of your core clock's speed. |
|
|
|
DiabloD3,
I've downloaded latest DiabloMiner, sadly it went from 793-795 MHs on a dual GPU (5850/5870) rig (860,260/980,280 as clocks) to 445-448 MHs!!
I start it with -v 19 -l url
best regards.
spiccioli
Try -v 2 or -v 18. |
|
|
|
|
Locking this thread until people pull their heads out of their asses.
|
|
|
|
OSX user here, new version is working steadily for 15 mins now, no more running wild behavior. I will keep it going for a day and see what happens, but I believe you fixed it, thanks! Do you use a variant of your original kernel again, or this this still phatk?
BTW I am still using Snow Leopard since I don't believe in 1.0 OS versions. Can anyone confirm the miner working on Lion?
It never really was pure phatk to begin with. I tried to phatk-arize the existing kernel, but it ended up causing more work and problems than it was worth. It is still phatk-ized, but in a way that properly uses the technique (something phateus himself doesn't yet). What technique is that? Oh! And hey, what do you think of compressing the initial tables by utilizing the difference between the current and previous values in the table instead of the actual values? I know that it might add a slight overhead on the addition/subtraction, but it would decrease the amount of memory that would need to be read before running the calculations and might allow for another unroll or two. The phatk technique is... to use an array. Thats it. Those arguments are loaded into constant memory, which is as fast as registers but is workgroup wide. You can't win that way. |
|
|
|
OSX user here, new version is working steadily for 15 mins now, no more running wild behavior. I will keep it going for a day and see what happens, but I believe you fixed it, thanks! Do you use a variant of your original kernel again, or this this still phatk?
BTW I am still using Snow Leopard since I don't believe in 1.0 OS versions. Can anyone confirm the miner working on Lion?
It never really was pure phatk to begin with. I tried to phatk-arize the existing kernel, but it ended up causing more work and problems than it was worth. It is still phatk-ized, but in a way that properly uses the technique (something phateus himself doesn't yet). |
|
|
|
|
Update: Increase speed 1.3% on SDK 2.1 and 0.2% on SDK 2.5, use Deque instead of AtomicReference for incoming new work
OSX users: Test to see if the new kernel fixes things or makes it faster.
|
|
|
|
I have a technical question for the developer; At ABCPool we have at least one user experiencing problems when connecting with Diablominer. Part of it pertains to Long Polling; ABCPool times out LP connections with an empty HTTP 200 response after 50 seconds to prevent defunct LP connections from causing delays when a new block is found. When this happens, DiabloMiner prints [8/18/11 10:22:18 AM] ERROR: Cannot connect to pool.abcpool.co: Bitcoin disconnected during response: 200 ok
Is it possible that DiabloMiner gets confused by these timeouts? I'm wondering, is there another way for ABCPool to gracefully timeout the connection in a way that DiabloMiner remains happy? BTW: The way Phoenix handles such a timeout seems OK: It silently reconnects. Is there a way to get similar behaviour from DiabloMiner? Timing an LP connection out is still an error. LP is meant to be kept open until the next block appears. DiabloMiner can handle pools that lag badly during LP return, due to significant testing on Eligius when they had that problem. |
|
|
|
Hey, I keep getting this error when I run the miner. Exception in thread "main" java.lang.NullPointerException
at com.diablominer.DiabloMiner.DiabloMiner.execute(DiabloMiner.java:329)
at com.diablominer.DiabloMiner.DiabloMiner.main(DiabloMiner.java:137) Are you sure you're using the newest version? 137 doesn't look like it can do that. First thing I checked. This was a fresh download. Sorry, I'm blind. Its 329, I dunno why I didn't see that line. What command line are you giving it? Its wrong, but I should be handling that error properly. C:\Users\D337z\Desktop\bitcoin\DiabloMiner>DiabloMiner-Windows.exe -D 0 -v 2 -l http://pit.deepbit.net -r 8332 -u [myusername] -p [mypassword] -w 128 Good news, I can replicate the bug. Bad news, I'm busy trying to make the kernel go faster so my next patch won't be a fix for this Good news, use -l http://username:password@pit.deepbit.net:8332/ until I fix it |
|
|
|
200 ok
I am thinking a pool issue. I bet their HTTP implementation is very wrong. |
|
|
|
Hey, I keep getting this error when I run the miner. Exception in thread "main" java.lang.NullPointerException
at com.diablominer.DiabloMiner.DiabloMiner.execute(DiabloMiner.java:329)
at com.diablominer.DiabloMiner.DiabloMiner.main(DiabloMiner.java:137) Are you sure you're using the newest version? 137 doesn't look like it can do that. First thing I checked. This was a fresh download. Sorry, I'm blind. Its 329, I dunno why I didn't see that line. What command line are you giving it? Its wrong, but I should be handling that error properly. C:\Users\D337z\Desktop\bitcoin\DiabloMiner>DiabloMiner-Windows.exe -D 0 -v 2 -l http://pit.deepbit.net -r 8332 -u [myusername] -p [mypassword] -w 128 -D 0 isn't valid, card numbers start at 1. Tell me if that fixes it. |
|
|
|
Hey, I keep getting this error when I run the miner. Exception in thread "main" java.lang.NullPointerException
at com.diablominer.DiabloMiner.DiabloMiner.execute(DiabloMiner.java:329)
at com.diablominer.DiabloMiner.DiabloMiner.main(DiabloMiner.java:137) Are you sure you're using the newest version? 137 doesn't look like it can do that. First thing I checked. This was a fresh download. Sorry, I'm blind. Its 329, I dunno why I didn't see that line. What command line are you giving it? Its wrong, but I should be handling that error properly. |
|
|
|
Hey, I keep getting this error when I run the miner. Exception in thread "main" java.lang.NullPointerException
at com.diablominer.DiabloMiner.DiabloMiner.execute(DiabloMiner.java:329)
at com.diablominer.DiabloMiner.DiabloMiner.main(DiabloMiner.java:137) Are you sure you're using the newest version? 137 doesn't look like it can do that. |
|
|
|
|
Show Posts
