DiabloMiner GPU Miner

[d3m0n1q_733rz]

Hey, I keep getting this error when I run the miner.

Code:

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

My friend, I like your thinking.  Good news, I think that will work.  Bad news, I hated having to do that with Phoenix Miner, now I have to do it with Diablo Miner too.  T_T  Good news, I have Dr. Pepper beside me right now so I don't care.  ^_^

[1714221550]

1714221550

[1714221550]

1714221550

[1714221550]

1714221550

[DiabloD3]

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

Code:

[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.

[DiabloD3]

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.

[kaosbit]

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?

[DiabloD3]

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).

[d3m0n1q_733rz]

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.

[Druas]

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.

Past versions have performed slightly better Mhash-wise. I actually saw a decrease in speed with this version, so I will probably use an older version since I never had the problems others have had with the older versions.

[DiabloD3]

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.

[spiccioli]

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

[DiabloD3]

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.

[spiccioli]

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

[DiabloD3]

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.

[iopq]

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.

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

[spiccioli]

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.

They are the lowest ones that don't slow down mining.

spiccioli.

[DiabloD3]

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.

[iopq]

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.

except it is a guideline, because my 5750 is not stable with memory at 233 mhz
my 5850 card is faster as slightly more than 1/3, its core clock is is 725 and 275 is faster than both 242 and 300

you can blame the kernel, but phatk 2.2 is the fastest kernel on both cards and those timings are the fastest timings in practice

[spiccioli]

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.

[d3m0n1q_733rz]

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.

[DiabloD3]

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.

[DiabloD3]

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.