Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v15.0 (Windows/Linux)

[Claymore]

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.

[1714184702]

1714184702

[1714184702]

1714184702

[1714184702]

1714184702

[citronick]

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

[Claymore]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[restless]

2 Claymore

What about https://github.com/ethereum/go-ethereum/releases/tag/v1.4.8

Should you update your miner? As your miner has great % of ether mining, is running unupdates miners is voting anti-soft-fork may cause problems 0-o

[Claymore]

2 Claymore
What about https://github.com/ethereum/go-ethereum/releases/tag/v1.4.8
Should you update your miner? As your miner has great % of ether mining, is running unupdates miners is voting anti-soft-fork may cause problems 0-o

https://bitcointalk.org/index.php?topic=1433925.msg15356732#msg15356732

[merc84]

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]

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]

suprnova closes their ETH pool...

https://bitcointalk.org/index.php?topic=1163395.msg15383242#msg15383242

[madmartyk]

anyone got any lines on who is taking pre-orders for the AMD RX 480s yet?

[Claymore]

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]

anyone got any lines on who is taking pre-orders for the AMD RX 480s yet?

B&H but the prices are outrageous...

Check it out:

http://www.bhphotovideo.com/c/product/1261505-REG/index.html

http://www.bhphotovideo.com/c/product/1261970-REG/msi_radeon_rx_480_8g_rdn_rx_480_gddr5.html

[osnwt]

suprnova closes their ETH pool...

https://bitcointalk.org/index.php?topic=1163395.msg15383242#msg15383242

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.