Re: measuring swap partition speed
- In reply to: Mark Millard : "Re: measuring swap partition speed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 23 Dec 2023 23:30:13 UTC
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: > >> 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 : >>> >>>> On Fri, 22 Dec 2023, at 09:37, Ronald Klop wrote: >>>>> Can you provide more concrete information? Like: >>>>> >>>>> # usbconfig list >>>> >>>> # usbconfig list >>>> ugen0.1: <(0x1106) XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) >>>> ugen0.2: <vendor 0x2109 USB2.0 Hub> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA) >>>> ugen0.3: <American Power Conversion Back-UPS XS 1400U FW:926.T2 .I USB FW:T2> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (24mA) >>>> ugen0.4: <Ralink 802.11 n WLAN> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (450mA) >>>> ugen0.5: <Toshiba MQ01ABD > at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (36mA) >>>> >>>> The power supply is the approved 5.1V 3A one. >>> >>> I use CanaKit power supplies that have more margin for the power: >>> >>> 5.1V 3.5A >>> >>>>> And the output of "devinfo -v". That will give people much more >>>>> information to work with instead of "anecdotal evidence" about your >>>>> hardware being usb3. >>>> >>>> devinfo -v : https://bsd.to/ADPj >>>> >>>> detailed dmesg is here: https://bsd.to/Q5tx >>> >>> That last indicates another potentially significant difference >>> from my example benchmarks done for comparison to yours: >>> >>> GEOM_ELI: Device da0p3.eli created. >>> GEOM_ELI: Encryption: AES-XTS 256 >>> GEOM_ELI: Crypto: software >>> >>> 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. >>> >>> If you had the resources to test avoiding the encrypted >>> partition for your type of media, that might prove >>> interesting. >>> >>> I've never had occasion to want to use any encrypted >>> partitions for my FreeBSD activity. >>> >>> 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=1 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 >> [all] >> arm_64bit=1 >> dtparam=audio=on,i2c_arm=on,spi=on >> dtoverlay=mmc >> dtoverlay=disable-bt >> device_tree_address=0x4000 >> kernel=u-boot.bin >> >> [pi4] >> hdmi_safe=1 >> armstub=armstub8-gic.bin >> # >> over_voltage=6 >> sdram_freq_min=3200 >> arm_freq_min=2000 >> force_turbo=1 >> >> # 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 == 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. >> > > 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: > > Before (400), Jun 8, 2021: > https://github.com/raspberrypi/documentation/blob/974995fabb184a2435a98e68c1e728b346112f89/configuration/config-txt/overclocking.md > > After (3200), Jun 9, 2021: > https://github.com/raspberrypi/documentation/blob/920ff905995541f7ef1c60482924a392143e9192/configuration/config-txt/overclocking.md > > 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. > > This might just be one example parameter that is overridden. === Mark Millard marklmi at yahoo.com