Re: ssh client_loop send disconnnect from Dom0 -> DomU (NetBSD 10.0_BETA/Xen)
Hi, On 30.06.23 07:07, Brian Buhrow wrote: hello. Yes, this behavior is expected. It ensures that there is no conflict between the device on the domu end of the vif port and the device on the dom0 end. This is more sane behavior than FreeBSD, which zeros out the MAC address on the dom0 side of the vif. -thanks -Brian thanks for the clarification. Good to know this is not a bug or so. Overall the topic seems now a lot more clearer and with the static ARP entries in place I can finally return to having daily backups of my VMs :-) Concerning the root cause I assume this requires further investigation. To make this independend of the system where it originally occured, I plan to create a minimal setup to reproduce it on a similiar sized system and will support as much I can. Kind regards Matthias smime.p7s Description: S/MIME Cryptographic Signature
Re: ssh client_loop send disconnnect from Dom0 -> DomU (NetBSD 10.0_BETA/Xen)
hello. Yes, this behavior is expected. It ensures that there is no conflict between the device on the domu end of the vif port and the device on the dom0 end. This is more sane behavior than FreeBSD, which zeros out the MAC address on the dom0 side of the vif. -thanks -Brian
Re: ssh client_loop send disconnnect from Dom0 -> DomU (NetBSD 10.0_BETA/Xen)
Hello, On 29.06.23 11:58, Matthias Petermann wrote: While I do not want to praise the evening before the dayyou deserve some feedback. Both the synthetic test with ssh/dd and my real payload with ssh/dump have been running for easily 6 hours without interruption this morning. I took the advice and first made static entries in the ARP table for each other for the two partners directly involved (Dom0 and the DomU concerned). I will continue to monitor this but it looks much better now than the days before. In case this proves as a reproduceable solution, my next question would be how this could be persisted (apart from hard-coding the arp -d -a / -s calls into rc.local etc.). The former proposal you sent me (net.inet.icmp.bmcastecho=1 and ping -nc10) did not create ARP-adresses with no expiration time on my NetBSD 10.0_BETA system. You mentioned this might be a feature of -HEAD - not sure about 10... I also wanted to mention - and I don't know how this contributes - that mDNSd is enabled on all involved hosts. I had originally planned this so that the hosts can also find each other via the .local suffix if the local domain .lan cannot be resolved - for example if the DNS server is down. Kind regards Matthias With the assignment of permanent ARP entries, everything worked stably for the whole day yesterday. It seems to be due to the ARP entries. I've done some work on how to make this persistent at least as a workaround and found /etc/ethers in combination with /usr/sbin/arp -f /etc/ethers to be suitable. Anyway, while applying this change and do further testing, something weird came to my attention. Is this expected?: Please see the MAC adress configured in the DomU config file (on Dom0): ``` ame="srv-net" type="pv" kernel="/netbsd-XEN3_DOMU.gz" memory=512 vcpus=2 vif = ['mac=00:16:3E:00:00:01,bridge=bridge0,ip=192.168.2.51' ] disk = [ 'file:/data/vhd/srv-net_root.img,0x01,rw','file:/data/vhd/srv-net_data1.img,0x02,rw','file:/data/vhd/srv-net_data2.img,0x03,rw','file:/data/vhd/srv-net_data3.img,0x04,rw', ] ``` In the DomU this configured MAC adress matches the MAC of the virtual network interface: ``` srv-net$ ifconfig xennet0 xennet0: flags=0x8843 mtu 1500 capabilities=0x3fc00 capabilities=0x3fc00 enabled=0 ec_capabilities=0x5 ec_enabled=0 address: 00:16:3e:00:00:01 inet6 fe80::216:3eff:fe00:1%xennet0/64 flags 0 scopeid 0x1 inet 192.168.2.51/24 broadcast 192.168.2.255 flags 0 ``` In opposite to this, on the Dom0 the related xen backend network interface has a slightly different MAC: ``` xvif1i0: flags=0x8943 mtu 1500 capabilities=0x3fc00 capabilities=0x3fc00 enabled=0 ec_capabilities=0x5 ec_enabled=0x1 address: 00:16:3e:01:00:01 inet6 fe80::216:3eff:fe01:1%xvif1i0/64 flags 0 scopeid 0x4 ``` It differs in the 4th octet and I am wondering, if this is intended? Kind regards Matthias smime.p7s Description: S/MIME Cryptographic Signature
daily CVS update output
Updating src tree: P src/distrib/sets/lists/man/mi P src/doc/3RDPARTY P src/doc/CHANGES P src/external/apache2/mDNSResponder/prepare-import.sh P src/external/apache2/mDNSResponder/dist/mDNSPosix/PosixDaemon.c P src/lib/libc/gen/vis.c P src/share/man/man4/Makefile P src/share/man/man4/npflog.4 P src/sys/arch/i386/stand/bootxx/boot1.c P src/sys/arch/shark/shark/scr.c P src/usr.bin/aiomixer/aiomixer.1 P src/usr.bin/aiomixer/app.h P src/usr.bin/aiomixer/draw.c P src/usr.bin/aiomixer/main.c P src/usr.bin/xlint/common/externs.h P src/usr.bin/xlint/common/inittyp.c P src/usr.bin/xlint/common/lint.h P src/usr.bin/xlint/common/tyname.c P src/usr.bin/xlint/lint1/cgram.y P src/usr.bin/xlint/lint1/debug.c P src/usr.bin/xlint/lint1/decl.c P src/usr.bin/xlint/lint1/emit1.c P src/usr.bin/xlint/lint1/externs1.h P src/usr.bin/xlint/lint1/func.c P src/usr.bin/xlint/lint1/lex.c P src/usr.bin/xlint/lint1/lint1.h P src/usr.bin/xlint/lint1/tree.c P src/usr.bin/xlint/lint2/emit2.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 49619259 Jun 30 03:03 ls-lRA.gz
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: ssh client_loop send disconnnect from Dom0 -> DomU (NetBSD 10.0_BETA/Xen)
Hi Brian, On 26.06.23 16:17, Brian Buhrow wrote: hello. A couple of quick questions based on the convrsation and the snippets of logs shown in the e-mails. 1. Is the MAC address shown in the ARP replies the correct one for the dom0? No reason it should be wrong, but it's worth verifying, just in case there is an unknown host replying on the network. The addresses match - I just verified this. Anyway, thanks for the pointer. 2. Can you capture the same tcpdumps using the -e flag? The -e flag will print the source and destination MAC addresses, as wel as the source and destination IP addresses or host names, depending on whether you use the -n flag. This might provide additional insight into what's happening on the network. Since I added static ARP records, the problem did not occur another time. I did stop tcpdump for now to save space, but I will consider the -e flag next time. Kind regards Matthias smime.p7s Description: S/MIME Cryptographic Signature
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: ssh client_loop send disconnnect from Dom0 -> DomU (NetBSD 10.0_BETA/Xen)
Hi, On 26.06.23 15:37, RVP wrote: On Mon, 26 Jun 2023, Matthias Petermann wrote: Could it still be an ARP related issue? I did a simplified version of the test this morning: Try this test: since you have static IP- & MAC-addresses everywhere in your setup, just add them as static ARP entries (skip own address): On each of your DomUs and the Dom0: arp -d -a # delete ARP-cache arp -s IP-addr1 MAC-addr1 arp -s IP-addr2 MAC-addr2 etc. On the Dom0, add the addrs. of the DomUs. On each of the DomUs, the addrs. of Dom0 and _other_ DomUs. Do your tests. -RVP While I do not want to praise the evening before the dayyou deserve some feedback. Both the synthetic test with ssh/dd and my real payload with ssh/dump have been running for easily 6 hours without interruption this morning. I took the advice and first made static entries in the ARP table for each other for the two partners directly involved (Dom0 and the DomU concerned). I will continue to monitor this but it looks much better now than the days before. In case this proves as a reproduceable solution, my next question would be how this could be persisted (apart from hard-coding the arp -d -a / -s calls into rc.local etc.). The former proposal you sent me (net.inet.icmp.bmcastecho=1 and ping -nc10) did not create ARP-adresses with no expiration time on my NetBSD 10.0_BETA system. You mentioned this might be a feature of -HEAD - not sure about 10... I also wanted to mention - and I don't know how this contributes - that mDNSd is enabled on all involved hosts. I had originally planned this so that the hosts can also find each other via the .local suffix if the local domain .lan cannot be resolved - for example if the DNS server is down. Kind regards Matthias smime.p7s Description: S/MIME Cryptographic 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
