Claymore (OP)
Donator
Legendary
Offline
Activity: 1610
Merit: 1325
Miners developer
|
 |
June 27, 2016, 06:00:45 AM |
|
Claymore, will there be plans to make the miner more efficient with newer drivers to support the release of the Radeon RX 480?
As soon as I get that card I will select best driver version and update miner. Is it possible to solo with Sammy007's proxy? If not, any way to get the statistics that it provides, mainly blocks per rig?
It must work though miner cannot pass rig name in HTTP solo mode. You can see stats via EthMan, every share in solo mode is a block. Hi Claymore, I am currently testing a rig with multi GPUs on CDMv4.6 During test, I noticed that an isolated spike in temperature went to 100c and very quickly went down to normal (60s). Unfortunately, the switches that i have used triggered CDM to shut down that GPU. The temp spike was really isolated... My question: for determining genuine high temp on GPUs, can CDM ignore temp spikes? Thanks
Do you think it's a good idea to add a pause before disabling overheated GPU? I'm not sure.
|
|
|
|
citronick
Legendary
Offline
Activity: 1834
Merit: 1080
---- winter*juvia -----
|
 |
June 27, 2016, 06:48:25 AM |
|
Hi Claymore, I am currently testing a rig with multi GPUs on CDMv4.6 During test, I noticed that an isolated spike in temperature went to 100c and very quickly went down to normal (60s). Unfortunately, the switches that i have used triggered CDM to shut down that GPU. The temp spike was really isolated... My question: for determining genuine high temp on GPUs, can CDM ignore temp spikes? Thanks
Do you think it's a good idea to add a pause before disabling overheated GPU? I'm not sure. I think even a quarter of a second, may help so that CDM can be very sure that this is a genuine temperature increase and not a "odd electronic surge", perhaps a user define switch if its not too much coding effort. Thanks
|
If I provided you good and useful info or just a smile to your day, consider sending me merit points to further validate this Bitcointalk account ~ useful for future account recovery...
|
|
|
Claymore (OP)
Donator
Legendary
Offline
Activity: 1610
Merit: 1325
Miners developer
|
 |
June 27, 2016, 07:09:48 AM |
|
Hi Claymore, I am currently testing a rig with multi GPUs on CDMv4.6 During test, I noticed that an isolated spike in temperature went to 100c and very quickly went down to normal (60s). Unfortunately, the switches that i have used triggered CDM to shut down that GPU. The temp spike was really isolated... My question: for determining genuine high temp on GPUs, can CDM ignore temp spikes? Thanks
Do you think it's a good idea to add a pause before disabling overheated GPU? I'm not sure. I think even a quarter of a second, may help so that CDM can be very sure that this is a genuine temperature increase and not a "odd electronic surge", perhaps a user define switch if its not too much coding effort. Thanks What I cannot understand is how your GPU can change temperature so fast. It takes a few seconds to warm GPU by 10-15C. Did you remove cooling system?
|
|
|
|
osnwt
|
 |
June 27, 2016, 07:25:37 AM |
|
What I cannot understand is how your GPU can change temperature so fast. It takes a few seconds to warm GPU by 10-15C. Did you remove cooling system? In some cases, usually when risers are used, PCI-e bus can give wrong data reading temps. Usually it is not 100, but 511. But if that was the case, GPU usually does not behave right after that anyway.
|
|
|
|
Claymore (OP)
Donator
Legendary
Offline
Activity: 1610
Merit: 1325
Miners developer
|
 |
June 27, 2016, 07:29:09 AM |
|
With 4.6, Single 7970GPU(1150,1500), the gpu hangs after some hours and stops working. Hashrate: 20.5+ With 4.5, Single 7970GPU(1150,1500), the gpu 100% Stable. Hashrate: 20.2- Why its not stable?
Both 4.5 and 4.6 use same OpenCL kernels, so hashrate and stability must be the same...
|
|
|
|
osnwt
|
 |
