Date: Sat, 23 Dec 2023 15:30:13 -0800 From: Mark Millard <marklmi@yahoo.com> To: void <void@f-m.fm>, freebsd-fs@freebsd.org Subject: Re: measuring swap partition speed Message-ID: <B922C347-DED1-4308-B6E8-96FF4C241793@yahoo.com> In-Reply-To: <68CE5AE9-4800-49B6-BC00-14F5D3AB464A@yahoo.com> References: <B4833CC9-96FB-444E-B1BC-2662A2909E7A@yahoo.com> <81D464BA-FABE-4F25-B2BE-3DB9D85E3E64@yahoo.com> <68CE5AE9-4800-49B6-BC00-14F5D3AB464A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 23, 2023, at 15:24, Mark Millard <marklmi@yahoo.com> wrote: > On Dec 23, 2023, at 14:01, Mark Millard <marklmi@yahoo.com> wrote: >=20 >> On Dec 23, 2023, at 11:55, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >>> void <void_at_f-m.fm> wrote on >>> Date: Sat, 23 Dec 2023 15:52:55 UTC : >>>=20 >>>> On Fri, 22 Dec 2023, at 09:37, Ronald Klop wrote: >>>>> Can you provide more concrete information? Like: >>>>>=20 >>>>> # usbconfig list >>>>=20 >>>> # usbconfig list >>>> ugen0.1: <(0x1106) XHCI root HUB> at usbus0, cfg=3D0 md=3DHOST = spd=3DSUPER (5.0Gbps) pwr=3DSAVE (0mA) >>>> ugen0.2: <vendor 0x2109 USB2.0 Hub> at usbus0, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DSAVE (100mA) >>>> ugen0.3: <American Power Conversion Back-UPS XS 1400U FW:926.T2 .I = USB FW:T2> at usbus0, cfg=3D0 md=3DHOST spd=3DLOW (1.5Mbps) pwr=3DON = (24mA) >>>> ugen0.4: <Ralink 802.11 n WLAN> at usbus0, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DON (450mA) >>>> ugen0.5: <Toshiba MQ01ABD > at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER = (5.0Gbps) pwr=3DON (36mA) >>>>=20 >>>> The power supply is the approved 5.1V 3A one. >>>=20 >>> I use CanaKit power supplies that have more margin for the power: >>>=20 >>> 5.1V 3.5A >>>=20 >>>>> And the output of "devinfo -v". That will give people much more=20 >>>>> information to work with instead of "anecdotal evidence" about = your=20 >>>>> hardware being usb3. >>>>=20 >>>> devinfo -v : https://bsd.to/ADPj >>>>=20 >>>> detailed dmesg is here: https://bsd.to/Q5tx >>>=20 >>> That last indicates another potentially significant difference >>> from my example benchmarks done for comparison to yours: >>>=20 >>> GEOM_ELI: Device da0p3.eli created. >>> GEOM_ELI: Encryption: AES-XTS 256 >>> GEOM_ELI: Crypto: software >>>=20 >>> That likely contributes to slowing down I/O for da0p3 and >>> possibly to leaving less time for I/O to other partitions >>> when da0p3 is in use. >>>=20 >>> If you had the resources to test avoiding the encrypted >>> partition for your type of media, that might prove >>> interesting. >>>=20 >>> I've never had occasion to want to use any encrypted >>> partitions for my FreeBSD activity. >>>=20 >>> I'm unsure of the GEOM_ELI processing-time contributions >>> vs. "gstat -spod" reporting. >>=20 >> FYI: the 2023-Dec-16 stable/14 snapshot that I'm using >> has: >>=20 >> # strings /boot/efi/start4.elf | grep VC_BUILD_ID_ >> VC_BUILD_ID_USER: dom >> VC_BUILD_ID_TIME: 10:50:39 >> VC_BUILD_ID_VARIANT: start >> VC_BUILD_ID_TIME: Mar 17 2023 >> VC_BUILD_ID_BRANCH: bcm2711_2 >> VC_BUILD_ID_HOSTNAME: buildbot >> VC_BUILD_ID_PLATFORM: raspberrypi_linux >> VC_BUILD_ID_VERSION: 82f3750a65fadae9a38077e3c2e217ad158c8d54 (clean) >>=20 >> So fairly modern RPi* firmware compared to what FreeBSD used >> to use. >>=20 >> What vintage are you using? IT may have different defaults than >> what my FreeBSD snaphot context reports. >>=20 >>=20 >> Another issue may be: >>=20 >> bcm2835_cpufreq0: current ARM 600MHz, Core 250MHz, SDRAM 400MHz, = Turbo OFF >> bcm2835_cpufreq0: max/min ARM 2147/600MHz, Core 750/250MHz, SDRAM = 400/400MHz >>=20 >> What does: >>=20 >> # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq >>=20 >> report for your context? The default for the FreeBSD supplied >> config.txt in the snapshot I'm using is: >>=20 >> # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq >> dev.bcm2835_cpufreq.0.freq_settings: 1500/-1 600/-1 >> dev.cpu.0.freq_levels: 1500/-1 600/-1 >> dev.cpu.0.freq: 600 >>=20 >> Adding arm_boost=3D1 to config.txt in order to have 1800 instead of = 1500: >>=20 >> # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq >> dev.bcm2835_cpufreq.0.freq_settings: 1800/-1 600/-1 >> dev.cpu.0.freq_levels: 1800/-1 600/-1 >> dev.cpu.0.freq: 600 >>=20 >> Then there is how I normally use all the RPi4B's that I >> (sometimes) have access to: >>=20 >> # more /boot/efi/config.txt=20 >> [all] >> arm_64bit=3D1 >> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don >> dtoverlay=3Dmmc >> dtoverlay=3Ddisable-bt >> device_tree_address=3D0x4000 >> kernel=3Du-boot.bin >>=20 >> [pi4] >> hdmi_safe=3D1 >> armstub=3Darmstub8-gic.bin >> # >> over_voltage=3D6 >> sdram_freq_min=3D3200 >> arm_freq_min=3D2000 >> force_turbo=3D1 >>=20 >> # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq >> dev.bcm2835_cpufreq.0.freq_settings: 2000/-1 >> dev.cpu.0.freq_levels: 2000/-1 >> dev.cpu.0.freq: 2000 >>=20 >>=20 >> An unfortunate issue is the signed output of: >>=20 >> # sysctl -x hw.cpufreq.sdram_freq >> hw.cpufreq.sdram_freq: 0xbebc2000 >> root@generic:~ # sysctl hw.cpufreq.sdram_freq >> hw.cpufreq.sdram_freq: -1094967296 >>=20 >> 0xbebc2000 =3D=3D 3200000000 >>=20 >> (3200 [MHz] in terms of config.txt content. More modern >> RPi* firmware always uses that figure by default for >> sdram_freq_min as well: so fixed RAM frequency across >> alternate arm frequencies.) >>=20 >> Also, FreeBSD does not have a hw.cpufreq.sdram_freq_min >> but the RPi4B does have sdram_freq_min . >>=20 >> Based on config.txt as FreeBSD supplies it: >>=20 >> # sysctl hw.cpufreq.sdram_freq >> hw.cpufreq.sdram_freq: 400000000 >>=20 >> (That last is 400 [MHz] in config.txt notation.) >>=20 >> This is based on the RPi* firmware default for >> sdram_freq_min for the vintage of RPi* firmware >> FreeBSD currently uses for its snapshot builds. >>=20 >> If you are using the combination: >>=20 >> dev.cpu.0.freq: 600 >> hw.cpufreq.sdram_freq: 400000000 >>=20 >> that may be causing extra time to be taken compared to >> alternatives. >>=20 >> Of course you may be using powerd or some such. I use >> fixed frequency configurations normally. >>=20 >=20 > Well, my assumption about the likes of the hw.cpufreq.sdram_freq being Sorry: (RPi* config.txt notation) sdram_freq_min (since 400 is observed = to occur) > due to RPi* firmware looks to be wrong. The RPi* documentation changed > from 400 MHz to 3200 MHz for RPi4B sdram_freq_min at: >=20 > Before (400), Jun 8, 2021: > = https://github.com/raspberrypi/documentation/blob/974995fabb184a2435a98e68= c1e728b346112f89/configuration/config-txt/overclocking.md >=20 > After (3200), Jun 9, 2021: > = https://github.com/raspberrypi/documentation/blob/920ff905995541f7ef1c6048= 2924a392143e9192/configuration/config-txt/overclocking.md >=20 > The RPi* firmware should be setting things up to have 3200 MHz. Since > that is not what FreeBSD ends up with in modern snapshots with the > FreeBSD supplied config.txt , Likely FreeBSD has taken control of > such. >=20 > This might just be one example parameter that is overridden. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B922C347-DED1-4308-B6E8-96FF4C241793>