re: cpu temperature readings
> > though NetBSD's cpu selection algorithm doesn't (yet anyway) really > > understand processors like this. > > The scheduler did use first cores first, with performance cores > using low cpu numbers, they should be utilized first but not > necessarily for the important workloads. > > It now handles big.little configurations independent of cpu numbers, > but probably only on arm. our scheduler has a fast/slow CPU method only, so it handles "HT" by saying the non-1st sibling is slow, and the 1st one attached is fast, and for big.little/dynamiq it just marks the big cores as fast and little cores as slow. it then prefers fast cores over slow cores, and it will typically select lower cpu numbers once within the fast/slow zone. eg, on rk3399, cpu4 and cpu5 are used first for most tasks as they're the big cores, and cpu0 ends up getting a lot of random interrupts, and cpu1-3 are idle unless you're using more than 3 cores of CPU. this means that the 3-level speed provided by the newer intel client cpus is not handled by our code, and i believe it means it will not give up and not attempt any special and will thus just end up using cpu numbers. i had a look at converting the "bool cpu_is_slow" in cpu_data into an integer, but i didn't get far enough understanding all the current uses to properly know where to start. would be great if someone where to have a look at this. one hack to make thing work "sort of OK", would be to allow this to have one thread of the e-cores as fast, and both the other thread and the p-cores as slow. .mrg.
Re: cpu temperature readings
Sorry, no, I can't test, the system looks to have died, and certainly needs repairs, it looks as if the cooler might be dead (not sure about the cpu at the minute, it won't even boot to the stage where the BIOS enables the display) However, much of what your patch does (according to your description, at the minute my method of e-mail access doesn't rise to looking at attachments) is what I actually put in the kernel I was running. I didn't change the lower limit on the range, for me that was clearly not a problem, and I made the upper limit 130 instead of 120 (though as it turned out, either would do). My system sets Tjmax to 115. That seems to be a constant, every read of the register, on all cores, produces 115 (I added a diagnostic to tell me if it ever changed). I can't comment on what should be done in the case of the value being outside the expected range - I don't know enough about PC hardware to know whether or not there are systems which might return garbage in that register - if there are, then settling on a default to use sounds like the right way, but if nothing is known to do that, thenjust believing what the CPU says (as we do with any other register) - with or without a disgnostic to the console would probably be better. This time (Weds evening) when the system shut down, I had just finished a build, and run (some) ATF tests to check some changes I was making to sh quoting in some of the test scripts (there is some horribly bogus nonsense around... though as long as the data being used doesn't change there would be no adverse effects in the tests I looked at, so the change I was working on should be made, but won't actually change any results - the ATF test runs I did verified that). During the build the core temps were fluctuating about Tjmax (115) which I didn't consider all that abnormal (the previous build I did, before the Tjmax adjustment, did much the same thing). The difference this time was that things never cooled down after the build finished. Further, before I could get to commit the changes, the "critical temp" bit started being set (all cores) and powerd shut down the system. I had a diagnostic to print the register that has the bit in it, and also (if it managed to read properly) the temp that had been read (in micro-kelvins, as the value has been converted by this time). I took a photo of the data on the screen while (some of) that data was visible, if it is likely to be useful to anyone. (That's on my phone, so no problem accessing it). Note that until my system gets repaired (and I won't even start looking for a local reputable repair place until Monday at least) I am going to be fairly sluggish accessing e-mail (I won't be looking very frequently, and might easily miss messages when I do look, as I get to see incoming messages without any spam filtering yet when I access it this way). kre
Re: cpu temperature readings
Hi, all. Could you test the following diff? http://www.netbsd.org/~msaitoh/coretemp-20230707-0.dif In the draft of the commit message: -- coretemp(4): Change limits of Tjmax. - Change the lower limit from 70 to 60. At least, some BIOSes can change the value down to 62. - Change the upper limit from 110 to 120. At least, some BIOSes can change the value up to 115. - Print error message when rdmsr(TEMPERATURE_TARGET) failed. #if 1 - Print error message when Tjmax exceeded the limit. #else - When Tjmax exceeded the limit, print warning message and use the value as it is. #endif -- In "#if 1" part, The default value (100) is used for Tjmax if it exceeded the limit. It's the same as before except the range of the limit. In "#else" part, the read value is used as it is even if it exceeded the limit. Which one do you think is better? -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: cpu temperature readings
k...@munnari.oz.au (Robert Elz) writes: >So my current guess (and it is no more than that) would be that if >powerd happens to notice that happening, which would require it to >look at just the right time, then powerd does a system shutdown. >If powerd doesn't notice quickly enough, the CPU (or BIOS perhaps) >sees that things are getting too hot, and no-one is taking any corrective >action, and simply kills the power. The overheating flag persists, i.e. "somewhen overheated in the past". >I suppose it is possible that when the temp rises very rapidly, very >quickly, as in when doing CPU intensive work, at high speed, the cooler >also ramps up, and cools at max rate, whereas when the CPU temp just >creeps up slowly, the cooler doesn't notice it happening, and fails to >react - but that seems kind of unlikely to me, It certainly doesn't >seem like the kind of problem that can be caused by thermal paste (or >the lack thereof). The Cooler is much slower than the (small) die. Any rapid temperature change is buffered by the heat sink (better if there is good conductivity). Air or water carry away the energy, but slowly. I'd rather think that an idle core that is put to "turbo" speeds is clocked higher and produces heat faster than can be buffered by the heat sink. But if the machine is busy, none of the cores actually reaches the extreme clock rates and there are no short term heat peaks that trigger the "critical" flag. That's all just guessing. But if a better connection between CPU and heat sink helps, it might be right.
Re: cpu temperature readings
Date:Sun, 2 Jul 2023 11:43:35 +0200 From:Michael van Elst Message-ID: | Yes. That bit also triggers powerd. So my current guess (and it is no more than that) would be that if powerd happens to notice that happening, which would require it to look at just the right time, then powerd does a system shutdown. If powerd doesn't notice quickly enough, the CPU (or BIOS perhaps) sees that things are getting too hot, and no-one is taking any corrective action, and simply kills the power. That would explain the shutdown types I'm observing. | It's also possible that the heat sink needs attention (re-apply thermal | paste or similar), this might prevent the CPU from reaching a critical | temperature. That's possible - but the reason I haven't really been looking at the cooling system (which is, after all, the obvious place to look) is that when things are legitimately hot (when the CPU really is working hard) it seems to be very effective in cooling it again, quite quickly. I suppose it is possible that when the temp rises very rapidly, very quickly, as in when doing CPU intensive work, at high speed, the cooler also ramps up, and cools at max rate, whereas when the CPU temp just creeps up slowly, the cooler doesn't notice it happening, and fails to react - but that seems kind of unlikely to me, It certainly doesn't seem like the kind of problem that can be caused by thermal paste (or the lack thereof). But I really know nothing about any of the factors involved here. kre
Re: cpu temperature readings
On Sun, Jul 02, 2023 at 04:16:51PM +0700, Robert Elz wrote: > > if ((msr & MSR_THERM_STATUS_CRIT_STA) != 0) > edata->state = ENVSYS_SCRITICAL; > > that is, rather than reaching some configured limit, simply being told > by the cpu that the status is critical ? Yes. That bit also triggers powerd. > | or something completely > | different (motherboard power regulators or even the PSU?). > > Certainly. Anything is possible. I suspect something changed > (broke, or wore out) about a month ago - clearly it is marginal, and > only seems to affect things in turbo mode (higher power draw), as > this is a new phenomenom in the past month or so. It's also possible that the heat sink needs attention (re-apply thermal paste or similar), this might prevent the CPU from reaching a critical temperature. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: cpu temperature readings
Date:Sun, 2 Jul 2023 08:11:59 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | In the end that means the chip either won't reach it's maximum turbo | speed, or only for a shorter time, or only when cooled better. The | value that corresponds to this is called cTDP (and usually used | to raise the value for extreme overclocking, but it can also be | reduced). Next time I am in the BIOS I will look more carefully for something related to that. There are vast numbers of settings, most of which I have never seen... (never had a reason to look). | The values probably come from ACPI. I first thought there was a limit | of 16 states, but we (arbitrarily) have a limit of 256. So either | ACPI doesn't show all states that you can see in the BIOS interface | or we have a bug. This is an extraordinarily unimportant issue, but if I find some free time I will see if I can add some debugging to observe what is happening with that. | coretemp doesn't have thresholds, so it cannot trigger powerd to shut down. That's weird then, as while most times I have no idea what is causing the halt (poweroff) I have certainly observed a couple of occasions when it was certainly powerd shutting things down based upon over temps (I haven't configured any limits). Once I was ssh'd in from my phone when it happened, and as that was a login I got powerd's broadcast messages. Those shutdowns feel different than the others though, things seem to sequence through the normal shutdown steps. Could the powerd behaviour perhaps be related to these couple of lines in arch/x86/x86/coretemp.c:coretemp_refresh_xcall() if ((msr & MSR_THERM_STATUS_CRIT_STA) != 0) edata->state = ENVSYS_SCRITICAL; that is, rather than reaching some configured limit, simply being told by the cpu that the status is critical ? In my recent changes I added a debug printf (with relevant data included) if that ever happens, which I haven't ever seen - but if the system shuts down quickly enough, there's no guarantee I would. But there is no question that I saw powerd shut the system down based upon over temp, twice I know of (a small fraction of all the shutdowns), and coretemp provides the only temperature related info available to the system (well, I guess there is drive temp, from SMART, but that wouldn't shut the system down, and none of the drives has ever reached its upper limit - though some have come close once or twice), and there may be temp sensors in the DIMMs, but nothing I'm aware of is accessing those. | Immediate power off also doesn't suggest that this is a shutdown. Yes, agreed, or not a normal one anyway. At least most of the time. | I would | guess it's either the CPU reaching its limit (unlikely to your description, I'm less sure how unlikely it is, as: | but the temperature can change very very quickly) it certainly does that (if I am doing a -j16 build, it will, using the old code (Tjmax==100) ramp up to 90 (which probably was really 105) quite quickly - but then cool down again just as quickly when a brief gap in the cpu intensive part of the build happens. I have done several builds during this period of instability, and the system has never halted during any of those. But when it is just idling (mostly) in turbo mode, the temps seem to stay fairly stable for a while (hours perhaps) then go up a degree or two, then more quickly, rise again, and then again even more quickly, and possibly by a bit more. Since the at rest idle temp in turbo mode (new code, with Tjmax==115) seems around 50, that I had observed temps about 60 (as the apparent baseline, not the occasional blip up and down again, which happens all the time, when something runs for a second or two) suggests that this ramp up effect was happening. The higher the temp rises, the faster it rises more, so it easily could have been that. | or something completely | different (motherboard power regulators or even the PSU?). Certainly. Anything is possible. I suspect something changed (broke, or wore out) about a month ago - clearly it is marginal, and only seems to affect things in turbo mode (higher power draw), as this is a new phenomenom in the past month or so. Initially I thought (kind of absurdly perhaps) it may have been somehow related to a very large copy (set of copies) to an external USB drive I was doing, but that finished weeks ago now (there are also I/O performance related issues I will mention later related to that, but as a preview, I once observed a "sync" command take 3 hours to complete). I have been centred around the temperature issue, as that one is at least observable, and has been behaving erratically (though some of that is now explained). | The Z690 Taichi BIOS seems to have an event log, not sure what it actually | logs. Thanks - more for me to look for next time I am in the BIOS. I guess I need to spend some time
Re: cpu temperature readings
k...@munnari.oz.au (Robert Elz) writes: > | You can probably avoid this, if you limit the chip to performance of the > | non-selected die (in real applications it will probably lose 1-5%). The > | BIOS should have a setting for the cTDP value that you can play with. >If I am understanding you, which I might not be, you mean slow down the >fastest cores from 5.5GHz (two cores are currently allowed to run that >fast, I found the settings for that) to (probably) 5.2GHz - the other >6 performance cores are currently limited to that (and I think that's >as fast as they're normally expected to run). Turbo speed is controlled by the power (dissipation) budget. On some CPUs you don't have to control the clock itself, but the available power, and that should also be possible with the i9-12900. In the end that means the chip either won't reach it's maximum turbo speed, or only for a shorter time, or only when cooled better. The value that corresponds to this is called cTDP (and usually used to raise the value for extreme overclocking, but it can also be reduced). I haven't seen such a setting in the Asrock Z690 BIOS though. >[Aside: I also noticed that the BIOS claims that the min available >frequency is 400MHz ... NetBSD thinks 800MHz is as slow as it should go, >that's the min value in machdep.cpu.frequency.available]. The values probably come from ACPI. I first thought there was a limit of 16 states, but we (arbitrarily) have a limit of 256. So either ACPI doesn't show all states that you can see in the BIOS interface or we have a bug. >I got to look at all that as the system shut itself down again in the early >hours of this morning (here) - A/C was on, so room was cool, I had turbo >mode enabled, just to see if it would still cause a problem, and it seems >that it did (at the minute, as long as I leave that off, the system is >stable). coretemp doesn't have thresholds, so it cannot trigger powerd to shut down. > Note that I am still just guessing that thermal issues are what >is causing this, almost always the system is just running fine, with >envstat reporting elevated temperatures, but nothing close to 100 - the >highest I saw before the shutdown were in the low 60's - but I wasn't >actually watching those numbers at the time), and then it is off. >No warning (that I saw anyway) - just off. This time I restarted >immediately, and as soon as I could, looked at the BIOS's cpu temp >value - that was about 36C. But the BIOS doesn't use turbo mode I >don't believe, so it would have been running slower, and the BIOS spends >quite a bit of time doing whatever it does, before it allows any kind of >interaction. Immediate power off also doesn't suggest that this is a shutdown. I would guess it's either the CPU reaching its limit (unlikely to your description, but the temperature can change very very quickly) or something completely different (motherboard power regulators or even the PSU?). On server motherboards you would often have some BMC logging the issue. The Z690 Taichi BIOS seems to have an event log, not sure what it actually logs.
Re: cpu temperature readings
Date:Sat, 1 Jul 2023 13:18:50 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | To support the "turbo" speeds, you need higher voltages and it is plausible | that the voltages need to be set for the worst case because switching the | clock to "turbo" doesn't control the voltages (or not fast/precise enough). That makes sense, thanks for the explanation. | You can probably avoid this, if you limit the chip to performance of the | non-selected die (in real applications it will probably lose 1-5%). The | BIOS should have a setting for the cTDP value that you can play with. If I am understanding you, which I might not be, you mean slow down the fastest cores from 5.5GHz (two cores are currently allowed to run that fast, I found the settings for that) to (probably) 5.2GHz - the other 6 performance cores are currently limited to that (and I think that's as fast as they're normally expected to run). That I can do, I could even make all of then 5Ghz (the max freq, in units of 100MHz, can be set for each core, separately). That minor reduction isn't likely to matter. [Aside: I also noticed that the BIOS claims that the min available frequency is 400MHz ... NetBSD thinks 800MHz is as slow as it should go, that's the min value in machdep.cpu.frequency.available]. I got to look at all that as the system shut itself down again in the early hours of this morning (here) - A/C was on, so room was cool, I had turbo mode enabled, just to see if it would still cause a problem, and it seems that it did (at the minute, as long as I leave that off, the system is stable). Note that I am still just guessing that thermal issues are what is causing this, almost always the system is just running fine, with envstat reporting elevated temperatures, but nothing close to 100 - the highest I saw before the shutdown were in the low 60's - but I wasn't actually watching those numbers at the time), and then it is off. No warning (that I saw anyway) - just off. This time I restarted immediately, and as soon as I could, looked at the BIOS's cpu temp value - that was about 36C. But the BIOS doesn't use turbo mode I don't believe, so it would have been running slower, and the BIOS spends quite a bit of time doing whatever it does, before it allows any kind of interaction. Note "early hours" here means very early, at 14:17 now, the system has now been up 13:44, so the shutdown must have been between 00:00 and 00:30. That's well before cron starts running any of the daily/weekly stuff, so the system should still have been mostly idle (no builds happening, not even cvs update, or anything like that - just a couple of unrelated net downloads happening in the background, and not all that quickly at that, maybe 3Mbps total, probably slightly less). When that happened, I had seen your message, but hadn't formed any real comprehension as to what it might have meant - but that's what inspired me to go looking at BIOS settings I would never normally go near, and where I found (but did not alter) the "max turbo rate" (per core) settings. kre
Re: cpu temperature readings
k...@munnari.oz.au (Robert Elz) writes: >I have been running that kernel now for approaching 18 hours. At boot >time (when coretemp is being attached) Tjmax was read as 115 (on all cores, >I don't know if that's supposed to be a per-core value, or not, but that >doesn't matter), and nothing I have done since (including changing the >cpu frequency target (and actual frequency) has made any difference, it >seems to simply be a constant 115 no matter what (and the effort to read >it every time it is used, rather than just remember what was read first, >seems to be unnecessary - at least on this processor (and perhaps BIOS). That's what I found first, the i9-12900KS (KS for the selected die) actually has a Tjmax of 115C (but would report 100C by default, a value that the BIOS may change). >I have just set the cpu freq to 3401 (enabled the "turbo boost" - though >I am not convinced there's an actual turbocharger in the CPU anywhere) >and the temps more or less immediately rose to the low 50's (a 15 degree >increase). I suppose that is possible, but it seems a bit extreme, just >for enabling higher speed on a system which is really doing nothing that >matters. To support the "turbo" speeds, you need higher voltages and it is plausible that the voltages need to be set for the worst case because switching the clock to "turbo" doesn't control the voltages (or not fast/precise enough). That effect is usually not that noticable, but my guess is that the bias is so much higher for the selected die. You can probably avoid this, if you limit the chip to performance of the non-selected die (in real applications it will probably lose 1-5%). The BIOS should have a setting for the cTDP value that you can play with.
Re: cpu temperature readings
Date:Thu, 29 Jun 2023 20:18:31 +0200 From:Michael van Elst Message-ID: | Unless there is a BIAS on those numbers and the real values are maybe 15 | degrees higher. That's exactly what they were. I added some extra debug code to coretemp.c, to tell me what was being read as Tjmax, every time that value changed (before it was forced to be 100 if the value read was outside the [70,110] range). I also changed that range to be [70,130]. I have been running that kernel now for approaching 18 hours. At boot time (when coretemp is being attached) Tjmax was read as 115 (on all cores, I don't know if that's supposed to be a per-core value, or not, but that doesn't matter), and nothing I have done since (including changing the cpu frequency target (and actual frequency) has made any difference, it seems to simply be a constant 115 no matter what (and the effort to read it every time it is used, rather than just remember what was read first, seems to be unnecessary - at least on this processor (and perhaps BIOS). Currently it is running @3400 and with room temp about 30, core temps (on a mostly idle system) are fluctuating around 40. I have just turned the A/C on (I have been out all day, so it was off) and the room temp is dropping, so are the core temps, that's all fine - more around 36 at the minute, but they will go down as the room cools more. I have just set the cpu freq to 3401 (enabled the "turbo boost" - though I am not convinced there's an actual turbocharger in the CPU anywhere) and the temps more or less immediately rose to the low 50's (a 15 degree increase). I suppose that is possible, but it seems a bit extreme, just for enabling higher speed on a system which is really doing nothing that matters. kre
Re: cpu temperature readings
Date:Thu, 29 Jun 2023 20:18:31 +0200 From:Michael van Elst Message-ID: | Unless there is a BIAS on those numbers and the real values are maybe 15 | degrees higher. Probably 20. That would be more realistic. | I can also easily imagine that temperatures rise with enabled turbo | mode, even when idle, in particular on selected dies like the i9-12900ks. Rise yes, but keep on rising over time? This is a new thing I am just seeing in the past month or so, until then this system was very stable. | The code is supposed to follow the Linux example. If a fixed Tjmax can | be read, then that's it. If no fixed Tjmax can be read, a dynamic value | needs to be read from a new register every time you evaluate the temperature. Yes, apologies - I misread the patch (I have actually looked more at the patched file since ...).That is what it is doing. It is perhaps even doing (or would be if used on the relevant processors) a bit more of that than it should be - I doubt there are processor versions which give an fault when reading one of those registers at one attempt, and then work the next time. | N.B. Asrock says, they would configure Tjmax to 105C for that board. That doesn't seem to be what they have done. Or the people who built the system for me perhaps were meant to, and didn't know to do that. But I have some things to try now, more information to obtain. I will do that later tonight and send another message later. | That happens when that cpu is used by another LWP (maybe a kernel thread | that is bound to that cpu) and the previously running LWP needs to be | migrated. Ah, thanks - that explains what is happening, though isn't really the way I'd like to see things on this system (though it would make sense on a system with homogenous CPUs). I think I'd like to try limiting the kernel threads to the highest numbered (perhaps 4) of the performance cores - those should be plenty fast enough, and lots of systems only have 4 cores, so it should be sufficient. Then processes can use the faster performance cores, and the slower economy cores, with less risk of being needlessly bumped. | It has no idea what a "suitable CPU" is. Yes, I know - that is something that will need code added, somewhere, to provide the information. It could be done as a note in the binary file for processes that need high performance (usually) - like perhaps gcc (and clang) (or the relevant part of those), and ffmpeg, and things like that, and have all the "normal" processes default to the low speed cores (which are still fast by most standards) unless there are none free and a performance core is available. Or better, monitoring the processes dynamically, looking for those which get bumped due to time quantum exceeded without doing (at least, slow) system calls, or lots of fast ones perhaps, and promote those to faster cores, so they will get more done each time they get to run - and then watch processes on those cores, and if they start blocking in system calls, more often then exceeding the time quantum, then move them to slower cores. The actual algorithms would need more thought than this 5 mins worth, and then evaluation for a while to see how the perform under varying loads. | With our simple scheduler strategy that loads one thread per core and | only puts two threads on each core when you have more runnable threads | (except for the bound system threads). Yes, that would probably help a bit - though liking a core and its hyperthread clone to threads from the same process might be a good idea. | On Intel however (at least on this i5), the mapping alternates between | both threads: On all Intel processors with hyperthreading that I have seen. This is the first one I have bought that has had that, I typically looked for a processor without it, just to avoid the nuisance, but there was nothing available in the same class as this processor without it (slower ones of the same generation, but not this). kre
Re: cpu temperature readings
On Thu, Jun 29, 2023 at 08:59:18PM +0700, Robert Elz wrote: > > When I set 3400, which is what I have right now, if that dropped to low 30's, > or high 20's, or just stayed the same while idling as your processor does, > then that would all make sense. But it doesn't. I am running at 3400 now, > and the coretemp readings are: > >Current CritMax WarnMax WarnMin CritMin Unit > [coretemp0] >cpu0 temperature:13.000 degC > Room temperature is about 21C at the minute (A/C maintained). Even remaining > at 3400, if the workload drops even more (I am replying to this mail, which > means keyboard and mouse activity, some disc I/O as well, and the X server > needs to be processing everything - so we can go much more idle than that, > with the screens all off, so the X server has little to do, no keyboard or > mouse activity, ...) then the reported temps will sometimes drop into single > digits (8 or 9 ... I haven't seen less than 8). > > Those values are absurdly low. Unless there is a BIAS on those numbers and the real values are maybe 15 degrees higher. I can also easily imagine that temperatures rise with enabled turbo mode, even when idle, in particular on selected dies like the i9-12900ks. > | One possibility would be that the Tjmax value is actually changed > | dynamically (maybe some SMM code) and that the patch isn't complete > | to handle this. > > The possibility is certainly there. The patch certainly doesn't handle it, > the code has been rearranged in a way that would make it much simpler to do, > but as it is now, it is really just doing the same as before - calculate the > Tjmax value to be used at sensor attach time, and never touch that again. The code is supposed to follow the Linux example. If a fixed Tjmax can be read, then that's it. If no fixed Tjmax can be read, a dynamic value needs to be read from a new register every time you evaluate the temperature. N.B. Asrock says, they would configure Tjmax to 105C for that board. > However, to explain what is being observed, the Tjmax value would need > to be increasing as the cpu frequency decreases, since at the minute we're > using Tjmax==100, and getting 12 as the reported temp, so the value read > and subtracted from Tjmax must be 88. To make that value be somewhere > around 30-35, (which is what I am seeing now ... I just went back to 3401 > mode temporarily) then Tjmax would need to be in the 118-123 range (and so > perhaps 120). That seems a bit unlikely to me (unlikely things are that > simple). 120 seems plausible, an "official" number from Intel was 115. So if Asrock puts 105 instead of 100, then it might also configure 120 instead of 115. > | The scheduler did use first cores first, with performance cores > | using low cpu numbers, they should be utilized first but not > | necessarily for the important workloads. > > Depending upon what that really means, that is, "use first" (use the first > cores *first*) wrt to what? unit numbers. cpu0 before cpu1 before cpu2, etc. This only happens when a core is searched, it doesn't (immediately) migrate LWPs that were started on higher units. There was code to regularly balance LWPs on all cores that was broken, was fixed by myself and then ripped out by ad@. > What's even more peculiar is that we seem to be moving processes from core > to core for no apparent reason, if I am running a single cpu bound process, > I can observe it move from cpu to cpu. That happens when that cpu is used by another LWP (maybe a kernel thread that is bound to that cpu) and the previously running LWP needs to be migrated. > If it was moving processes to a more suitable cpu for the workload, that would > also make sense, but it isn't doing that either. It has no idea what a "suitable CPU" is. > | It now handles big.little configurations independent of cpu numbers, > | but probably only on arm. > > This processor needs more than that, though it would be a start. It has > been quite a while since I looked at the specs for it in detail, but as > I remember it (and assuming we have no hyperthreading to occupy all the > odd numbered cpu numbers, Actually on AMD I mapped one thread of each core to the first cpus and the other thread of each core to the later cpus. I.e. cpu0: Cluster/Package ID 0 cpu0: Core ID 0 cpu0: SMT ID 0 cpu1: Cluster/Package ID 0 cpu1: Core ID 1 cpu1: SMT ID 0 cpu2: Cluster/Package ID 0 cpu2: Core ID 2 cpu2: SMT ID 0 ... cpu16: Cluster/Package ID 0 cpu16: Core ID 0 cpu16: SMT ID 1 cpu17: Cluster/Package ID 0 cpu17: Core ID 1 cpu17: SMT ID 1 ... With our simple scheduler strategy that loads one thread per core and only puts two threads on each core when you have more runnable threads (except for the bound system threads). On Intel however (at least on this i5), the mapping alternates between both threads: cpu0: Cluster/Package ID 0 cpu0: Core ID 0 cpu0: SMT ID 0
Re: cpu temperature readings
Another reply to multiple messages in one, but starting from the last one this time, as it is the most important I think. Date:Thu, 29 Jun 2023 13:52:03 +0200 From:Michael van Elst Message-ID: | One possibility would be that the 3401 mode didn't enable turbo frequencies | but actually throttled the CPU (e.g. due to a faulty BIOS). Then the low | temperature readings would have been only a logical consequence. If that was the problem, then yes, that would have been a possibility, but that's backwards. At 3401 the temperature readings look OK (there's still the other problem I was initially seeking, but this one needs to be solved first). At slower cpu frequencies, the temperatures are lower. That, when simply stated, with just that much info, looks like it deserves a "That is how it should be, run slower, generate less heat" response - as indicated by the data you gave in your previous message: Date:Thu, 29 Jun 2023 13:45:11 +0200 From:Michael van Elst Message-ID: | The Haswell CPU here (room temperature about 27C) runs idle at about 40C | when clocked at minimum 800, but heats up to 47C when idling at 3300 and | there is no difference to 3301. That kind of thing is what I'd expect to see. But that isn't what I am seeing, if I set 3401 as the target frequency (turbo mode - which Intel still calls it) the temperatures of the cores (when idling) probably range in the low 30's to low 40's range (as reported, how that relates to real heat in the chip is anyone's guess - but the BIOS also reports those kinds of values). When I set 3400, which is what I have right now, if that dropped to low 30's, or high 20's, or just stayed the same while idling as your processor does, then that would all make sense. But it doesn't. I am running at 3400 now, and the coretemp readings are: Current CritMax WarnMax WarnMin CritMin Unit [coretemp0] cpu0 temperature:13.000 degC [coretemp1] cpu1 temperature:13.000 degC [coretemp10] cpu10 temperature:15.000 degC [coretemp11] cpu11 temperature:15.000 degC [coretemp12] cpu12 temperature:14.000 degC [coretemp13] cpu13 temperature:14.000 degC [coretemp14] cpu14 temperature:14.000 degC [coretemp15] cpu15 temperature:14.000 degC [coretemp2] cpu2 temperature:14.000 degC [coretemp3] cpu3 temperature:13.000 degC [coretemp4] cpu4 temperature:13.000 degC [coretemp5] cpu5 temperature:15.000 degC [coretemp6] cpu6 temperature:12.000 degC [coretemp7] cpu7 temperature:13.000 degC [coretemp8] cpu8 temperature:15.000 degC [coretemp9] cpu9 temperature:15.000 degC Room temperature is about 21C at the minute (A/C maintained). Even remaining at 3400, if the workload drops even more (I am replying to this mail, which means keyboard and mouse activity, some disc I/O as well, and the X server needs to be processing everything - so we can go much more idle than that, with the screens all off, so the X server has little to do, no keyboard or mouse activity, ...) then the reported temps will sometimes drop into single digits (8 or 9 ... I haven't seen less than 8). Those values are absurdly low. There doesn't seem to be much (if any) difference between the temps being reported whether the frequency is 3400, or 800 (highest and lowest available fixed frequencies). Maybe just one or two degrees less at 800 than at 3400 (when mostly idling ... not fully idle right now, there's also some network traffic at the minute - has been throughout this reply). | The xx01 frequency sets the maximum base clock and enables turbo mode... | on systems that support such a setting. | | On "modern CPUs" however, it is often sufficient to stay on that setting That's what I used to do, before I started getting the original problem (not yet really reported, as I don't yet have much of an idea what is happening) - but as a first guess, the cores seemed to be overheating, or at least powerd thought they were (powerd gets the same info as envstat, which also showed rising temperatures) - this usually happening when the system was idle (or mostly idle, there are all the usual low cpu usage background noise processes running - clocks, cron, inetd, nothing that normally causes even a blip in apparent cpu used). In fact,
Re: cpu temperature readings
On Thu, Jun 29, 2023 at 06:01:28PM +0700, Robert Elz wrote: > It is, and I'm aware of it. I'm not sure why Michael wanted to know > whether the speed was actually being altered or not, One possibility would be that the 3401 mode didn't enable turbo frequencies but actually throttled the CPU (e.g. due to a faulty BIOS). Then the low temperature readings would have been only a logical consequence. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: cpu temperature readings
On Thu, Jun 29, 2023 at 12:03:33PM +0200, Rhialto wrote: > On Thu 29 Jun 2023 at 16:50:27 +0700, Robert Elz wrote: > > And then for fun, at 3401 ... this one I needed to run the test several > > times until the kernel picked one of the fastest processors to run it on > > When I was muddling with estd to dynamically slow down my cpus when not > in use, I was told that the xx01 frequency on modern (Intel) processors > will do that, even though in many sources that setting is still called > "turbo boost" or similar. The other frequencies would actually be fixed. > In your cpu this may be the case too, which would give confusing results > if you're not aware of the possibility. The xx01 frequency sets the maximum base clock and enables turbo mode... on systems that support such a setting. On "modern CPUs" however, it is often sufficient to stay on that setting as "racing to completion" needs the least power. To some degree however this assumes that the CPU enters a low-power idle mode when "complete", so YMMV on NetBSD. The Haswell CPU here (room temperature about 27C) runs idle at about 40C when clocked at minimum 800, but heats up to 47C when idling at 3300 and there is no difference to 3301. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: cpu temperature readings
On Thu, Jun 29, 2023 at 04:50:27PM +0700, Robert Elz wrote: > It looks to me as if the frequency adjustments are working properly, Then it gets really strange what the temperature sensor would see. One possibility would be that the Tjmax value is actually changed dynamically (maybe some SMM code) and that the patch isn't complete to handle this. > though NetBSD's cpu selection algorithm doesn't (yet anyway) really > understand processors like this. The scheduler did use first cores first, with performance cores using low cpu numbers, they should be utilized first but not necessarily for the important workloads. It now handles big.little configurations independent of cpu numbers, but probably only on arm. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: cpu temperature readings
Date:Thu, 29 Jun 2023 12:03:33 +0200 From:Rhialto Message-ID: | In your cpu this may be the case too, which would give confusing results | if you're not aware of the possibility. It is, and I'm aware of it. I'm not sure why Michael wanted to know whether the speed was actually being altered or not, but since I am seeking help I will supply any information that is requested, and I know how to obtain. That 3401 freq setting, when used on the correct core should give 5500GHz, on others 5300 or 5200, and on others 4000. kre
Re: cpu temperature readings
On Thu 29 Jun 2023 at 16:50:27 +0700, Robert Elz wrote: > And then for fun, at 3401 ... this one I needed to run the test several > times until the kernel picked one of the fastest processors to run it on When I was muddling with estd to dynamically slow down my cpus when not in use, I was told that the xx01 frequency on modern (Intel) processors will do that, even though in many sources that setting is still called "turbo boost" or similar. The other frequencies would actually be fixed. In your cpu this may be the case too, which would give confusing results if you're not aware of the possibility. -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: cpu temperature readings
Date:Thu, 29 Jun 2023 08:27:05 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | You could run a benchmark like 'openssl speed sha256' and compare | the 3400 MHz target and the target and step lower. First, my userland (that I run most of the time anyway) hasn't been updated since the system was installed, just the kernel, and occasional binaries that need it, so this is an oldish openssl, but I doubt that that matters for this purpose, it is the same binary in all tests. I "primed the cache" by running it once before these tests started, so they should all have a similar starting point. I made the cpu frequency adjustments from another window (where I have a root shell). At 3400: jacaranda$ openssl speed sha256 Doing sha256 for 3s on 16 size blocks: 8539390 sha256's in 2.99s Doing sha256 for 3s on 64 size blocks: 4782823 sha256's in 2.98s Doing sha256 for 3s on 256 size blocks: 1926335 sha256's in 2.98s Doing sha256 for 3s on 1024 size blocks: 554719 sha256's in 3.00s Doing sha256 for 3s on 8192 size blocks: 84392 sha256's in 2.89s Doing sha256 for 3s on 16384 size blocks: 40283 sha256's in 2.97s OpenSSL 1.1.1n 15 Mar 2022 NetBSD 9.99.97 options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) gcc version 10.3.0 (NetBSD nb1 20210411) The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes sha256 45741.63k 102821.86k 165372.82k 189407.22k 238969.67k 222146.30k At 3200 (next lower than 3400) jacaranda$ openssl speed sha256 Doing sha256 for 3s on 16 size blocks: 7979827 sha256's in 2.99s Doing sha256 for 3s on 64 size blocks: 3945995 sha256's in 2.99s Doing sha256 for 3s on 256 size blocks: 1634539 sha256's in 3.00s Doing sha256 for 3s on 1024 size blocks: 491637 sha256's in 3.00s Doing sha256 for 3s on 8192 size blocks: 65334 sha256's in 3.00s Doing sha256 for 3s on 16384 size blocks: 36043 sha256's in 3.00s OpenSSL 1.1.1n 15 Mar 2022 NetBSD 9.99.97 options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) gcc version 10.3.0 (NetBSD nb1 20210411) The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes sha256 42715.70k84434.53k 139480.66k 167812.10k 178405.38k 196908.47k At 1700 (not the next lower step, but one where the relationship should be easier to detect) jacaranda$ openssl speed sha256 Doing sha256 for 3s on 16 size blocks: 4367949 sha256's in 2.98s Doing sha256 for 3s on 64 size blocks: 2252212 sha256's in 2.90s Doing sha256 for 3s on 256 size blocks: 970476 sha256's in 2.91s Doing sha256 for 3s on 1024 size blocks: 295952 sha256's in 2.92s Doing sha256 for 3s on 8192 size blocks: 44675 sha256's in 2.98s Doing sha256 for 3s on 16384 size blocks: 18225 sha256's in 2.91s OpenSSL 1.1.1n 15 Mar 2022 NetBSD 9.99.97 options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) gcc version 10.3.0 (NetBSD nb1 20210411) The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes sha256 23452.08k49618.44k85433.93k 103892.65k 122728.91k 102470.28k At 800 (also not the next lower, 850 isn't an available frequency) jacaranda$ openssl speed sha256 Doing sha256 for 3s on 16 size blocks: 2186921 sha256's in 2.99s Doing sha256 for 3s on 64 size blocks: 1100432 sha256's in 3.00s Doing sha256 for 3s on 256 size blocks: 454525 sha256's in 2.99s Doing sha256 for 3s on 1024 size blocks: 122616 sha256's in 3.00s Doing sha256 for 3s on 8192 size blocks: 16505 sha256's in 3.00s Doing sha256 for 3s on 16384 size blocks: 11058 sha256's in 2.98s OpenSSL 1.1.1n 15 Mar 2022 NetBSD 9.99.97 options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) gcc version 10.3.0 (NetBSD nb1 20210411) The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes sha256 11686.95k23499.38k38863.86k41894.82k45129.83k 60735.59k And then for fun, at 3401 ... this one I needed to run the test several times until the kernel picked one of the fastest processors to run it on (for the others it shouldn't make any difference, any of them should be able to run at 3400 or below, though I am not sure if the economy processors actually do, at non-turbo speeds that might be limited to 2500GHz, though cpuctl claims they run at 3400 - it does get their max turbo speed right) jacaranda$ openssl speed sha256 Doing sha256 for 3s on 16 size blocks: 15927310 sha256's in 2.99s Doing sha256 for 3s on 64 size blocks: 8587518 sha256's in 3.00s Doing sha256 for 3s on 256 size blocks: 2803948 sha256's in 3.00s Doing sha256 for 3s on 1024 size blocks: 614484 sha256's
Re: cpu temperature readings
k...@munnari.oz.au (Robert Elz) writes: > | When this happens, is the machine actually running at 3400 MHz? >How do I tell? You could run a benchmark like 'openssl speed sha256' and compare the 3400 MHz target and the target and step lower. > | >The motherboard is an AsRock Z690 Taichi. > | Any deviation from factory settings ? >Several, but nothing which should affect the CPU operation, I'm not >into overclocking or anything like that (so no voltage changes, or >anything like that). I have disabled hyperthreading, and adjusted >some of the fan thresholds to make them run faster sooner. ok.
Re: cpu temperature readings
Date:Thu, 29 Jun 2023 05:39:23 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | When this happens, is the machine actually running at 3400 MHz? How do I tell? But if you mean what does machdep.cpu.frequency.current report, then yes, that is 3400 (any changes to any of the available frequencies happen immediately, or close enough to that that I can't detect the difference). But most of the time, I would expect that most of the CPUs are idle (probably in some C state or other - but that's just a guess, I know nothing about that kind of thing). | >The motherboard is an AsRock Z690 Taichi. | Any deviation from factory settings ? Several, but nothing which should affect the CPU operation, I'm not into overclocking or anything like that (so no voltage changes, or anything like that). I have disabled hyperthreading, and adjusted some of the fan thresholds to make them run faster sooner. kre
Re: cpu temperature readings
k...@munnari.oz.au (Robert Elz) writes: >When the >cpu frequency target is changed to 3400, all the core temp values drop >to lower than room air temp (which according to my probably inaccurate >desk lamp, is currently 22.5, the coretemp values are all in the 15-18 >range at the minute). When this happens, is the machine actually running at 3400 MHz? >The motherboard is an AsRock Z690 Taichi. Any deviation from factory settings ?
Re: cpu temperature readings
Date:Wed, 28 Jun 2023 23:46:24 + (UTC) From:RVP Message-ID: | You can set a lower "critical-max" property on the CPU temps. in | /etc/envsys.conf to make powerd trigger a shutdown at a lower temperature. | Say, 75C? Yex, I know, but at the minute I am not trusting the temperature readings, and shutting down because of some bogus temperature value seems like the wrong thing to be doing. The BIOS has "thermal throttling" enabled - which if I understand what that means, suggests that if things are getting too hot, the processors should simply slow down to avoid overheating. kre
Re: cpu temperature readings
Date:Wed, 28 Jun 2023 15:08:17 +0900 From:Masanobu SAITOH Message-ID: <1b1763d8-f565-612c-9336-9fb71d496...@execsw.org> | Please test the following diff: | https://www.netbsd.org/~msaitoh/coretemp-20230628-0.dif Done that, doesn't seem to make any difference. dmesg -t | grep Tjmax is now: coretemp0 at cpu0: thermal sensor, 1 C resolution, Tjmax=100 coretemp1 at cpu1: thermal sensor, 1 C resolution, Tjmax=100 coretemp2 at cpu2: thermal sensor, 1 C resolution, Tjmax=100 coretemp3 at cpu3: thermal sensor, 1 C resolution, Tjmax=100 coretemp4 at cpu4: thermal sensor, 1 C resolution, Tjmax=100 coretemp5 at cpu5: thermal sensor, 1 C resolution, Tjmax=100 coretemp6 at cpu6: thermal sensor, 1 C resolution, Tjmax=100 coretemp7 at cpu7: thermal sensor, 1 C resolution, Tjmax=100 coretemp8 at cpu8: thermal sensor, 1 C resolution, Tjmax=100 coretemp9 at cpu9: thermal sensor, 1 C resolution, Tjmax=100 coretemp10 at cpu10: thermal sensor, 1 C resolution, Tjmax=100 coretemp11 at cpu11: thermal sensor, 1 C resolution, Tjmax=100 coretemp12 at cpu12: thermal sensor, 1 C resolution, Tjmax=100 coretemp13 at cpu13: thermal sensor, 1 C resolution, Tjmax=100 coretemp14 at cpu14: thermal sensor, 1 C resolution, Tjmax=100 coretemp15 at cpu15: thermal sensor, 1 C resolution, Tjmax=100 I did a full power off, for long enough, for the BIOS (or cpu) to decide that the "economy" cores (cpu8..15) should be resurrected. That's unrelated to the patch (they were shown as missing in the BIOS before the power off state, and were back again, in the BIOS, after it). The envstat behaviour wrt changing the CPU target frequency seems to be the same, at initial boot the coretemp values were in the same range (a bit higher, but all that booting means some work was done) as the BIOS was showing (system high 30's to about 40, BIOS mid 30's - but the BIOS just shows "cpu temperature" not one for each core). When the cpu frequency target is changed to 3400, all the core temp values drop to lower than room air temp (which according to my probably inaccurate desk lamp, is currently 22.5, the coretemp values are all in the 15-18 range at the minute). I wonder if perhaps something should cause sc_tjmax_fixed to be re-calculated when the CPU frequency is changed, as it is now with the patch installed, it looks like that is intended to be able to happen, except that once sc_tjmax_fixed is set, it is never set again (and so, behaves just the same as the old sc_tjmax). I am still getting "not configured" (from both GENERIC and my kernel) for: Intel 600 Series PCH-H I2C 0 (miscellaneous serial bus, revision 0x11) at pci0 dev 21 function 0 not configured Intel 600 Series PCH-H SPI (FLASH) (miscellaneous serial bus, revision 0x11) at pci0 dev 31 function 5 not configured I (temporarily) enabled a bunch of iic related config lines in my kernel config, none of that made any difference at all (wrt what sensor devices were found) - I did boot a generic as well (from today's sources, with that patch applied) that behaved just the same as my custom kernel in all material respects (there are quite a few dmesg diffs, but none of it looks to be in any way related to anything - most is just because of drives, SATA and USB attached) configuring themselves in different orders, and of course the raidframe mod counters are different. lspci says of those two "not configured" devices: jacaranda# lspci -nn -vv -s 0:15.0 00:15.0 Serial bus controller [0c80]: Intel Corporation Alder Lake-S PCH I2C Controller #0 [8086:7acc] (rev 11) Subsystem: ASRock Incorporation Device [1849:7acc] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- (64-bit, non-prefetchable) [disabled] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Vendor Specific Information: Len=14 jacaranda# lspci -nn -vv -s 0:1f.5 00:1f.5 Serial bus controller [0c80]: Intel Corporation Alder Lake-S PCH SPI Controller [8086:7aa4] (rev 11) Subsystem: ASRock Incorporation Device [1849:7aa4] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- (32-bit, non-prefetchable) Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [a4] Vendor Specific Information: Len=14 Apart from
Re: cpu temperature readings
On Thu, 29 Jun 2023, Robert Elz wrote: The second issue (the one I started investigating) is that (with the cpu freq at 3401, enabling turbo mode, and I assume, actual frequencies up to 5500MHz) the temperatures recorded start creeping upwards (when the system is mostly idle, and nothing is really changing at all) and what's more, that seems to be on an exponential curve (positive feedback perhaps). That is, going from (reported values of) mid 30's to around 40 as the "resting" state, can take many hours, then from 40 to 50 or so, less time, and then once it gets beyond 50 and is approaching 60, it might just be minutes until it reaches Tjmax and powerd (or the cpu itself perhaps) decides to shut things down (when powerd does it, I sometimes see its broadcast message - but I often don't have a login terminal visible, so often not) and once or twice, X has actually shut down, and I've seen at least some of the normal shutdown sequence happening on the console. Usually however, the power is (or seems to be) simply abruptly cut, and everything simply stops, instantly, working and doing things (like typing an e-mail, or whatever) one second, and no power the next. (And no, it is not an external power issue, the system has a UPS, and in any case if it lost external power, it would reboot as soon as that returned, this does not do that, it behaves just like "poweroff" but seemingly without the file system unmounting, ... that would normally happen.) You can set a lower "critical-max" property on the CPU temps. in /etc/envsys.conf to make powerd trigger a shutdown at a lower temperature. Say, 75C? -RVP
Re: cpu temperature readings
I am going to reply to several messages in one reply... But first, thanks for looking at this at all, x86 processors have always been black magic to me. Date:Wed, 28 Jun 2023 05:06:11 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | coretemp temperatures in that range are unlikely to be true. Yes, of course, that was kind of the point of my message - something is obviously reporting nonsense. The question is why. | But you didn't tell what sensors you were reporting. Is that coretemp? Sorry, but yes, I should have actually included some values. Current CritMax WarnMax WarnMin CritMin Unit [coretemp0] cpu0 temperature:21.000 degC [coretemp1] cpu1 temperature:15.000 degC [coretemp2] cpu2 temperature:16.000 degC [coretemp3] cpu3 temperature:13.000 degC [coretemp4] cpu4 temperature:14.000 degC [coretemp5] cpu5 temperature:15.000 degC [coretemp6] cpu6 temperature:12.000 degC [coretemp7] cpu7 temperature:13.000 degC That's the entire envstat output on my system (as configured currently). Those readings are from when I was generating this mail, room temp is about 22C, cpu target frequency is 3400 (not 3401). If I set it to 3401, and wait a minute or so, what appears is: Current CritMax WarnMax WarnMin CritMin Unit [coretemp0] cpu0 temperature:42.000 degC [coretemp1] cpu1 temperature:40.000 degC [coretemp2] cpu2 temperature:36.000 degC [coretemp3] cpu3 temperature:35.000 degC [coretemp4] cpu4 temperature:45.000 degC [coretemp5] cpu5 temperature:34.000 degC [coretemp6] cpu6 temperature:36.000 degC [coretemp7] cpu7 temperature:33.000 degC Apart from the change of target (and actual) frequency (incidentally, does machdep.cpu.frequency.target set all the CPUs? I assume it does, but is there any mechanism to alter them individually?) nothing else of significance has changed (the room might be a tenth of a degree cooler - the A/C has not been turned on for very long). If (when) I return from 3401 to 3400 the temps will go back to (give or take a few degrees) the earlier readings, and if I leave things so the monitors switch to dpms off mode (or whatever happens to them when they turn off) and the CPUs have nothing to do, and the room cools a little more, the temps recorded would drop even lower. It is this strange behaviour that is interesting. Certainly I expect that if the CPUs are running faster, they will be hotter (and when they are really working they certainly are) but when all they're doing is mostly sitting in the idle loop, I'd have expected the target max freq to be more or less irrelevant to the temperature (and certainly not for anything to ever produce values less than is rationally possible). | Some ACPI value? A motherboard sensor (e.g. lm0)? No ACPI sensors I am aware of, motherboard sensors exist, but either aren't supported, or my kernel is not configured to support, any of those. I certainly have no lm? devices configured, and as best I can tell from a quick look, nor does the standard GENERIC kernel. When I next reboot (which is likely to be seen, as indicated below) I will try booting GENERIC and see if anything extra shows up ... but my kernel config was mostly created that way, initially running GENERIC, then making a config file with all the devices (and options) I am never going to have or ever want, removed. Any hardware which GENERIC matched a driver to would have been retained. But that GENERIC was 9.99.97 from more than a year ago now. | That's a selected 241W chip that may heat up to > 100 C (Tjmax = 115 C) | and usually requires a liquid cooler. Idle temperature between 50C and 60C | are normal. It has a liquid cooler. What's more it seems to work quite effectively. When I am going a build the coretemps go way up when things are busy (that's expected of course) and then drop (more quickly than I would have guessed would happen) during the occasional idle periods (like when waiting for the last parts of the main build to finish, before starting on the kernels). When the build is truly completed, everything reverts to the state before the build started, reasonably quickly. So, in general, I believe the cooling system is working OK. Date:Wed, 28 Jun
Re: cpu temperature readings
Hi. On 2023/06/28 14:24, Michael van Elst wrote: > k...@munnari.oz.au (Robert Elz) writes: > >> cpu0: "12th Gen Intel(R) Core(TM) i9-12900KS" > > The chip apparently reports a Tjmax of 100 C (as for the non-selected chip) > but actually has a real Tjmax of 115 C. https://ark.intel.com/content/www/us/en/ark/products/225916/intel-core-i912900ks-processor-30m-cache-up-to-5-50-ghz.html ark.intel.com often shows incorrect values. Looking at this page now, it says Tjmax is 90 degrees. Robert, could you show me the output of: dmesg -t | grep Tjmax It seems that the MSR_TEMPERATURE_TARGET's value is not fixed on newer chips. Please test the following diff: https://www.netbsd.org/~msaitoh/coretemp-20230628-0.dif Thanks in advance. > There are two caveats: > > Our driver ignores Tjmax of > 110 C (and uses 100 C as default). If the > chip would report the real value, we would ignore it. > > Intel recommends that the BIOS fakes the value and configures the MSR ten > degrees lower (so you see Tjmax of 90 C). > > > The temperature sensor reading is relative to Tjmax. > > /* > * The temperature is computed by > * subtracting the reading by Tj(max). > */ > edata->value_cur = sc->sc_tjmax; > edata->value_cur -= __SHIFTOUT(msr, MSR_THERM_STATUS_READOUT); > > > So it could be 15C lower than reality (if the default of 100 instead > of 115 is used) or even 25C lower if (if the Intel recommenendation > is followed). > -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: cpu temperature readings
k...@munnari.oz.au (Robert Elz) writes: >cpu0: "12th Gen Intel(R) Core(TM) i9-12900KS" The chip apparently reports a Tjmax of 100 C (as for the non-selected chip) but actually has a real Tjmax of 115 C. There are two caveats: Our driver ignores Tjmax of > 110 C (and uses 100 C as default). If the chip would report the real value, we would ignore it. Intel recommends that the BIOS fakes the value and configures the MSR ten degrees lower (so you see Tjmax of 90 C). The temperature sensor reading is relative to Tjmax. /* * The temperature is computed by * subtracting the reading by Tj(max). */ edata->value_cur = sc->sc_tjmax; edata->value_cur -= __SHIFTOUT(msr, MSR_THERM_STATUS_READOUT); So it could be 15C lower than reality (if the default of 100 instead of 115 is used) or even 25C lower if (if the Intel recommenendation is followed).
Re: cpu temperature readings
k...@munnari.oz.au (Robert Elz) writes: >sysctl -w machdep.cpu.frequency.target=3D2500 >(reducing from the apparent max, 3401) the temps dropped (almost >instantly) from upper 30's (C) to low 40's, down to the high teens >or very low 20's. coretemp temperatures in that range are unlikely to be true. But you didn't tell what sensors you were reporting. Is that coretemp? Some ACPI value? A motherboard sensor (e.g. lm0)? >cpu0: "12th Gen Intel(R) Core(TM) i9-12900KS" That's a selected 241W chip that may heat up to > 100 C (Tjmax = 115 C) and usually requires a liquid cooler. Idle temperature between 50C and 60C are normal.
cpu temperature readings
Hi all. I'm currently running HEAD from about June 14. My system has been having what appear to be temperature related issues (those are not the point of this e-mail). As part of attempting to deal with (or diagnose) what is happening there, I switched the CPU frequency to go slower (slower CPU, less heat). I was expecting a minor temperature reduction. Instead, when I did (initially sysctl -w machdep.cpu.frequency.target=2500 (reducing from the apparent max, 3401) the temps dropped (almost instantly) from upper 30's (C) to low 40's, down to the high teens or very low 20's. That's in a room with room temperature in the low 20's at the time. I switched the target (and actual reported running frequency) to 3400 (just leaving off the "turbo boost" "1") which made no difference. Today (still using 3400 as the frequency) I have seen reported CPU temperatures as low as 8 degrees C (in a room with ambient temps that never would have dropped below 20 - with the A/C running fairly hard). Since I don't believe my motherboard, processor, or cooler, have refrigeration capabilities, that's somewhat remarkable. I have just turned "turbo boost" back on (freq 3401) and the temp readings now are more normal, upper 20's (nicely above the ambient air temp, as one would normally expect) to mid 30's, with occasional excursions into the low 50's when a core gets temporarily busy. Has anyone else seen anything like this? Details of the CPU are appended - at least the basic model info from "cpuctl idenify 0", if knowing the (huge) set of feature bit settings would be useful (or some particular ones) I can supply those later. And while I am here, I currently see only the CPU core temps in envstat, but the BIOS can see much more. I suspect one of these "not configured" is the culprit. [ 1.025183] Intel 600 Series PCH-H I2C 0 (miscellaneous serial bus, revision 0x11) at pci0 dev 21 function 0 not configured [ 1.025183] Intel 600 Series PCH-H SPI (FLASH) (miscellaneous serial bus, revision 0x11) at pci0 dev 31 function 5 not configured Those might be being "not configured" either because NetBSD currently doesn't support them, or perhaps more likely, something is missing from my custom kernel config. If it is the latter, and anyone knows what I should be including, I'd appreciate a hint! There's a bunch of other stuff not configured (including the WiFi, which I know we do not currently support) but I doubt that any of that is related to missing sensor devices (the BIOS can see fan speeds, motherboard temp, (and voltages, but those might be done differently). Thanks, kre jacaranda# cpuctl identify 0 cpu0: highest basic info 0020 cpu0: highest extended info 8008 cpu0: "12th Gen Intel(R) Core(TM) i9-12900KS" cpu0: Intel 12th gen Core (Alder Lake) (686-class), 3417.60 MHz cpu0: CPU base freq 34 Hz cpu0: CPU max freq 55 Hz cpu0: TSC freq CPUID 341760 Hz cpu0: family 0x6 model 0x97 stepping 0x2 (id 0x90672) [] cpu0: SEF highest subleaf 0001 cpu0: SEF-subleaf1-eax 0x401c10 cpu0: Power Management features: 0x100 cpu0: Perfmon-eax 0x8300805 cpu0: Perfmon-eax 0x8300805 cpu0: Perfmon-edx 0x8604 cpu0: Hybrid: Core type 40, Native Model ID 001 cpu0: microcode version 0x16, platform ID 1 (That's running its supplied microdode - I disabled the microcode updates, as the issue I'm seeing appeared soon after the most recent microcode update was installed. But clearly that was irrelevant, as not doing the update has made no difference, so I will be enabling that again soon). I am also currently running with hyperthreading disabled (which seems to have been a change that is keeping my system running OK) - the 8 "economy" cores have also been disabled (but not by me) - the processor, or BIOS, does that sometimes (and always has) - they will return after a full power off (as in, removing power from the power supply - nothing less works). Having those disabled has not made any difference to the original problem (though enabling them might have made it worse - but that was from a single experiment under non-controlled circumstances, so really means nothing.)
