Re: measuring swap partition speed

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
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