Tell please the optimal manual configuration settings for AMD RX5XX/4XX with 8 GB for cryptonight-saber bittube
I found on the forum only for 4 GB cards
Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 32. (Read 90841 times)
Hooo, right, I forgot this point, the L2 and L3 are exclusive on those chips. Normal.
This is no longer the case for Zen architecture.
This is no longer the case for Zen architecture.
Quote
And that's with usage of FX4330(4-core, 8M, 4GHz)
CN-Heavy consumes 4M of cache, better use two threads with multi-hash 1Agree with your logic but it does less hashes that way.
So, I've got some observes:
01 + 31 = 114 01 + 32 = 128 02 + 31 = 128
01 + 21 = 114 02 + 21 = 128
01 + 11 = 92 02 + 11 = 85 01 + 12 = 85
11 + 21 = 114 12 + 21 = 128 11 + 22 = 128
21 + 31 = 92 22 + 31 = 85
The conclusion may be that miner uses not the only L3 cache which is one for all cores but it uses L2 caches which are numbered to core modules on the exact cpu.
FX4330 has 2 modules by 2 cores with 2MB L2 each. And the sum of L2 and L3 is exact 12MB.
Unfortunately I've already sold all of my 8300 and 6300 FXes. Would be nice to test them again.
That can be used to tune any CPU.
Thanks for report, but it should work now even with russian letters. I'll do more test with the exact same path as you.
@UnclWish
I let the pre-b5 online on purpose, but that's very surprising you noticed no increase. I had +15/+20% on all the card I tested from the HD6950 to the RX. It's not impossible your Curacao chip doesn't get any extra speed, but very strange. And i dedicated the release to you, so sad
@UnclWish
I let the pre-b5 online on purpose, but that's very surprising you noticed no increase. I had +15/+20% on all the card I tested from the HD6950 to the RX. It's not impossible your Curacao chip doesn't get any extra speed, but very strange. And i dedicated the release to you, so sad
OpenCL bug 0.2-10: i could reproduce it on my rig by using exotic characters in the path where JCE exe was, and this case is fixed. But there may be another cause of bug. Did you use non-english path too?
DEV BIG thanks! it all worked
I did not immediately understand that it was necessary to avoid Russian letters in folders with the JCE program!
as sample d:\JCE _MONERO\033b6\ all work nice!
as sample d:\MAЙHEP\033b6\ error
I use Win10 and catalyst 14.4.
Please, tell us how did you manage to install _14.4_ Catalyst on Windows _10_. As far as I see, maximum Windows version for 14.xx drivers is Win8.1.
OpenCL bug 0.2-10: i could reproduce it on my rig by using exotic characters in the path where JCE exe was, and this case is fixed. But there may be another cause of bug. Did you use non-english path too?
Hashrate: first, yes, the +15% is not fake, but it can be canceled by the higher instability on some cards. On old cards, it's +20% faster and stable, easy. HD6000, HD7000, R7, R9... On big RX and Vega, things are more complicated.
I read here opposite results, so:
* Ensure you're talking about CN-Heavy and related, CN-v8 is not concerned by the 0.33b6 release
* Is it unstable on the 8Gb RX and Vega only? Sure that's the most common cards, but if this is the status, it's an important detail to track the bug down. I did my long-run tests on 2G and 4G cards only so far. If I need a 8G card to reproduce the bug, i've some, so i need to focus on them.
I suspend GPU support and dev for now, going back to CPU version where i've a fistful of Github tickets to close.
I didn't noticed any + in hashrate on my R9 270X 4Gb (3,5 OpenCL). On pre-b5 versions on heavy it was 420 h/s and now speed the same, only fee increased... Hashrate: first, yes, the +15% is not fake, but it can be canceled by the higher instability on some cards. On old cards, it's +20% faster and stable, easy. HD6000, HD7000, R7, R9... On big RX and Vega, things are more complicated.
I read here opposite results, so:
* Ensure you're talking about CN-Heavy and related, CN-v8 is not concerned by the 0.33b6 release
* Is it unstable on the 8Gb RX and Vega only? Sure that's the most common cards, but if this is the status, it's an important detail to track the bug down. I did my long-run tests on 2G and 4G cards only so far. If I need a 8G card to reproduce the bug, i've some, so i need to focus on them.
I suspend GPU support and dev for now, going back to CPU version where i've a fistful of Github tickets to close.
alpha and beta are internal data packing modes. I cannot tell more without revealing code secrets. They must be power of two, and only three values are decent for them, respectively 32/64/128 and 4/8/16, except for very old cards where extreme values like alpha=256 or beta=32 can be good.
Other greeks are deprecated, note they no longer appear in the doc.
Other greeks are deprecated, note they no longer appear in the doc.
JCE,
as other miners alrady asked, please can you explain what are alpha, beta, gamma, zeta...? So at we have basic idea of what are we doing when putting all the random numbers
as other miners alrady asked, please can you explain what are alpha, beta, gamma, zeta...? So at we have basic idea of what are we doing when putting all the random numbers
Thanks, and that's also my first idea: recent JCEs are faster but support a lot less to mine on 99% available memory. The trick is that the b5 and b6 no longer need to use all memory to get fast, I tried to configure my 4G cards exactly like my 2G (with about 1900M memory allocated) and they mined fast. Increasing the 4G cards load over 2G gave very little extra speed at the cost of a very unstable hashrate.
Maybe the fix is just to warm users to update their older config and use less memory. I'm afraid a lot of users just updated their binary keeping the old config on 8G with maximum memory load, as it was the rule on previous versions, and is still on other miners like Cast or SRB.
To all who have the problem: configure your 8G card like if it was a 6G, leaving free vram on it and retry. I'd expect to get -1% speed and a very more stable hashrate.
I remember this rule from older Claymore 9 with mode -a 1: it provided +2% extra perf with +20% power consumption, 100% memory usage and random crashes. Not a good deal.
Maybe the fix is just to warm users to update their older config and use less memory. I'm afraid a lot of users just updated their binary keeping the old config on 8G with maximum memory load, as it was the rule on previous versions, and is still on other miners like Cast or SRB.
To all who have the problem: configure your 8G card like if it was a 6G, leaving free vram on it and retry. I'd expect to get -1% speed and a very more stable hashrate.
I remember this rule from older Claymore 9 with mode -a 1: it provided +2% extra perf with +20% power consumption, 100% memory usage and random crashes. Not a good deal.
Guys chech your multihash, if it is too high you will get all kinds of hashrate issues.
On my Vega rig i dropped multihash form 960 to 896 and hashrate stayed the same but now i had same hashrate over all cards
I was just testing the rig, it was connected to bittube pool and it was working like 10 hours with 0 issues
On my Vega rig i dropped multihash form 960 to 896 and hashrate stayed the same but now i had same hashrate over all cards
I was just testing the rig, it was connected to bittube pool and it was working like 10 hours with 0 issues
OpenCL bug 0.2-10: i could reproduce it on my rig by using exotic characters in the path where JCE exe was, and this case is fixed. But there may be another cause of bug. Did you use non-english path too?
Hashrate: first, yes, the +15% is not fake, but it can be canceled by the higher instability on some cards. On old cards, it's +20% faster and stable, easy. HD6000, HD7000, R7, R9... On big RX and Vega, things are more complicated.
I read here opposite results, so:
* Ensure you're talking about CN-Heavy and related, CN-v8 is not concerned by the 0.33b6 release
* Is it unstable on the 8Gb RX and Vega only? Sure that's the most common cards, but if this is the status, it's an important detail to track the bug down. I did my long-run tests on 2G and 4G cards only so far. If I need a 8G card to reproduce the bug, i've some, so i need to focus on them.
I suspend GPU support and dev for now, going back to CPU version where i've a fistful of Github tickets to close.
Hashrate: first, yes, the +15% is not fake, but it can be canceled by the higher instability on some cards. On old cards, it's +20% faster and stable, easy. HD6000, HD7000, R7, R9... On big RX and Vega, things are more complicated.
I read here opposite results, so:
* Ensure you're talking about CN-Heavy and related, CN-v8 is not concerned by the 0.33b6 release
* Is it unstable on the 8Gb RX and Vega only? Sure that's the most common cards, but if this is the status, it's an important detail to track the bug down. I did my long-run tests on 2G and 4G cards only so far. If I need a 8G card to reproduce the bug, i've some, so i need to focus on them.
I suspend GPU support and dev for now, going back to CPU version where i've a fistful of Github tickets to close.
On polarises 4GB it is not noticed, also vegas.
Correction - same problem with Vega.As a conclusion - unstable hashrate is noticed on 8GB cards. Also I think it is related to power drops (seen in gpuz) - I don't know whether they are cause ot result...
The b6 doesn't work on my rx580 8Gb samsung rigs, it is unstable exactly like the b5.
On my RX 580 8G cards speed with b6 a bit lower, but still unstable. One of cards drops speed to 985 h/s and didn't rise it again...
It's online 0.33b6 GPU
I mined Haven for 48 hours on 3 capricious RX and had a very stable hashrate, varying +/- 2% not more, I hope it will be better for everybody.
I mined Haven for 48 hours on 3 capricious RX and had a very stable hashrate, varying +/- 2% not more, I hope it will be better for everybody.
My GPUs could get through the warmup, still with swings (mostly RAM frequency, sometimes core freq). Declared speed in itself is highly improved compared to my reference JCE 0.32G version, +15% for same power draw (at wall). If my computer stay stable during the night, I'll check the reported HR at the pool.
Almost 9hs mining tube and counting.
Max speed is 2316H/s, I had never got above 2030H/s with my reference 0.32G version, so that's a solid +15% speed.
Current effective HR: 2250H/s.
Power draw at the wall: 365-370W, this include the CPU mining which consumes around 30W.
That's a HUGE improvement in terms of speed with the same wattage, impressive.
One important point: I had to lower both core and mem clock on 2 out of 3 GPUs.
http://json.org/
0.33b6 to be released in less than one day, with the OpenCL bug O.2.10 fixed.
Quote
ws
""
'0009' ws
'000a' ws
'000d' ws
'0020' ws
""
'0009' ws
'000a' ws
'000d' ws
'0020' ws
Quote
Whitespace can be inserted between any pair of tokens.
So my JSON is conformant, and said differently, JSON do'nt care about blankspaces and indentation.0.33b6 to be released in less than one day, with the OpenCL bug O.2.10 fixed.
033 b6 not work , reports the same errors
may need a specific version of the video driver?
A few hours before the release of 0.36 get stable configuration also with 0.35 on my rx card.
Example, for 580 8gb on heavy algo get stable 1035 hs with multihash 896 or 1062 with 832.
Increase value of multihash parameter get instable hashrate.
This is, test now 0.36
Example, for 580 8gb on heavy algo get stable 1035 hs with multihash 896 or 1062 with 832.
Increase value of multihash parameter get instable hashrate.
This is, test now 0.36
Hi, I've have to honest on this one - I’ve tried ver 06, unfortunately so far no improvement at all...I’m just not sure if it really worth it. currently, the ver.b6 doesn’t give me any of the advertising hash rate. (10-15% -realy???/are you sure?
)
To be clear, a have an excellent performed on my 46 rigs of Sapphire AMD Radeon GPU RX 480 8gb Samsung, each easily giving 8930-8950 h/s, founded best running on 33ver.b2, ///// and running by very similar hashrate 8800--0890 on ver, 0.3.b4 on my 17 rigs 8x580 8Gb powered by Hynix memory, its sems more stable on this version . So if you going with Polaris on 8Gb Samsung – the 0.33.b2 its the best version for you, on the Hynix Memory- its hard to beat ver b4. JUST IGNORE THE VER B05 / B06 AT ALL COST!!!!
)To be clear, a have an excellent performed on my 46 rigs of Sapphire AMD Radeon GPU RX 480 8gb Samsung, each easily giving 8930-8950 h/s, founded best running on 33ver.b2, ///// and running by very similar hashrate 8800--0890 on ver, 0.3.b4 on my 17 rigs 8x580 8Gb powered by Hynix memory, its sems more stable on this version . So if you going with Polaris on 8Gb Samsung – the 0.33.b2 its the best version for you, on the Hynix Memory- its hard to beat ver b4. JUST IGNORE THE VER B05 / B06 AT ALL COST!!!!
It seems the drops in hashrate remained at 033b6...
The strange thing is that it affects polarises (470/580) - 8GB and at each restart affect random cards of them. They work properly with stable hashrate (but little bit lower) with 032q, so I use that old version for them only. On polarises 4GB it is not noticed, also vegas.
The strange thing is that it affects polarises (470/580) - 8GB and at each restart affect random cards of them. They work properly with stable hashrate (but little bit lower) with 032q, so I use that old version for them only. On polarises 4GB it is not noticed, also vegas.
Jump to: