Re: measuring swap partition speed

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.

===
Mark Millard
marklmi at yahoo.com