Kerney, todx, can you please include in the API, the currently used algorithm?
It's already available, but given the lack of documentation I understand it's hard to find. We refer to the sgminer 5.5 API docs, but those are somewhat confusing as well... Anyway, the "devdetails" command is what you want. For a single gpu, this is what you get, the "Kernel" field contains the algo:
$ echo '{"command": "devdetails"}' | nc localhost 4028 | python -m json.tool
{
"DEVDETAILS": [
{
"DEVDETAILS": 0,
"Device Path": "05:00:0",
"Driver": "opencl",
"ID": 0,
"Kernel": "cn_conceal",
"Model": "Radeon RX 570 Series",
"Name": "GPU"
}
],
"STATUS": [
{
"Code": 69,
"Description": "TeamRedMiner 0.5.7.1",
"Msg": "Device Details",
"STATUS": "S",
"When": 1566223785
}
],
"id": 1
}
Double post, but: Is there a "Uptime" key present? The "When" is not really useful, it could be used only as "Last time". There are "Elapsed" fields in a number of different messages. Check the "SUMMARY" or "STATS" commands. Don't have access to a running miner right now for an example, just checked the code. Yup, sorry, i have totally missed that. |
|
|
|
Kerney, todx, can you please include in the API, the currently used algorithm?
It's already available, but given the lack of documentation I understand it's hard to find. We refer to the sgminer 5.5 API docs, but those are somewhat confusing as well... Anyway, the "devdetails" command is what you want. For a single gpu, this is what you get, the "Kernel" field contains the algo:
$ echo '{"command": "devdetails"}' | nc localhost 4028 | python -m json.tool
{
"DEVDETAILS": [
{
"DEVDETAILS": 0,
"Device Path": "05:00:0",
"Driver": "opencl",
"ID": 0,
"Kernel": "cn_conceal",
"Model": "Radeon RX 570 Series",
"Name": "GPU"
}
],
"STATUS": [
{
"Code": 69,
"Description": "TeamRedMiner 0.5.7.1",
"Msg": "Device Details",
"STATUS": "S",
"When": 1566223785
}
],
"id": 1
}
Double post, but: Is there a "Uptime" key present? The "When" is not really useful, it could be used only as "Last time". |
|
|
|
Kerney, todx, can you please include in the API, the currently used algorithm?
It's already available, but given the lack of documentation I understand it's hard to find. We refer to the sgminer 5.5 API docs, but those are somewhat confusing as well... Anyway, the "devdetails" command is what you want. For a single gpu, this is what you get, the "Kernel" field contains the algo:
$ echo '{"command": "devdetails"}' | nc localhost 4028 | python -m json.tool
{
"DEVDETAILS": [
{
"DEVDETAILS": 0,
"Device Path": "05:00:0",
"Driver": "opencl",
"ID": 0,
"Kernel": "cn_conceal",
"Model": "Radeon RX 570 Series",
"Name": "GPU"
}
],
"STATUS": [
{
"Code": 69,
"Description": "TeamRedMiner 0.5.7.1",
"Msg": "Device Details",
"STATUS": "S",
"When": 1566223785
}
],
"id": 1
}
Oh, thanks! |
|
|
|
|
Kerney, todx, can you please include in the API, the currently used algorithm?
|
|
|
|
Ofcourse its down, she kicked everyone from the OGAC team, and nuked the repository (probably only private). I will see if i have it to upload it. Why? ... #crysx Find something about the Mineority project, that she flopped on purpose. You will understand. |
|
|
|
I don't know why. I changed nothing with my cards. No tweaking with the cards. I'm good with the default settings. But every time I use TRM, my pc always says that Teamredminer.exe is blocked from accessing graphics card. I'm using 18.6.1 for my vega 64. If I use other miners, I don't encounter this problem. What could be causing this?
Make sure to exclude .exe file from your antivirus or windows defender and then you will not have problem. Thanks for responding but I already had exclusions for TRM. That's why I wonder what caused this because I don't have this problem if I use other miners. TRM will often push the GPU hardware harder than other miners. A lot of stock voltages/clocks on cards are very aggressive and can result in cards overheating. Have you looked at temps when you run the miner compared to other miners? Have you tried undervolting or lowering clocks? Thanks for your suggestion. But undervolting only made it worst. It gave my rig a bsod. Windows cannot repair it. So I had to reset. For CN, you can lower core clocks by 150Mhz probably and not lose significant performance. And then you lower the core voltage accordingly. |
|
|
|
Team Red Miner v0.5.5 releasedhttps://github.com/todxx/teamredminer/releasesChanges in v0.5.5 - Added cuckatoo31 algo for grin.
We've added cuckatoo31 for grin mining! Seems we might have been a bit late as asics are might already be here for the algo  . They have been up since the coin launched. |
|
|
|
https://mega.nz/#!yHAFjITY!_KMJM4EEZsZIerIfitGyHF8uIb2trzuEgcO7OvZBDUY There you go, the OhGodATool. I should have forked it when i had access...
|
|
|
|
Ofcourse its down, she kicked everyone from the OGAC team, and nuked the repository (probably only private). I will see if i have it to upload it. |
|
|
|
@kerney666
What does it mean to have the "hw" code triggered for a GPU? My Radeon VII GPU is having almost a 40% "hw" triggering even though the pool is still accepting its share. However, the poolside hashrate for the card is very low. I am using TRM 0.5.2 and running my GPU @1575cclk/975mclk/855mV.
Any ideas what is happening and how to fix this?
Yo Bro try to play with your clocks and votag and see which one is best for your GPU. HW means hardware error and it shows that your GPU is not doing well. 40% HW error means you are losing 40% of your hashrate. try to increse your voltage and see if it can fix or not, and be careful to not break your GPU increase bit by bit. Hi! +1 for bumping voltage. My experience is that the VIIs react with hw errs when they're starved on voltage, V64/56 and Polaris cards typically crash outright instead. I can't run my VII at 855mV at your clocks, it would produce bad hashes just like for you. I do know other VII owners that are just fine at the same levels though, so silicon lottery/ymmv/etc. Try raising it +5-10mV at the time and observe the error rate. Also, make sure your fan curve is set to provide adequate cooling. Actually, with my Polaris cards, if the voltage is just a tad lower than needed, it will throw HWs. A 1-2 step increase is enough to fix it. |
|
|
|
|
Having a weird issue.
Supposedly, before, the power consumption was fixed.
Now, its over hte place again.
Minimum power consumption for my rig is 477 watts, average is around 483watts, but the peak is around 495watts (at wall all).
This is with 0.5.2 and CN-R (XMR). GPUs are 4x580s, all on 1240Mhz core, 0.875V-0.9V core voltage. Drivers are 19.5.1. Windows 10.
Using the --cn-config from the Full test : 8+7:BAA,8+7:CAA,8*7:AAA,8+7:CAA
|
|
|
|
|
Kerney, the issue with the GPU dying, because of reaching 81*C continues. Miner API becomes unresponsive, and i gotta do hard reset, otherwise with a "emergency" reset, the GPU does not boot.
This kind of GPU dying is new to me, usually the miner detects it as DEAD somehow, or the OS crashes.
|
|
|
|
Hey Kerney. I had PMed you in the MMP OS Discord for a weird issue. 2 days ago, i experencied a crashed GPU, its a 570 4GB. System is Win 10 1703, AMD 19.2.1, 4GB RAM, i5-3470. The GPU would die for no reason (maybe timings). The GPU stats reporting will stop, and only the share submitting will remain. API is getting killed as well. But the miner itself does not seem to react properly with the dead GPU, as no SICK/DEAD is declared (and the API should still be responsive). Miner does not initiate properly the shutdown process, or at the very least, output is not shown. The GPUs did stop mining though. Trying to invoke the Task Manager or the AMD Radeon Settings freezes them almost right away. Even the driver does not know if its crashed or not  EDIT2: Here are the screenshots. https://imgur.com/a/fu3ZkxjI presume, it could be overheating, since yesterday crashed again at 81*C. EDIT: Also, i see that the Interleaving adjustment happens primarily on the GPU0 (shortly after the miner initialization). EDIT3: When the card was run with lower voltage (core + IMC), it crashed, and it was detected and declared as DEAD. Will try again, by raising the voltage, to see if the issue will repeat. Hi ku4eto! Thanks for the edit updates. Any more info after bumping voltage a little? Okay, after some testing, i got in the past 2 days, 3-4 more crashes in total. After playing with the voltage for that card (retesting the stability, in case it has degraded), but the voltage initially used was indeed correct. Bumping up the voltage by 2 steps (2x6.25mV) had no difference. I set the fan today to 95% for above 75*C (was for 85*C before that). I have not observed the issue still. I will check for 2 more days, before calling it 100% an thermal issue. Its a RX 570 Gigabyte Aorus. Not sure, but i believe some cards had a different thermal limit for some elements, compared to the rest. Although, i did compare the BIOS, and it had the same temp limits defined, as the rest of my cards. |
|
|
|
Hey Kerney. I had PMed you in the MMP OS Discord for a weird issue. 2 days ago, i experencied a crashed GPU, its a 570 4GB. System is Win 10 1703, AMD 19.2.1, 4GB RAM, i5-3470. The GPU would die for no reason (maybe timings). The GPU stats reporting will stop, and only the share submitting will remain. API is getting killed as well. But the miner itself does not seem to react properly with the dead GPU, as no SICK/DEAD is declared (and the API should still be responsive). Miner does not initiate properly the shutdown process, or at the very least, output is not shown. The GPUs did stop mining though. Trying to invoke the Task Manager or the AMD Radeon Settings freezes them almost right away. Even the driver does not know if its crashed or not EDIT2: Here are the screenshots. https://imgur.com/a/fu3ZkxjI presume, it could be overheating, since yesterday crashed again at 81*C. May EDIT: Also, i see that the Interleaving adjustment happens primarily on the GPU0 (shortly after the miner initialization). EDIT3: When the card was run with lower voltage (core + IMC), it crashed, and it was detected and declared as DEAD. Will try again, by raising the voltage, to see if the issue will repeat. |
|
|
|
I may have missed it, but: What does the GPU0 thread 0 interleave adjust xxx ms means? For dual thread CN mining to keep its highest hashrate over time you need to make sure the two threads are running with the appropriate separation in time. If they gravitate and become too close to running synchronously, the whole point of running dual threads disappears. Therefore, it's better to delay one of the threads a little before starting the next hash run. This is the "interleave adjustment" logged above. As long as your hashrate is stable (and high) over time, it's nothing to worry about, everything is working as intended. Asking, because i saw it on only one card. And this one tends to crash every week or two. |
|
|
|
I may have missed it, but: What does the GPU0 thread 0 interleave adjust xxx ms means? |
|
|
|
What's a good power draw from the wall for a 6 card rig? (4) Shappire 580s and (2) Power Color 590s.
Say for CNR and CRV8_Reverse Waltz?
With 3x 580 and 1x570, i am getting ~470-490w at wall, depending on ambient temp. Depending on clocks, you can get probably around 650-700W for 6 GPUs. |
|
|
|
Hi, i just discovered your miner and i would like to thank you for impressive work.
I have an annoying card (a RX560), and i've tweaked it a lot, trying several miners, several settings here and there, but never got something close to her "sisters".
For the first time, without changing anything, a part of the gap (1/3rd) is finally filled.
So, again, thanks.
The 460/550/560 cards do half of the *70/*80/*90 cards. They got half the memory chips. |
|
|
|
Shouldn't we revive this thread now that people can finetune the old GDDR5 public timings with amd mem tweak?  Can we? Micron MT51J256M32: 777000000000000022AA1C00CE615C4190551014B68C450A0060040074081420EA8900AB0200000 01712262BA42C3714 ETH 33.6mh/s Straps and speeds, without used core and memory clocks feel incomplete  Also, everyone can make a strap for Ethash. Try for CN. |
|
|
|
Well guys. At last Ive installed W10. AMD official driver 19.4.3 Wattomine for OC/UV (btw, saves its configuration in an xml file, like OverdriveTool) Atm same hashrate and performance than Minerstat. It's early to know if any GPU will die or when. Finally, Ive two questions about these parameters. Ive never used it, but i find it awesome: Check your dead GPU, restart system, ... cool! Same. Ive never setup that, but from what I've been reading, it serves to monitor the miner from other machines and/or via web. [/list] Do you use these options? Any usage/guide recommendation? No, the API is not web based, you do not have httpd server in the miner. Although, if you try to access it via the browser, you will get the JSON response as well. |
|
|
|
|
Show Posts