June 27, 2016, 07:30:36 AM |
|
v4.6: - bug fixes.
Can you confirm if it has any stability improvements on Linux regarding statistics socket? 4.4 had issues, 4.5 didn't have as I thought but there was a report of them here. Today I also found the issue of loosing socket by 4.5 on Linux. What about 4.6, were any changes done for it? Since you twice ignored this question, I assume the answer is "No changes, Linux 4.6 telemetry still is unstable". Due to reject issues with 4.6 and some pools I set back to 4.5. After running two rigs for ~45 hours both at the same time and same uptime had lost telemetry sockets, still running fine for mining. I am sending you links to both full logs in PM. Error: no response Last seen: 2016-06-25 06:40:45
Error: no response Last seen: 2016-06-25 06:42:01
Any chances to have stable telemetry on Linux? Or should I finally write an own process monitor and restart miner when telemetry is lost? I still cannot reproduce this issue. PM me, I can send you a debug version with more detailed log, it seems it's the only way to fix this problem. I PMed you at the same time as I wrote it and sent links to full logs. PM was not answered. Now I repeated the case. Again, both rigs started at the same time stopped responding at the same time. That is common, the uptime - it is around 45 hours. I think some timer overflows with that period.
|
|
|
|
Claymore (OP)
Donator
Legendary
Offline
Activity: 1610
Merit: 1325
Miners developer
|
 |
June 27, 2016, 07:59:13 AM |
|
v4.6: - bug fixes.
Can you confirm if it has any stability improvements on Linux regarding statistics socket? 4.4 had issues, 4.5 didn't have as I thought but there was a report of them here. Today I also found the issue of loosing socket by 4.5 on Linux. What about 4.6, were any changes done for it? Since you twice ignored this question, I assume the answer is "No changes, Linux 4.6 telemetry still is unstable". Due to reject issues with 4.6 and some pools I set back to 4.5. After running two rigs for ~45 hours both at the same time and same uptime had lost telemetry sockets, still running fine for mining. I am sending you links to both full logs in PM. Error: no response Last seen: 2016-06-25 06:40:45
Error: no response Last seen: 2016-06-25 06:42:01
Any chances to have stable telemetry on Linux? Or should I finally write an own process monitor and restart miner when telemetry is lost? I still cannot reproduce this issue. PM me, I can send you a debug version with more detailed log, it seems it's the only way to fix this problem. I PMed you at the same time as I wrote it and sent links to full logs. PM was not answered. Now I repeated the case. Again, both rigs started at the same time stopped responding at the same time. That is common, the uptime - it is around 45 hours. I think some timer overflows with that period. I get a lot of PMs, usually I answer all, but can miss some, sorry. I will PM you debug version today, it looks like resources leak instead of time overflow, but I cannot debug/handle such thing in Linux properly, it's not my primary OS.
|
|
|
|
osnwt
|
 |
June 27, 2016, 08:03:29 AM |
|
I get a lot of PMs, usually I answer all, but can miss some, sorry. I will PM you debug version today, it looks like resources leak instead of time overflow, but I cannot debug/handle such thing in Linux properly, it's not my primary OS.
That might be the memory leak since I reported you about that already. Now I still use 4.5 after 7 hours of total rejects @ Dwarf with 4.6 for both rigs. I can run the debug version but do not like an idea of having another few hours of rejects  Unfortunately I can't help with memory leak debug for closed source software.
|
|
|
|
Claymore (OP)
Donator
Legendary
Offline
Activity: 1610
Merit: 1325
Miners developer
|
 |
June 27, 2016, 08:19:27 AM |
|
I get a lot of PMs, usually I answer all, but can miss some, sorry. I will PM you debug version today, it looks like resources leak instead of time overflow, but I cannot debug/handle such thing in Linux properly, it's not my primary OS.
That might be the memory leak since I reported you about that already. Now I still use 4.5 after 7 hours of total rejects @ Dwarf with 4.6 for both rigs. I can run the debug version but do not like an idea of having another few hours of rejects  Unfortunately I can't help with memory leak debug for closed source software. It's not a memory leak. I'd like to see the log with rejects. Anyway, I'll send you a debug version soon.
|
|
|
|
osnwt
|
 |
