Diablo, I had Catalyst 11.1 installed. I did a complete uninstall and installed Catalyst 10.12. There is no change to the miner's behavior. The speed remains the same, and it continues to crash within minutes when using the default worksize of 256.
When I override worksize to 64, the speed drops from 13200 khash/sec to 4700 khash/sec, and it still crashes.
Somethings very wrong with your box. If you figure out what, tell me. |
|
|
|
|
pmw, tryptamine, make sure both of you aren't using Catalyst 11.1. It doesn't work right. Also make sure you're using SDK 2.1. Also, for some users you absolutely need to use -w 64, the hw default (256 on ATI) doesn't like Art's kernel.
|
|
|
|
Also, when I get messages like Block 1 found, Block 2 found, does that mean I generated a block...?
edit: it looks like this.
[2/10/11 11:52:36 AM] Block 1 found on GeForce 9600 GT (#1)
Yup, unless you're on a pool, then thats a pool share. |
|
|
|
Just want to say thanks for the info in this thread, I got it working and even have figured out how to have a few different batch files for different levels of hashing (-w 32 -f 1000 versus -w 512 -f 1)
Just want to report that I have a 9600 GT 1GB from MSI on Windows 7 x64, and if I increase the -w flag it goes up for each interval. At 32 I'm getting like 8600k but at 512 I get almost 150k.
Good work on this one, it's quite an improvement over my CPU's 4k (and I've got an AMD quad!).
oh, one thing. I noticed some talk about -v flags but the program doesn't recognize any. I assume they were simply removed from implementation?
Nvidia handles -w weird. Some cards have a minimum of 32, some have 64, and there is no way to query this and there doesn't seem to be a list out there. If -w 32 is extremely slow, don't use it. And yes, -v has been removed. It doesn't increase speed on properly functioning OpenCL compilers. |
|
|
|
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/humble/warez/DiabloMiner/target/libs/natives/linux/liblwjgl.so: /usr/lib/jvm/java-6-sun-1.6.0.22/jre/lib/i386/libjawt.so: symbol awt_FreeDrawingSurface, version SUNWprivate_1.1 not defined in file libmawt.so with link time reference
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
Anybody found an always effective workaround for this problem ? I'm finding it hard to fix it, though only certain machines have the issue Display already set to :0. Will using openjdk-6-jre-headless solve it ? Using FC14 at this time, thinking on switching to Ubuntu, not sure if that will help. The only way to get that issue is if you don't have X running. Just setting DISPLAY isn't enough and using headless makes it worse. This is an unfortunate bug in Java triggered by how LWJGL works; it shouldn't happen. On ATI you need X running anyhow, on Nvidia you can run a dummy X (such as xvfb). |
|
|
|
Looping doesn't cause the 3% performance boost if thats what you're asking. I see it on my 4xxx, and looping isn't enabled on 4xxx. Looping is probably another, eh, half a percent or so. My bad, the meter is fluctuating a bit more, I'll check if it stabilizes. The first meter measures whats going on now, the second meter measures the performance since the start of the miner. If you intend on benchmarking, do -f 1 and read the second meter after 15 minutes. |
|
|
|
Update: Fix bug on Radeon 5xxx looping
Does this justify a 3% performance increase? I'm not sure how precise the hash meter is. Looping doesn't cause the 3% performance boost if thats what you're asking. I see it on my 4xxx, and looping isn't enabled on 4xxx. Looping is probably another, eh, half a percent or so. |
|
|
|
|
Update: Fix bug on Radeon 5xxx looping
|
|
|
|
|
I've updated my miner to reduce share loss in pool situations. Update to newest.
|
|
|
|
|
Update: Use multiple buckets on output to reduce lost pool shares
Roughly 3.5% of shares are lost (due to bucket cramming) on a 5870 on -f 1... its far less for slower cards or high -f values. It is now 256 times less. I can live with 0.02% lost.
|
|
|
|
|
Except thats not what he said at all. m0's kernel ALSO runs best at -w 64 and low -f settings. -f controls kernel execution length; ANY kernel will run better with lower -f settings because there is far less time wasted on kernel setup overhead.
10.12 may or may not cause issues for some people. Downgrading to 10.11 should fix them for the few people that have them.
|
|
|
|
Art's miner is great, but not without disadvantages. At -f 30 it is significantly slower than the original miner. At -f 2 it is faster, but the desktop is useless for interactive work. Could we have an option to use the old miner? Perhaps even an option where DiabloMiner switches miner when it has to slow down due to desktop activity, and changes back to Art's miner with -f 1 when the screensaver is on?
Its just a kernel switch. The kernel does not have control over what you describe, so what you describe is impossible.... if Art's miner performs badly, it will perform badly no matter the -f setting. Art's kernel DOES drive the hardware (3%) harder, so it MAY require a larger -f number to keep the same desktop interactivity, but thats about it. Also, if you are using 11.1, don't. Also, -f 30 sounds rather low for keeping your desktop interactive. |
|
|
|
|
Update: Changed to 15 sec avg/forever double meter, further decreased run size floor, allow very maximum nonce before saturation flush
|
|
|
|
|
The miner, even with -f 1, tries to adjust to system activity. I use -f 1000 on my 4850 now, and it swings wildly in all sorts of directions when I'm using my computer.... this is by design. Most people want to mine while having a useful desktop. -f 1 curbs this behavior as much as possible, but obviously does not eliminate it.
|
|
|
|
|
Connections to the miner when they lag (such as connection failures) confuses the miner. If thats a long count hash, thats completely inaccurate... it could have flatlined completely to 0.
|
|
|
|
With dual cards, my hash/sec are all over the place. It never settles in to a steady rate. (running locally)
As I said to cdecker, if you're benchmarking use -f 1 |
|
|
|
|
Hmm, are you connecting locally or to slush's pool?
|
|
|
|
|
Use below -f 5, my miner counts hash performance from start, instead of using a 30 second average. If you're seriously benchmarking it, use -f 1 and let it run for like 15 minutes.
|
|
|
|
|
Run the miner with --help. The only tuning switches are -w and -f, -w changes worksize (on ATI it has to be a multiple of 64, 64 seems to be the fastest, 256 is the default; on NVidia it has to be a multiple of 32, and all values seem to work exactly alike), -f changes how long the kernel runs (FPS, the lower the value the longer it runs, -f 1 has the least overhead but also destroys desktop interactivity).
|
|
|
|
Wow, just pulled the latest commit, added my JMX patch and started the worker again and it maxes out at 14 Mhash/s on my 5850, whereas I got 254 Mhash/s before. Somewhere I got a problem ^^ I'll try to track it down next week  My 5770 was pulling about 15 MH/s until I set "-w 64", then it goes back to the expected 150 MH/s. Thats the problem though. There should be no reason -w 256 (the default on ATI hardware) should be THAT slower. It is slower for OpenCL kernels like the one I use in the miner, but it should be still >100. |
|
|
|
|
Show Posts
