Date: Sat, 23 Dec 2023 14:01:54 -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: <81D464BA-FABE-4F25-B2BE-3DB9D85E3E64@yahoo.com> In-Reply-To: <B4833CC9-96FB-444E-B1BC-2662A2909E7A@yahoo.com> References: <B4833CC9-96FB-444E-B1BC-2662A2909E7A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 23, 2023, at 11:55, Mark Millard <marklmi@yahoo.com> wrote: > 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. FYI: the 2023-Dec-16 stable/14 snapshot that I'm using has: # 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) So fairly modern RPi* firmware compared to what FreeBSD used to use. What vintage are you using? IT may have different defaults than what my FreeBSD snaphot context reports. Another issue may be: bcm2835_cpufreq0: current ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo = OFF bcm2835_cpufreq0: max/min ARM 2147/600MHz, Core 750/250MHz, SDRAM = 400/400MHz What does: # sysctl dev.bcm2835_cpufreq.0.freq_settings dev.cpu.0.freq_levels = dev.cpu.0.freq report for your context? The default for the FreeBSD supplied config.txt in the snapshot I'm using is: # 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 Adding arm_boost=3D1 to config.txt in order to have 1800 instead of = 1500: # 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 Then there is how I normally use all the RPi4B's that I (sometimes) have access to: # 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 [pi4] hdmi_safe=3D1 armstub=3Darmstub8-gic.bin # over_voltage=3D6 sdram_freq_min=3D3200 arm_freq_min=3D2000 force_turbo=3D1 # 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 An unfortunate issue is the signed output of: # sysctl -x hw.cpufreq.sdram_freq hw.cpufreq.sdram_freq: 0xbebc2000 root@generic:~ # sysctl hw.cpufreq.sdram_freq hw.cpufreq.sdram_freq: -1094967296 0xbebc2000 =3D=3D 3200000000 (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.) Also, FreeBSD does not have a hw.cpufreq.sdram_freq_min but the RPi4B does have sdram_freq_min . Based on config.txt as FreeBSD supplies it: # sysctl hw.cpufreq.sdram_freq hw.cpufreq.sdram_freq: 400000000 (That last is 400 [MHz] in config.txt notation.) 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. If you are using the combination: dev.cpu.0.freq: 600 hw.cpufreq.sdram_freq: 400000000 that may be causing extra time to be taken compared to alternatives. Of course you may be using powerd or some such. I use fixed frequency configurations normally. =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?81D464BA-FABE-4F25-B2BE-3DB9D85E3E64>