楽天モバイルのIPv6ではNAT64/DNS64が利用できることが知られている1。 筆者の自宅では固定回線が引けないため楽天モバイルを使用しているが、IPv4でいくつかのサイトが開けないことがあった。 NAT64ではそのようなサイトも開けたため、しばらくはIPv6シングルスタックのネットワークを切って利用していたが、色々面倒になったのでメインのネットワークのIPv4デフォルトルートを464XLATにした。 OpenWRTの設定 上流のIPv6ネットワークがNAT64に対応していれば、OpenWRTでは464xlatパッケージをインストールし設定を行えば使える。 まずは464xlatをインストールする。LuCIでもsshのopkgでもよい。 LuCIで464XLATのinterfaceを作成する。上流のIPv6 interfaceがwan6なので、今回はinterfaceの名前はwan6_4とした。 firewallでwan zoneにinterfaceを追加する。interface作成時にはwebから設定できるが、作成後はLuCIからは変更できないので、 その際は/etc/config/firewallのwan zoneにlist network ‘wan6_4’を追加し、firewallを再起動する。 これで464xlatでIPv4パケットが通るようになる。他にIPv4の上流がある場合はmetricを調整する。 IPv6 prefix変更時に464XLATが通信できなくなる問題の対処法 楽天モバイルでは再接続時にIPv6 prefixが変更されることがある(当然IPv6アドレスも変わる)。 OpenWRTの464xlatパッケージはこのような場合を自動では取り扱ってくれないので、今回は自動化のためhotplugにスクリプトを用意した。 IPv6の上流ネットワークが変更された場合、新しいIPv6アドレスが振られた状態でwan6_4をdownさせれば、数秒後に再起動して通信が可能になる。 そこで、次のようなスクリプトを用意した。 Filename: /etc/hotplug.d/iface/50-464xlat #!/bin/sh [ "$ACTION" = ifupdate ] && { [ "$INTERFACE" = "wan6" ] && { [ "$IFUPDATE_ADDRESSES" = 1 ] && { [ "$IFUPDATE_ROUTES" = 1 ] && { ubus call network.interface.wan6_4 down } } } } https://www.zukeran.org/shin/d/2021/10/22/rakuten-network-1/ ↩︎
zramの性能測定(ddによる簡易測定)
概要 RAMディスク代わりにzramを使うことに興味を持ったが、 インターネット上の日本語で書かれたzramの記事では、zramの性能を測定するのにファイルシステムを作成していて キャッシュが効いていそうなものばかりだったため、ddで直接測定した。 実験にはlinux-6.12のソースコードのtarファイルを用いた。実験した圧縮アルゴリズムで最速だったlz4で読込1.2GB/s、書込490MB/s、圧縮比3.06であった。 実験に使ったi3 8100Tは古いCPUとはいえ、tmpfsが読取10GB/s、書込2.4GB/sであることを考えるとzramはI/Oが遅い。 I/O性能が必要な場合、tmpfsをzramで置き換えることは慎重に検討するべきである。 導入 zramはlinuxのメモリ上に作成できる圧縮ブロックデバイスで、swapやRAMディスクとして使用できる。 zramに書き込まれたデータは圧縮されるので、そのI/O性能はCPUと圧縮アルゴリズムとデータの特徴に依る。 Linux 6.12で使用できるアルゴリズムはlzo-rle,lzo,lz4,lz4hc,zstd,deflate,842であり、 どれもLZ系の圧縮アルゴリズムである。 LZ系のアルゴリズムでは、繰り返し同じパターンが現れるデータのとき高い圧縮率になる。 例えば、ソースコードやログファイルなどで高い圧縮率を期待できる。 zramでは、同じデータ(unsigned long)で埋められたページはsame pageとして処理され、圧縮処理を行わない。 same pageの展開は圧縮されたページの展開よりも速いので、ゼロフィルされたファイルを用いればzramの処理速度の上界が把握できるはずである。 そこで、zramの最大I/O速度を測定するために適当な大きさのゼロフィルされたファイルを用い測定し、 アルゴリズムを含めた実力を測るためにソースコードを纏めた非圧縮のtarファイルを用い測定することとした。 zramはブロックデバイスなため、ファイルを書き込むときは通常はext4などのファイルシステムを用いるが、ファイルシステムを通したI/Oはページキャッシュが効くため速度測定では注意を払う必要がある。 今回は、簡単に測定をするため、デバイスファイルに直接ddでファイルの書き込み・読み取りを行う。 実験環境 機種はLenovo M720q(i3-8100T/DDR4-2400 32GB)を用いた。 カーネルはLinux version 6.12.38-gentoo-distを用いた。 実験時はCPU governerをperformanceに設定して測定した。 実験用データはlinux-6.12.tar.xzを伸長したlinux-6.12.tarを使用した。 ddのオプションはbs=1Mで測定した。 読み取り速度測定時はof=/dev/nullに出力した。 実験用ファイルはtmpfs上に配置した。 実験内容と結果 実験1 tmpfsの速度測定 RAMディスクとしてのtmpfs(正確にはファイルシステムだが)の性能を測るため、tmpfs上でのI/O速度を測定した。 tmpfs上に配置したlinux-6.12.tarを、ddでコピーすることで書き込み速度を、ddで/dev/nullに出力することで読み取り速度を測定した。 結果は読取9.8GB/s、書込2.2GB/sであった。 実験2 0埋めファイルの測定 ddで/dev/zeroからtmpfs上に1GiBのファイルを作成し、測定に用いた。 結果は読取2.7GB/s, 書込4.3GB/sであった。 実験3 ソースコードtarファイルの測定 linux-6.12.tarをtmpfs上に配置して測定に用いた。 圧縮アルゴリズムのlevelはデフォルト値を用いた(lz4は1, lz4hcは9, zstdは3, deflateは6)。 圧縮アルゴリズム 読取 書込 圧縮比 lzo-rle 900 MB/s 460 MB/s 3.17 lzo 890 MB/s 459 MB/s 3.17 lz4 1.2 GB/s 490 MB/s 3.06 lz4hc 1.3 GB/s 63.5 MB/s 3.45 zstd 433 MB/s 160 MB/s 4.42 deflate 231 MB/s 33.4 MB/s 4.63 842 100 MB/s 52.0 MB/s 2.14 圧縮アルゴリズムの性能はデータの特性に依るところが大きいので、あくまでも参考程度に留めるべきである。 ...
Gentoo LinuxでHyprlandを使う
長年X11でAwesome WMを使用していたが、Waylandへの移行に合わせHyprlandを採用することにした。 筆者が利用しているLightDMではgui-wm/hyprlandを入れるだけでとりあえず動くが、設定でいくつか躓いたことがあるので記録を残しておく。 Hyprlandの設定 Hyprlandでdbusを有効にする Hyprlandには標準のタスクバーが存在しないので、通常はwaybarなどのソフトウェアを使う。 Gentoo(OpenRC)で何も考えずにLightDMからHyprlandを起動すると、dbusセッションが有効にならずwaybarの起動に失敗する。(no such file or directoryとか言われる。実際にはdsubのsession busへアクセスして失敗しているが、configファイルの読み込みに失敗してるように見えて紛らわしい。) /usr/share/wayland-sessions/hyprland.desktopを編集してdbusセッションを有効にする。 Filename: /usr/share/wayland-sessions/hyprland.desktop Exec=dbus-run-session Hyprland XWaylandの設定 筆者はAwesome WMと一緒にrxvt-unicodeを使用していたが、urxvtの設定は~/.Xresourcesで行われている。 HyprlandではX11アプリはXWayland経由で起動するが、通常は.Xresourcesを読み込まないため、hyprland.confの早い段階で読み込む必要がある。.XresourcesでXft.dpiの設定もしておくとよい。 Filename: hyprland.conf exec-once = xrdb -load ~/.Xresources 好みによるが、Xft.dpiでスケーリングを指定して、xwaylandによるスケーリングをforce_zero_scalingに設定した。 Filename: hyprland.conf xwayland { force_zero_scaling = true } fcitxの設定 筆者はX11ではibus-skkを使用していたが、waylandではfcitxのほうが良いらしい。 fcitx5-skkのebuildを適当に書いて使用している。 https://github.com/wtetsuya/gentoo-overlay fcitxの設定はapp-i18n/fcitx-configtoolを使う。