Re: measuring swap partition speed

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