June 27, 2016, 08:37:53 AM |
|
That might be the memory leak since I reported you about that already. Now I still use 4.5 after 7 hours of total rejects @ Dwarf with 4.6 for both rigs. I can run the debug version but do not like an idea of having another few hours of rejects  Unfortunately I can't help with memory leak debug for closed source software. It's not a memory leak. I'd like to see the log with rejects. Anyway, I'll send you a debug version soon. No, no. These are two different issues. Rejects I saw with 4.6 right after release when switched from 4.5 in a hope to get fixed the telemetry problems. It run without logs since there was no issues with rejects until 4.6. So I cannot show those logs. Now I run 4.5 again that has no such issues. But the memory leak is obvious and easily observed. If you run the program 'top', you'll see that the miner process consumes around 1M per second of virtual memory. Probably that is the reason why telemetry got dropped. You close the socket after every request and probably something leaks. I expected to open the control connection once and then just send requests and get replies over the same socket. Please check the 'top' output on Linux and I am sure you will fix that leak easily.
|
|
|
|
osnwt
|
 |
June 27, 2016, 08:41:57 AM |
|
Also I can definitely confirm that the memory leak is directly related to the telemetry. I stopped the monitoring and found no memory leaks using the same top output. As soon as I started the monitor again, the leak resumed.
More info found, I'll PM it to you.
|
|
|
|
|
Claymore (OP)
Donator
Legendary
Offline
Activity: 1610
Merit: 1325
Miners developer
|
 |
June 27, 2016, 11:53:54 AM |
|
|
|
|
|
merc84
|
 |
June 27, 2016, 12:16:57 PM |
|
If u wish to vote for soft-fork then mine on a pool that is running soft-fork supported geth 1.4.8. Coinotron is running this version of geth, however they have also opened an alternate port that allows you to vote against soft-fork. I read around that some other pools are running the softfork version of geth also, you should investigate if ur pool is doing so or change appropriately.
|
|
|
|
kirilvvbg
|
 |
June 27, 2016, 12:31:18 PM |
|
Hi, Claymore, Hi, guys,
Can you please help me. I've noticed that the miner is getting stuck several times in the past few days. So I have carefully read "red lines" and it says error 10004. The miner restarts after this error. But few minutes later same error - miner restarts again and get stuck on "POOl/SOLO...." text.
What is this error? And where is the problem, i.e. what should I do to fix it? Thank you.
|
|
|
|
citronick
Legendary
Offline
Activity: 1834
Merit: 1080
---- winter*juvia -----
|
 |
June 27, 2016, 03:08:11 PM |
|
|
If I provided you good and useful info or just a smile to your day, consider sending me merit points to further validate this Bitcointalk account ~ useful for future account recovery...
|
|
|
madmartyk
Legendary
Offline
Activity: 2730
Merit: 1030
Yes I am a pirate, 300 years too late!
|
 |
June 27, 2016, 03:11:47 PM |
|
anyone got any lines on who is taking pre-orders for the AMD RX 480s yet?
|
|
|
|
Claymore (OP)
Donator
Legendary
Offline
Activity: 1610
Merit: 1325
Miners developer
|
 |
June 27, 2016, 03:14:14 PM |
|
Hi, Claymore, Hi, guys,
Can you please help me. I've noticed that the miner is getting stuck several times in the past few days. So I have carefully read "red lines" and it says error 10004. The miner restarts after this error. But few minutes later same error - miner restarts again and get stuck on "POOl/SOLO...." text.
What is this error? And where is the problem, i.e. what should I do to fix it? Thank you.
It's uncommon error, something is wrong with winsock. You can PM me the log.
|
|
|
|
Trimegistus
Legendary
Offline
Activity: 1565
Merit: 1027
|
 |
June 27, 2016, 03:17:32 PM |
|
|
|
|
|
osnwt
|
 |
June 27, 2016, 03:21:10 PM |
|
And strictly speaking, they're right. Any fork breaks the main idea of blockchain, making Ethereum NOT that declared on their main page. The worst thing is that so called hacker may be wrong in general, but strictly complied with the terms of TheDAO contract. Any fork means that a 3rd-party changes the rules of the game on the fly in favor of someone just because some business made something wrong and lost some investments. Any investment is a risk, and they should learn the lesson, fix it and move on. Instead, due to conflict of interests being in both Ethereum foundation and TheDAO curators, they decided to prove the world that they are right to break own rules just because they lost some money due to own fault. Be that a smaller project that failed, no one would ever thought about any forks. But this one just "too big to fail", and that's sad. No any polls and votes should be treated as the network consensus - they just mean that people trust to the founders without own investigation. If one said 'theft', they do not do own judgement. And just led by a false goal. Killing the whole Ethereum thing as a result.
|
|
|
|
|