Anyone figured out why phoenix slowly degenerates from full load to sine wave?

[PcChip]

Upon a fresh restart of Phoenix 1.48 / 1.50 miner with PhatK Kernel, the load stays at 99% with maximum hashrate.

However during the course of several days it slowly degenerates from a straight line into first a small sine wave from 99-95%, then after a few more days it degenerates to a larger sine wave all the way down to 99-90%, which is wasting hashing power.  

Restarting the miner resets it back to full load again.

(notice GPU1 has a large sine wave, the dip is where I killed it, and after restarting it's a flat line)

Anyone figured it out ?

[1714913740]

1714913740

[1714913740]

1714913740

[1714913740]

1714913740

[1714913740]

1714913740

[CanaryInTheMine]

Power fluctuation?

[PcChip]

are you... was that... are you kidding ?

[Peao]

maybe vrm temp hitting 120 celsius ?

[BOARBEAR]

use poclbm, i had too much troubles with phoenix and eventually i gave up on it

[TiagoTiago]

Temperature kinda makes sense; the performance of the chips decrease the hotter they get, the hotter they get the less they are doing so they gradually cool down, then when they're cool they start racing again and the cycle starts over...


Though perhaps there is the need for an additional component to throttle things down when it gets hot or it would just stay choking hot, i'm not sure...Hm, perhaps the fan kicks in drawing enough electricity that would otherwise be used by the card to run faster? Dunno really...

[PcChip]

I guess you guys don't read, it is only based on the length of time (usually in days) that phoenix.exe has been running.  

Also, if it was getting too hot and throttling back, the clocks would be lowered but the load would not change (99%)


It has nothing to do with power or heat.  

The performance of the chips decreases the hotter they get, the hotter they get the less they are doing so they gradually cool down, then when they're cool they start racing again and the cycle starts over...

FYI, chips don't "run faster" as they cool down, or "run slower" as they heat up; they run at whatever speed the clock generator crystal is set at.  If a video card has a thermal throttling circuit, when it overheats it will change its clocks and voltage to lower levels until it reaches normal operating temperatures, and then return to normal.  The silicon doesn't automatically run faster based on temperature.

[TiagoTiago]

Doesn't the performance degrades with increased temperature?

[Xephan]

Doesn't the performance degrades with increased temperature?

Temperature alone doesn't degrade performance. The chip will continue to attempt to work at the clock speed until temperature either causes errors or kills it.

[c00w]

The persistent agent connection used to connect to servers probably has a bug which is messing up the reactor and thus everything else. see _newclient4320.py and client4320.py in minerutils.

[PcChip]

The persistent agent connection used to connect to servers probably has a bug which is messing up the reactor and thus everything else. see _newclient4320.py and client4320.py in minerutils.

c00w I know you're one smart mofo, so I'm not going to question that you know what you're talking about.  However, I am going to question where the hell I find _newclient4320.py, client4320.py, and minerutils in the Phoenix1.5 zipfile, because for the life of me I know not of what you speak

[simonk83]

Yep, I'm seeing this as well.  I normally mine at 442Mhash (x2) with full 99% load.  I just noticed the load was wobbling about all over the shop, and along with it the hash rate (fluctuating down to 400 and anywhere in between).

Restarted the client (AOCLBF 1.75) and we're back at a solid 99% and 442Mhash.

If anyone works out how to fix this, that'd be great (I'm not smart enough to go fishing around in the py files without instructions )

[c00w]

See if turning off LP fixes it. client4320 is in minerutils/something. Its one of the folders. And it is only used in longpolling. I hope.

[bcforum]

Check you memory usage. The is a rumor going around that phoenix has a memory leak.

[paraipan]

I've seen that too in phoenix miner,and LP doesn't work like it should be, waiting for 1.55 to fix some issues for everybody
btw, it's the fastest miner for my hardware so I will not be giving up on him

[FalconFour]

I can't really explain what's going on in your case, because quite frankly I have no idea what the fuck I'm looking for in your oversized, full-res-posted, non-scrollable screenshot (too much shit going on and no labels)...

But I can tell you one thing: yes, processors (GPU, CPU, any kind of complex, self-monitoring and managing chip) WILL actually slow down based on thermal response. Google "intel thermal monitor" to get a more in-depth look at one example (and keep in mind, the throttling is done INVISIBLE to the user on older TM1 chips like the Pentium 4). If a chip is overheating it can delay execution and slow its clock settings/insert "halt" instructions to throttle the chip and cool it off.

Just to get that out of the way.

[DeathAndTaxes]

Also, if it was getting too hot and throttling back, the clocks would be lowered but the load would not change (99%)

False.  The videocard throttle back LOAD not clockspeed.  Check your VRM temps.  If your VRM isn't getting solid cooling after an extended period of working 24/7 (something AMD never planned on) they will be hitting 110-120 deg when that happen current limit kicks in and starts taking GPU offline for x% of cycles to reduce thermal output.  The throttling seems to vary by cards but happens around 110-120 deg on VRM.  Note this is VRM temp not GPU temp.  A utility like GPU-Z should show you VRM temp (some lower end cards don't report VRM temp though).

Now this may NOT be caused by VRM temp but you belief that thermal throttling will show up as frequency change is 100% incorrect.

[DeathAndTaxes]

If a video card has a thermal throttling circuit, when it overheats it will change its clocks and voltage to lower levels until it reaches normal operating temperatures, and then return to normal.  The silicon doesn't automatically run faster based on temperature.

Not true.  Dynamically changing voltage and frequency is hard to handle and hard to estimate thermal load.  When VRM overheats it simply idles the card for some % of clock cycles bringing average current and thermal output back inline.  Far faster, far simpler, and has far less unforseen consequences than trying to dynamically adjust voltage and frequency.  When current protection kicks in you will see this as a drop in load % (which is actually load average over one second).  If you had milisecond resolution on your graph you would see it as load of 100% then drops to 0% periodically then back to 100%.  That averages out to 99%, 97%, 95%, or 90% over one second.