I got my 5850 Toxic 1Gb to 418Mhash @ 1055 Core, 375 Mem and 1.25V.
That was on XP though and after I changed to W7 the diriver started to crash at 1025 Core..
Note that at that voltage it's less efficient than a 5870 but I just wanted to test how high it could go :3 (Temps were never above 65C though, Vapor-x <3)
Yes, increasing voltage can hurt power consumption in a big way. There's certainly room for improvement in software though. A 1055 core should be able to manage more than 430 MH/s with a little tweaking. I'm impressed with the cooling though. 65*C on a 5850 1055/375@1.25V is very good. |
|
|
|
I had momentarily forgotten about changing the worksize, thanks for the reminder!  Changed to 256, and now hashing at 405 MH/s, will do some more tweaking later today. No worries. I hope you manage to get a little more out of that card with tips mentioned on this thread. I'm currently trying to improve further. I believe it's possible to get quite a bit more because Tx2000 is able to get a staggering 413 MH/s at only 970 MHz! Granted, this is on Windows, and I have a suspicion that he's using Catalyst 11.7, but if he's not then there's surely some trick he's using for the extra 12 MH/s. My good card has been running at 1025 MHz for over 12 hours now and is perfectly fine. I think being kept very cool is good for it's stability (at these clocks 60*C is far too high). I'm getting impatient so time to go to 1030 MHz. |
|
|
|
|
Excellent.
It looks like this SDK 2.1 bugfix is popular! Perhaps now people will stop telling me to use SDK 2.4.
Thanks Diapolo for the fix and I'm glad I was able to help.
|
|
|
|
Ah sorry, I was not clear enough. You must not add (u) in front of every hex value in the kernel, but ONLY in front of the hex values, that generated an error.
You were perfectly clear, I was just being dumb. Incase you missed my second post, this fix works for SDK 2.1. Thank you very much. |
|
|
|
With help from Diapolo I've modified the latest phatk kernel to work with SDK 2.1 and the result is another 2.1 MH/s for the 1GHz 5850s. Now I'm able to achieve 415.4 (+/- 0.1) MH/s. See http://forum.bitcoin.org/index.php?topic=25860 for details. |
|
|
|
You could try to add (u) in front of the raw hex values like (u)0x400022 and report back then.
Dia
Sorry about that last post. I'm not usually that dumb I assure you. I've modified your kernel code by adding (u) before each of the 5 raw hex values corresponding to the error messages. I also added (u) directly before L from the other error message. After this everything starts working in SDK 2.1. For my stock voltage 5850: 423.7 (+/- 0.1) MH/s -> 425.9 (+/- 0.05) MH/s This does of course mean that SDK 2.1 has increased its lead against SDK 2.4 for me. So many people are convinced that SDK 2.4 is faster so perhaps this is a Windows/Linux thing. If this runs for 24 hours without freezing then I have a new personal best! I will want to test what proportion of these hashes are inaccurate but things are looking good. Another donation is coming your way. |
|
|
|
what agression is for?
can we put AGRESSION 999 for exemple?
Aggression tells the miner how much work you want to do per OpenCL instruction. The formula is nonces = 2^(16 + AGGRESSION). So AGGRESION=14 will be about 1'000'000'000 nonces per OpenCL instruction (which I believe takes about 2.5 seconds at 1GHz core on a 5850 - hence the rather slow rate updates). AGGRESSION 15 will be twice as much work per OpenCL instruction and your rate will change once every 5 seconds or so. I chose AGGRESSION=16 because 2^32 is a nice round number and I get about 0.2 MH/s compared to AGGRESSION=14. For a dedicated rig I don't think increasing the AGGRESSION to 16 is going to hurt (might even help) stability but for a miner you want to use for other tasks it is completely ridiculous and 11 or below is more suitable. I use AGGRESSION to reduce jitter (reported hash rate variance). |
|
|
|
Ok, here are the errors for the latest kernel on SDK 2.1. { Build on <pyopencl.Device 'Cypress' at 0x34a3680>: /tmp/OCLthVTDN.cl(126): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) W[19] = P4(19) + 0x11002000 + P1(19); ^ /tmp/OCLthVTDN.cl(138): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) W[30] = P3(30) + 0xA00055 + P1(30); ^ /tmp/OCLthVTDN.cl(261): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) Vals[3] = L + W[64]; ^ /tmp/OCLthVTDN.cl(286): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) W[81] = P4(81) + P2(81) + 0xA00000; ^ /tmp/OCLthVTDN.cl(299): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) W[87] = P4(87) + P3(87) + 0x11002000 + P1(87); ^ /tmp/OCLthVTDN.cl(316): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) W[94] = P3(94) + 0x400022 + P1(94); ^ 6 errors detected in the compilation of "/tmp/OCLthVTDN.cl". } Hopefully this is just some implicit casting of a kind which SDK 2.1 wants to be babied through. If I were versed in OpenCL I'd have a go at fixing this myself but I'm sure you would be much more efficient. You could try to add (u) in front of the raw hex values like (u)0x400022 and report back then. Dia No good. Now I get a ton of "expression must have a constant value" errors. The end of the log looks like: { /tmp/OCLgV3our.cl(25): error: expression must have a constant value (u)0x6a09e667, (u)0xbb67ae85, (u)0x3c6ef372, (u)0x510e527f, (u)0x9b05688c, (u)0x1f83d9ab, (u)0xfc08884d, (u)0x5be0cd19 ^ /tmp/OCLgV3our.cl(29): error: expression must have a constant value __constant ulong L = (u)0x198c7e2a2; ^ /tmp/OCLgV3our.cl(261): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) Vals[3] = L + W[64]; ^ 74 errors detected in the compilation of "/tmp/OCLgV3our.cl". } Only one of the "mixed vector-scalar operation" errors remains but I'm guessing the others are still there but just buried by the even more urgent "constant value" errors. |
|
|
|
Greetings, 5850 owners.  I am dropping in to tell you the true tale of the non-reference XFX 5850 (this one: http://www.newegg.com/Product/Product.aspx?Item=N82E16814150477&cm_re=xfx_5850-_-14-150-477-_-Product) that I purchased for $100 on Craigslist. The first night I ran it, the fan broke so that it was no longer speed-adjustable, and stayed at 1100 RPM at all times. This made it quite unsuitable for mining, of course. I communicated with XFX's customer services representatives several times, but was unable to obtain the necessary RMA. I ended up buying the Arctic Cooling Twin Turbo Pro, which fits perfectly and works like.....well, it just works. So well does it work, in fact, that I slowly increased the core clock speed, and it did not freeze until 1035 MHz (410 MH/s)! Right now, I am running it at 1000 MHz (398 MH/s), just to be safe. Note that this is at STOCK VOLTAGE, and has not exceeded 64 degrees C at any time! I think I got a lucky card.  Miner Settings: Phoenix, phatk (latest optimized version), worksize=128, aggression=11 Wow! My best card froze at 1025 MHz. Perhaps the XFX cards are a bit better at overclocking than the Sapphire Xtremes, perhaps you have a lucky card, perhaps you have a more stability inducing configuration than my own. I'm assuming your XFX's stock voltage is indeed 1.0875V. I'd be very interested to learn about your configuration, are you using Windows or Linux? Inspired by this I've clocked my good card up to 1025 MHz again to see if it lasts longer this time. I wonder if keeping the card very cool affects stability, I'll keep my card under 50*C and see if it can hold 1025 MHz for 24 hours. I'm only 5 mins in but already 423.7 MH/s feels good . How long did your card last at 1030MHz before you decided to increase the clock? Here is that WORKSIZE=128 again. I simply cannot figure this out; WORKSIZE=256 is always about 10 MH/s faster for me no matter what my other settings are. I guess there's an outside chance that this is a Windows/Linux difference. If you check up the thread you'll find whopper and I competing for the highest hash rate for a 1000MHz card and ended up agreeing that 412-413 is currently achieveable. Perhaps you can give our settings a go and realise 410MH/s once more! At the moment I'm using: RAM=360 MHz, SDK 2.1, Catalyst 11.6, basic phatk with just the MA patch (3%), AGGRESSION=16, WORKSIZE=256, VECTORS, BFI_INT, FASTLOOP=false. although swapping out SDK 2.1 for SDK 2.4 and 'basic phatk with MA patch' for 'latest phatk patches' is only 0.6 MH/s slower for me at these core speeds and may be much easier for you to try. |
|
|
|
I simply let aticonfig generate the xorg.conf for me, nothing changed there. (aticonfig --initial -f --adapter=all)
I guess that little extra MH/s isnt really important. At this point it would be better to look for some real-world effecting factors, including better cooling, network latency (better pools) to reach a higher real hashrate
Absolutely. I'm just following a half-way scientific approach, fixing some factors and then trying to maximise others (in this case hash rate). Besides, maxing the hash rate is fun. When my power meter finally arrives I'll be looking very carefully at power consumption and may try to max MH/J before returning to a compromise which takes into account the very high value of mined BTC versus the value of the consumed power where I live. I've planned ahead to this end a little by investing in a fairly effinient (90%) and exceptionally quiet power supply. Undervolting is a consideration here too. As for the pools, I've always been a solo miner and my circumstances are such that there is no reason for me to change. A friend of mine is pool mining in Windows with BTC guild and has had much trouble in the last two weeks. multiminer solves some of these issues but he's not tried it yet (and I have no reason to). Another very important factor for me is noise. My miner has to live in my room and I value my sanity far more than the BTC it produces. I replaced the stock coolers on my cards with Zalman VF3000As (Caution: these coolers are not designed for these cards). Combining this with no overvolting and I'm able to run these cards at high clocks and with 40% fans (which are very quiet). When the stock coolers were still attached I needed to run them at 80% for reasonable temperatures and this was very noisy indeed (be wary of 100% on the stock coolers, many people have had problems with the fans dying on these cards). |
|
|
|
Ok, here are the errors for the latest kernel on SDK 2.1. { Build on <pyopencl.Device 'Cypress' at 0x34a3680>: /tmp/OCLthVTDN.cl(126): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) W[19] = P4(19) + 0x11002000 + P1(19); ^ /tmp/OCLthVTDN.cl(138): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) W[30] = P3(30) + 0xA00055 + P1(30); ^ /tmp/OCLthVTDN.cl(261): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) Vals[3] = L + W[64]; ^ /tmp/OCLthVTDN.cl(286): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) W[81] = P4(81) + P2(81) + 0xA00000; ^ /tmp/OCLthVTDN.cl(299): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) W[87] = P4(87) + P3(87) + 0x11002000 + P1(87); ^ /tmp/OCLthVTDN.cl(316): error: mixed vector-scalar operation not allowed unless up-convertable(scalar-type=>vector-element-type) W[94] = P3(94) + 0x400022 + P1(94); ^ 6 errors detected in the compilation of "/tmp/OCLthVTDN.cl". } Hopefully this is just some implicit casting of a kind which SDK 2.1 wants to be babied through. If I were versed in OpenCL I'd have a go at fixing this myself but I'm sure you would be much more efficient. |
|
|
|
There is no point trying to run phatk on pre-2.4 SDK versions. It will just end up being slower than the poclbm kernel.
I read elsewhere that this is the theory but in practice phatk is faster than poclbm on SDK 2.1 for me. Maybe this has something to do with the fact that I've applied the MA tweak (one less operation) to both kernels. E.g. Sapphire HD5850 Xtreme 1000MHz core, 350MHz RAM, Catalyst 11.6 (Linux x86_64), VECTORS BFI_INT FASTLOOP=false AGGRESSION=13 WORKSIZE=256: phatk: 413.3 MH/s (+/- 0.2 MH/s) poclbm: 411.4 MH/s (+/- 0.2 MH/s) I've tried lower core speeds and higher RAM speeds but always phatk outperforms poclbm on SDK 2.1 for me. For mining I see only 2 real options:
SDK 2.1 with poclbm
SDK 2.4 with phatk
2.2 is slower than 2.1 on poclbm and doesn't work well with phatk either.
2.3 is even slower than 2.2 on poclbm, but all I know with phatk is that it's slower than with 2.4
Anyway, getting the output from the compiler is very simple. You just need to comment out the try/except block surrounding self.loadKernel().
I'll try that. |
|
|
|
|
Our setups are very similar, so much so that the missing 1.3 MH/s puzzles me. I guess this could be a difference in the way phoenix and poclbm calculates the value to be displayed from the data fed to them by phatk. the 10 MHz RAM difference has practically no effect on the hashing speed and varying the AGGRESSION among the 'hard' levels (13 and up) only makes a difference of about 0.6 MH/s.
|
|
|
|
I dont use the poclbm kernel, I'm using poclbm miner with phatk kernel  Run "git pull", it was included recently As of the clocks, I'm on 1000,350 now. There is no aggression in poclbm, I use -f0 which is the hardest setting, -w256 and -v Running headless means I simply run "xinit" which spawns an empty desk with one xterm window in case of ubuntu server. I didn't change anything config related, except for having "export DISPLAY=:0" included in my bashrc file. Ah. I see. I was confused because phoenix comes with two kernels, called poclbm and phatk. I guess poclbm also refers to the front end. I'll also try some 'harder' aggression settings again (was using AGGRESSION=13 until recently). I have only one possible tip: Add a file '.xinitrc' to your home folder and simply put in the one line 'cat'. This will simply wait for input and could be considered a slight improvement on running an xterm. This almost certainly won't affect hashing rate but might affect stability a tiny bit. Either way, it seems neater to me. Are you doing anything special in xorg.conf? I don't really know what I'm doing in this file. I don't think I've made an impact on jitter, hash-rate, or stability yet but it's hard to tell with stability. |
|
|
|
If Phoenix would allow to output the OpenCL compiler build log we could get an idea what's wrong. Perhaps jedi95 reads here and takes this as a suggestion  . Perhaps I can take the lead with 2.4 and newer versions of my kernel, but for now I have no huge optimization ideas ... (but I'm thinking about it right now ^^). Dia Would I get more detailed feedback from another front-end to phatk? I haven't really 'shopped around' with the front ends. |
|
|
|
-w 128 gives me better results with my 5850.
Interesting. When I change to 128 my rate drops by a full 10 MH/s per 5850. Perhaps there are other settings which need to be changed in tandem to yield an improved rate. Could you let me know your other settings? RAM speed, SDK version, Catalyst version, kernel type/version/patches, kernel parameters. If your comments can improve my rate I'll tip in BTC. For me, it's the opposite. I lose 10 MH/s if I set -w 256. I'm actually using Phoenix, so my settings look a bit different: start /DC:\Bitcoin\phoenix phoenix.exe -u http://******:******@eu.triplemining.com:8344 -k poclbm VECTORS BFI_INT AGGRESSION=11 DEVICE=0 WORKSIZE=128 I'm running poclbm
Very interesting. On my system (980MHz core with 360MHz ram): python phoenix.py -u http://<user>:<pass>@<host>:<port>/ -a 1 -q 1 -k poclbm VECTORS BFI_INT AGGRESSION=11 WORKSIZE=256 DEVICE=1401 MH/s (+/- 2 MH/s) python phoenix.py -u http://<user>:<pass>@<host>:<port>/ -a 1 -q 1 -k poclbm VECTORS BFI_INT AGGRESSION=11 WORKSIZE=128 DEVICE=1
391 MH/s (+/- 2MH/s) Perhaps this is something to do with RAM clock speed. I'll investigate. Edit: Before getting to the RAM I noticed that this playing around with poclbm and AGGRESSION has frozen my card. This is the second time today! I really have to pull it back to 975 MHz unfortunately. I'll do my testing on my good core (still running well after 36 hours at 1020 MHz). |
|
|
|
I'm running poclbm
I'm running poclbm
Ok. In which case '-a 1' does something entirely different and no averages taken by default. What is your RAM clock and AGGRESSION at the moment? Also, you mention you are running headless. I assume you are therefore using custom '/etc/X11/xorg.conf', '/home/user/.xinitrc', et cetera, to activate the cards and give the drivers and poclbm something to point at but without asking the cards to drive any kind of desktop. If so then I must admit I'm having some trouble getting xorg.conf just right. I've got it to a point where if I plug a monitor into one of the cards there will be no signal but I'm not convinced it's not doing something anyway. Any tips would be appreciated and I'll happily share my files if you're interested. |
|
|
|
I'm sorry to hear that ... what are the error messages you get with 2.1? I only tried with 2.4 and will test only on 2.4 and later SDKs by myself. Buf If you give me a hint I can try to fix it.
Dia
Don't worry about it. The improvements for the SDK 2.4 users are clear and I'm impressed that you've managed to close the gap between 2.4 and 2.1 as much as you have. I don't know how to get detailed error messages from phatk. When I use SDK 2.1 and your latest kernel I run the command python phoenix.py -u http://<user>:<pass>@<host>:<port>/ -a 1 -q 1 -k phatk VECTORS BFI_INT FASTLOOP=false AGGRESSION=14 WORKSIZE=256 DEVICE=1and get [<date> <time>] FATAL kernel error: Failed to load OpenCL kernel!If I try the same with the previous version of your kernel everything works happily. I wish I had more details for you but I just don't know how to get them. |
|
|
|
Hehe I guess so Maybe it will change with the new SDK 2.5, so we can squeeze out a little more Hashes Yes, I look forward to when that is released. As far as I can tell there's a early version out but it's only usable on Windows. By the way, how are you using phatk? Are you driving it through phoenix? If so be aware that, by default, the readout is an average of the last 10 rates and this can be disabled with the flag '-a 1'. I find the moving average is only useful if your MH/s is leaping around by more than 1 MH/s say which shouldn't be the case here. |
|
|
|
Possibly you're using an old version of SDK. I get a fatal error when trying this with SDK 2.1 but am fine with SDK 2.4.
Well it worked with the previous version of the modified kernel. Yes, I found the previous version worked with SDK 2.1. But the version released today doesn't. I had to change to SDK 2.4 for this most recent version and this change actually lost me 0.4-0.6 MH/s. |
|
|
|
|
Show Posts
