 Show Posts
|
|
Pages: [1] 2 »
|
...the miners change and my intensities dont work, odnt dont work.
xmr-stak? ' xmr stak and xmr aeon stak Try SRBminer with intensity 112. its working fine. or use CastXmr. Why xmr-stak?! because of its integration with the JJ's hash monitor. I never figured out the cast xmr;s UI that sets hash rate thresholds. anyway I did use cast xmr and got similar hashrate. Not sure where the problem is. Using win 10 1709 Go back and look on the Cast thread for StellarX88's modified JJ hash monitor script. That works with Cast + JJ hash monitoring, and works very well. JJ has released closed source precious Guardian too to work around this too. As of now I am still using the one I modified myself for both Xmr-stak & Cast-Xmr. Let me know if you need assistance to set it up on your rig. Hi Stellax88, I have seen your post on cast-xmr on hash monitoring. are you still using it after the monero 7 fork? can you share your script? Hi, sorry for late reply, didn't browse this thread for a bit. Yes, I am still running the modified JJ script monero 7 fork, even though with the new driver chances of hash drop is lower, it's still a failsafe to run it. Hit me up on Skype @ mo.jin.ee if you need direct assistance/modification with the script. This is the version that I shared: https://drive.google.com/open?id=1TnicWxpB1TtGQCe_cuXND8ha-XsgQsU1I have a somewhat updated and modified version pre Precious Guardian that I am running now, but I don't think there's much difference there. Thanks Stellax. have you tried SRB miner? it is giving me about 80 - 100kh/s more than cast or xmr-stak. You are welcome. No, I haven't try SRB miner. Since I am only running one GPU, I am okay with tweaking around using Cast-XMR & XMR-Stak with the hash drop script alone. When I am into toying around with fine tweaking my GPU, I might consider modifying it accordingly with SRB Miner as well. I have already accepted the fate of Hynix memory hashing a tad lower than Samsung.  |
|
|
|
...the miners change and my intensities dont work, odnt dont work.
xmr-stak? ' xmr stak and xmr aeon stak Try SRBminer with intensity 112. its working fine. or use CastXmr. Why xmr-stak?! because of its integration with the JJ's hash monitor. I never figured out the cast xmr;s UI that sets hash rate thresholds. anyway I did use cast xmr and got similar hashrate. Not sure where the problem is. Using win 10 1709 Go back and look on the Cast thread for StellarX88's modified JJ hash monitor script. That works with Cast + JJ hash monitoring, and works very well. JJ has released closed source precious Guardian too to work around this too. As of now I am still using the one I modified myself for both Xmr-stak & Cast-Xmr. Let me know if you need assistance to set it up on your rig. Hi Stellax88, I have seen your post on cast-xmr on hash monitoring. are you still using it after the monero 7 fork? can you share your script? Hi, sorry for late reply, didn't browse this thread for a bit. Yes, I am still running the modified JJ script monero 7 fork, even though with the new driver chances of hash drop is lower, it's still a failsafe to run it. Hit me up on Skype @ mo.jin.ee if you need direct assistance/modification with the script. This is the version that I shared: https://drive.google.com/open?id=1TnicWxpB1TtGQCe_cuXND8ha-XsgQsU1I have a somewhat updated and modified version pre Precious Guardian that I am running now, but I don't think there's much difference there. |
|
|
|
Hi Guys, I will buy some vega 56 or 64 on amazon, Any tips for brands or partnumbers for increase the possibility of getting an vega with Samsung memory ? Thanks The question is which card will you buy, I mean is it reference version or version form asus and sapphire, cause they are different from each other? I have vega from gigabyte but that is simple reference version build by amd. I was lucky to have Samsung memory on that board.. Hi ivakar, Thanks for help, I just thinking for the reference version too, that had the turbine cooler, could it increase the possibility of have samsung memory? Could you send the link of amazon of your card? Thanks All reference Vega (56/64) [Don't matter ASUS/Sapphire/XFX/Gigabyte/MSI] pretty much have Samsung memory since other PCB manucfacturer aren't even gearing up to produce Vega PCB back then; For aftermarket Vega design (Strix, Sapphire Nitro+, Red Devil, Air Boost), you are likelier to find Samsung memory on Vega 64, and Hynix memory on Vega 56. |
|
|
|
Can someone please help me with hashrate (only 1.2khash/s). I have 4 asus vega 56 strix on windows 10 using newest drivers. HBM is on 890mhz because is unstavble over that. The code I'm using is:
cast_xmr-vega -S xmr-us-east1.nanopool.org:14444 -u adress.name %*
You should be able to get about 1.8kh/s with 890 mem clock at least. Have you updated to latest Cast XMR 0.9.2? Try DDU and redo it. I am also running at 890 mem clock since 900 and above will start throwing more % of invalid shares due to limited OC capability of Hynix memory. Did update on lastest and did try DDU. Have Samsung memory on this one. On the Hynix managed to pull of 950 but 1.3 khash/s. Samsung memory seems like a gold mine on Strix Vega 56. Doesn't make sense to pull such low figures, unless you are mining Cryptonight-Heavy not CryptonightV7? Hit me up on Skype @ mo.jin.ee if you want me to trouble shoot it together with you. Cheers. Thank you for advice. I'm mining V7. Or at least it says so xD I can only move on pm. Don't have skype. I can only 2 PMs a day here. Any other form of instant messaging will definitely be helpful to troubleshoot this. Discord/Slack or anything else that you prefer. Let me know. Managed to solve it! Didn't realize that newer version popped up in the meantime. But have now other problem. Didn't see that only one gpu from three was mining. How to fix that? Maybe i need to add something into the code (bat file) Make sure no -G is being called in the bat file to ensure all cards are mining. Also, make sure all 3 cards are recognized in the device manager and enabled too. |
|
|
|
Can someone please help me with hashrate (only 1.2khash/s). I have 4 asus vega 56 strix on windows 10 using newest drivers. HBM is on 890mhz because is unstavble over that. The code I'm using is:
cast_xmr-vega -S xmr-us-east1.nanopool.org:14444 -u adress.name %*
You should be able to get about 1.8kh/s with 890 mem clock at least. Have you updated to latest Cast XMR 0.9.2? Try DDU and redo it. I am also running at 890 mem clock since 900 and above will start throwing more % of invalid shares due to limited OC capability of Hynix memory. Did update on lastest and did try DDU. Have Samsung memory on this one. On the Hynix managed to pull of 950 but 1.3 khash/s. Samsung memory seems like a gold mine on Strix Vega 56. Doesn't make sense to pull such low figures, unless you are mining Cryptonight-Heavy not CryptonightV7? Hit me up on Skype @ mo.jin.ee if you want me to trouble shoot it together with you. Cheers. Thank you for advice. I'm mining V7. Or at least it says so xD I can only move on pm. Don't have skype. I can only 2 PMs a day here. Any other form of instant messaging will definitely be helpful to troubleshoot this. Discord/Slack or anything else that you prefer. Let me know. |
|
|
|
Can someone please help me with hashrate (only 1.2khash/s). I have 4 asus vega 56 strix on windows 10 using newest drivers. HBM is on 890mhz because is unstavble over that. The code I'm using is:
cast_xmr-vega -S xmr-us-east1.nanopool.org:14444 -u adress.name %*
You should be able to get about 1.8kh/s with 890 mem clock at least. Have you updated to latest Cast XMR 0.9.2? Try DDU and redo it. I am also running at 890 mem clock since 900 and above will start throwing more % of invalid shares due to limited OC capability of Hynix memory. Did update on lastest and did try DDU. Have Samsung memory on this one. On the Hynix managed to pull of 950 but 1.3 khash/s. Samsung memory seems like a gold mine on Strix Vega 56. Doesn't make sense to pull such low figures, unless you are mining Cryptonight-Heavy not CryptonightV7? Hit me up on Skype @ mo.jin.ee if you want me to trouble shoot it together with you. Cheers. |
|
|
|
...the miners change and my intensities dont work, odnt dont work.
xmr-stak? ' xmr stak and xmr aeon stak Try SRBminer with intensity 112. its working fine. or use CastXmr. Why xmr-stak?! because of its integration with the JJ's hash monitor. I never figured out the cast xmr;s UI that sets hash rate thresholds. anyway I did use cast xmr and got similar hashrate. Not sure where the problem is. Using win 10 1709 Go back and look on the Cast thread for StellarX88's modified JJ hash monitor script. That works with Cast + JJ hash monitoring, and works very well. JJ has released closed source precious Guardian too to work around this too. As of now I am still using the one I modified myself for both Xmr-stak & Cast-Xmr. Let me know if you need assistance to set it up on your rig. |
|
|
|
Can someone please help me with hashrate (only 1.2khash/s). I have 4 asus vega 56 strix on windows 10 using newest drivers. HBM is on 890mhz because is unstavble over that. The code I'm using is:
cast_xmr-vega -S xmr-us-east1.nanopool.org:14444 -u adress.name %*
You should be able to get about 1.8kh/s with 890 mem clock at least. Have you updated to latest Cast XMR 0.9.2? Try DDU and redo it. I am also running at 890 mem clock since 900 and above will start throwing more % of invalid shares due to limited OC capability of Hynix memory. |
|
|
|
@ All with Vega 56 with Hynix HBM2:
I read here, that the most V56 with Hynix having issues if the frequency is higher than 890Mhz.
I have one V56 Hynix running well @890/0915mV
A second V56 Hynix has issues with this settings and brings GPU errors
What voltages do you apply in Wattman/OverDriveNTool/Regmods???
Please let me know. THANKS
I am not certain if raising voltage will assist with higher core clock without throwing invalid shares, but what I did was merely reducing the mem clock until no error was thrown. If increasing voltage will allow the HBM memory to hash at expected hashrate I would have done so. But so far it doesn't seems to be the case (able to push to 930 mem clock, but no amount of voltage bump will fix the invalid calculation error). |
|
|
|
So got a Vega 56 to play around finally.
Mining cryptonight @1926 H/s with xmr-stak at 1408 core and 925 HBM2 (900mV). Even though the overdriveNTool profile is set to run at 1408/915mV HWinfo64 says the CVDDC is at 1.25V. MVDDC changes get reflected but not the core. Any pointers?
I am already using soft pp table btw.
Core P6 is 1212, 910 mV and P7 is 1408, 915 mV
HBM2 P3 is 925, 900mV
Pretty impressive, is that a reference model with Samsung memory? The readings on hwinfo could be flipped depending on version reading, 1.25V is actually the MVDDC, your core voltage should be sub 0.9 as for your p7 915mV. May I know what's your xmr-stak config for this? Inn terms of intensity. Reference with Samsung. 1932 intensity, 2 threads. I am not sure if it's flipped. Cause it reflects the changes I do in MVDDC in HWInfo. Samsung is indeed still the king, I am more amazed with the intensity with you not flashing to 64 BIOS. It is indeed flipped, p3 mem voltage has nothing to do with adjusting memory voltage, it's hardcoded to 1.25V in BIOS for 56, and 1.35V in BIOS for 64. The adjustment you make in p3_mem voltage is merely setting the bare floor voltage for GPU core, but p7_gpu voltage takes precedence; no voltage adjustment that you can perform in OverDriveNTool is going to impact mem voltage. |
|
|
|
So got a Vega 56 to play around finally.
Mining cryptonight @1926 H/s with xmr-stak at 1408 core and 925 HBM2 (900mV). Even though the overdriveNTool profile is set to run at 1408/915mV HWinfo64 says the CVDDC is at 1.25V. MVDDC changes get reflected but not the core. Any pointers?
I am already using soft pp table btw.
Core P6 is 1212, 910 mV and P7 is 1408, 915 mV
HBM2 P3 is 925, 900mV
Pretty impressive, is that a reference model with Samsung memory? The readings on hwinfo could be flipped depending on version reading, 1.25V is actually the MVDDC, your core voltage should be sub 0.9 as for your p7 915mV. May I know what's your xmr-stak config for this? Inn terms of intensity. |
|
|
|
Let's examine everything I am doing... Let's take a look at the mining settings. cast_xmr-vega -G 1 --fastjobswitch -S pool.supportxmr.com:7777 -p <snip> -u <snip> Testing it on the true Vega64 first to dial it in, before I start tackling the Vega56s. I've tried this pool, and a few other coins. I've tried with and without --fastjobswitch. That port, 7777, is for "highend hardware" starting at 25,000 difficulty. I have tried lower difficulty, of 5,000. I have tried setting the difficulty flat in 50,000 increments from 50,000 to 350,000 to no effect. Pool difficulties is not going to impact your card performance, shoot me a message on skype @ mo.jin.ee, I will try to trouble shoot this with you. |
|
|
|
Well, the good news is after a full pave and reinstall of the drivers - I no longer get that warning message of not using the blockchain drivers.
I am also now able to use the same tweaked settings in the guides, and getting around 1300 H/s. So yes, that's a little better.
But still a far cry from 1900 or 2000 H/s as advertised.
Guess I'll sleep on it. Let me know if y'all have another ideas.
Crossfire disabled? Ensure that you do a vega driver reset after reboot once at least, it should push your vega to the expected range at 1050 to 1100 mem for vega64 BIOS. |
|
|
|
Have you disable and enabled gpu in device manager before you start the miner. After reboot also if miner crash. Yet better? If not go this how to http://vega.miningguides.com/Don't thought 900mhz gpu is enough for 1900+h/s  I saw that disable/reenable in a few guides. But the newer ones don't have that step. I'll try it now though; however, I do reboot often and power-cycle without any differences. Back... Nope, made no difference at all. Even powered off, booted, disable/enabled in device manager. Oh and not 900mhz core - 900 millivolt.  It greatly lowers power consumption. Even at the full stock millivolts, it makes no difference in mining. What bugs me is that it continues to say: "[22:35:41] [Suspicious link removed]pute Driver NOT detected." The AMD installer explicitly says 17.30.1029. However, once installed it shows 17.30.1091. Yes, I ran DDU as well to clean. Still only 1091 gets installed? EDIT: If it matters, I do have IGPU enabled in bios and am using the onboard video. [Suspicious link removed]pute-Release-Notes.aspx Ensure crossfire is off just in case. If you installed the correct driver, Cast-XMR won't throw the warning. |
|
|
|
i have this 3 pics,all of cards have Hynix HBM. so,i set up memory clock 890@900mv core 1400mh stable.with ~1800H/s. powerplaymod is working fine same AIB card's.  Did you try pushing your Hynix memory to 930 or 950 mem range? Does it hash in good result? Or just throwing invalid shares all around? Thanks. temp is around 55-60 fan rpm 3000-3500. bit higher becouse i use Onda B250-D8P. its close by GPUs. pushing memclock to 930 is can. but show invalid shares. 940 is unstable.  Same as my case, seems to be a Hynix issue. My ASUS Strix also purely throw invalid shares at much higher OC. At 890 mem it's hashing fine at lower rate. |
|
|
|
i have this 3 pics,all of cards have Hynix HBM. so,i set up memory clock 890@900mv core 1400mh stable.with ~1800H/s. powerplaymod is working fine same AIB card's. Did you try pushing your Hynix memory to 930 or 950 mem range? Does it hash in good result? Or just throwing invalid shares all around? Thanks. |
|
|
|
At 56 BIOS (Can't find Hynix 64 BIOS to flash on to try yet), I am able to actually run the mem overclock at 950, it actually won't crash but there is no accepted results, so I find the maximum mem overclock without throwing invalid shares at 890 Mhz.
It's taking 900 mV using overdriveNTool, on hwInfo it's drawing 0.881V just like my previous ref vega56. (Still unsure if this is the core clock power draw or mem clock power draw) This is with registry edit so the undervolt works, compared to ref vega 56, my on the wall power draw has been reduced by about 30 Watt. I imagine the power draw should be the same as ref, the difference is likely due to me running ref vega 56 at 64 BIOS (higher mem/core clock power draw @ 1.35V).
For reference,
before: r7 1700 + rx480 8gb + ref vega56 (64 BIOS) -> ~ 400W
now : r7 1700 + rx480 8gb + strix vega56 -> ~ 370W
Thanks again. So it should be safe to assume that ref and aftermarket are about the same, except for the slower memory. Did you use the same registry tools (and .reg files) that you used in the ref card (I guess they're the same)? With only 1 card I can never be certain if the memory manufacturer is the fault for overclocking tolerance, or it might be due to how the BIOS is programmed (I really doubt that but if it can be fixed via software it will be awesome), but your assumption is more or less correct. Aftermarket is essentially changes on the heatsink + cooler design, and also possibly some BIOS tweaks from each brand themselves. The registry file for my ASUS strix doesn't come with softPTTTable, so I merely apply the one I had for previous ref 56 onto it and it will be effective after a disable/enable or full pc reboot. I don't recall if there's any major difference between ref 56 core clock and mem clock out of the box vs Asus Strix, so the registry application is meant for undervolting and power draw reduction (adjusting core clock p2 to p5). |
|
|
|
So, what makes of aftermarket cards are out there ?
I know of Sapphire. Others ?
Also, what memory they're using ?
I myself has switched from Ref 56 to ASUS Strix Vega 56. The one I had comes with Hynix memory, it could push to 950 mem clock, but it's all invalid shares from there on, so I have to downclock the memory to 890 ish, doing about 1750 to 1800 h/s at best. Thank you for sharing. What is the tension you can run the hynix memory at ? Can it hold 875 or 900mV ? What is the power needs (higher or lower than the ref) ? At 56 BIOS (Can't find Hynix 64 BIOS to flash on to try yet), I am able to actually run the mem overclock at 950, it actually won't crash but there is no accepted results, so I find the maximum mem overclock without throwing invalid shares at 890 Mhz. It's taking 900 mV using overdriveNTool, on hwInfo it's drawing 0.881V just like my previous ref vega56. (Still unsure if this is the core clock power draw or mem clock power draw) This is with registry edit so the undervolt works, compared to ref vega 56, my on the wall power draw has been reduced by about 30 Watt. I imagine the power draw should be the same as ref, the difference is likely due to me running ref vega 56 at 64 BIOS (higher mem/core clock power draw @ 1.35V). For reference, before: r7 1700 + rx480 8gb + ref vega56 (64 BIOS) -> ~ 400W now : r7 1700 + rx480 8gb + strix vega56 -> ~ 370W |
|
|
|
I've got a bit of a weird issue...
One of my six Vega56 flashed to 64 is hashing at 120h/s slower than the other 5. At first, I thought it was the one with the dummy plug in, but I switched the plug to another card and it's still that same GPU3 that's hashing slower... The other ones hash on avg at 1970 h/s, GPU3 does 1850.
They're all clocked the same (1025@1V iirc) and temps are in the low 60's.
Any ideas (apart from the card being inferior)?
Vegas 56 are awesome. I'd check if it's a raiser issue. Bad raisers can cause certain problems, one of them being that a card could perform more slowly than others. However I wouldnt bother with them seeing that the difference is "small", imho. Btw, have you tried to decrease the temperatures? Ah yes... The risers... Wait... I've got an Onda D1800! Nah temps are fine. All cards are very closely matched. Maybe this specific card is just running at its max for that voltage. I might try just increasing that one a notch and see what happens. Do you know if Cast XMR uses the same GPU number as OverdriveNtool? I only have 2 cards set up at the moment and Cast-Xmr is indeed mirroring overdriveNTool GPU number. Could be a 50 50 flux. |
|
|
|
|
