Orz日記 by Akio Morita

_ [雑記]RTL8127 NIC導入試験

暫く前から流通しているRTL8127 10GbE NICだが、国内メーカー製が流通し始めたので、LGY-PCIE-MG3を調達し既設のAQC107Sと入れ替え実施

換装前後の通信速度をbenchmarks/netioで簡易測定した

AQC107Sと異なり、TCP 1 connectionで素直に性能が引き出せる上に、最新世代の半導体採用により低発熱化されており、次世代定番にふさわしい出来

RTL8127系Chip自体はPCIe x2 or x4のバリエーションもあるらしいが、 本機LGY-PCIE-MG3はPCIe Gen4 x1仕様なので、Gen3スロットに装着すると10Gbpsに届かなくなるのが注意点

Jumbo Frameに関しては、RTL8127側のMTUを振ってベンチマークした範囲では、トップスピードの伸びはMTU 4000 octet付近が一番よかった。

測定環境

• netio server - Ryzen 9950X + B650 + Connect X-6 Lx (SFP+ DA接続)
• netio client - Ryzen 7950X + B850 + RTL8126(内蔵) / AQC107S(既設) / RTL8127(購入品)
• Network Switch - QSW-M1208-8C
• OS - FreeBSD stable/15
  • Jumbo Frame MTU 9000
  • net/realtek-re-kmod v1101.00 (エラッタノートに従い Checksum offloading disableにて測定)
  • net/aquantia-atlantic-kmod v0.0.5_3
  • OpenBSD rgeドライバ移植版 (追加)

RTL8126 / MTU 9000 (MSI B850 TOMAHAWK MAX WiFi内蔵・net/realtek-re-kmod v1101.00)

Packet size  1k bytes:  418.08 MByte/s Tx,  445.19 MByte/s Rx.
Packet size  2k bytes:  503.43 MByte/s Tx,  455.32 MByte/s Rx.
Packet size  4k bytes:  479.57 MByte/s Tx,  458.32 MByte/s Rx.
Packet size  8k bytes:  497.26 MByte/s Tx,  486.15 MByte/s Rx.
Packet size 16k bytes:  496.16 MByte/s Tx,  485.87 MByte/s Rx.
Packet size 32k bytes:  492.06 MByte/s Tx,  474.84 MByte/s Rx.

• 5Gbps接続の性能が素直に出ている

AQC107S / MTU 9000 (PCIe Gen4 x4スロット上・net/aquantia-atlantic-kmod v0.0.5_3)

Packet size  1k bytes:  342.60 MByte/s Tx,  485.58 MByte/s Rx.
Packet size  2k bytes:  389.57 MByte/s Tx,  516.60 MByte/s Rx.
Packet size  4k bytes:  398.00 MByte/s Tx,  531.74 MByte/s Rx.
Packet size  8k bytes:  381.86 MByte/s Tx,  548.03 MByte/s Rx.
Packet size 16k bytes:  376.85 MByte/s Tx,  563.24 MByte/s Rx.
Packet size 32k bytes:  377.78 MByte/s Tx,  562.65 MByte/s Rx

• Rxは5Gbps越えるが、Txが振るわない
  • TCP sessionを3並列で稼働させると、合計 9Gbps程度まで出ることを確認済み

RTL8127 / MTU 9000 (PCIe Gen4 x4スロット上・net/realtek-re-kmod v1101.00)

re0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000
        options=2418<VLAN_MTU,VLAN_HWTAGGING,LRO,WOL_MAGIC>
Packet size  1k bytes:  582.29 MByte/s Tx,  859.27 MByte/s Rx.
Packet size  2k bytes:  684.06 MByte/s Tx,  943.62 MByte/s Rx.
Packet size  4k bytes:  1006.32 MByte/s Tx,  949.19 MByte/s Rx.
Packet size  8k bytes:  986.54 MByte/s Tx,  965.99 MByte/s Rx.
Packet size 16k bytes:  973.88 MByte/s Tx,  973.33 MByte/s Rx.
Packet size 32k bytes:  973.65 MByte/s Tx,  943.99 MByte/s Rx.

• 4k/packet辺りから凡そ10Gbpsに届いている

RTL8127 / MTU 1500 (PCIe Gen4 x4スロット上・net/realtek-re-kmod v1101.00)

re0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=2418<VLAN_MTU,VLAN_HWTAGGING,LRO,WOL_MAGIC>
Packet size  1k bytes:  551.69 MByte/s Tx,  682.98 MByte/s Rx.
Packet size  2k bytes:  581.93 MByte/s Tx,  801.25 MByte/s Rx.
Packet size  4k bytes:  700.99 MByte/s Tx,  881.42 MByte/s Rx.
Packet size  8k bytes:  702.18 MByte/s Tx,  876.36 MByte/s Rx.
Packet size 16k bytes:  716.90 MByte/s Tx,  895.89 MByte/s Rx.
Packet size 32k bytes:  736.95 MByte/s Tx,  812.71 MByte/s Rx.

• MTU 9000に比べると伸びが悪い (特にTx側)
  • 割り込み数増大に伴い、driver stack込みのレイテンシが足かせになっている？
  • Driver errataによりChecksum offloading disable設定なので本来期待されるレイテンシよりも遅くなっている可能性有り (今後の改良に期待)
  • OpenBSD driverからの移植版も有る模様
    • base treeへのマージは、ライセンス的にこちらが有望か？
    • 現段階では性能が微妙な模様

RTL8127 / MTU 9000 (PCIe Gen4 x4スロット上・https://github.com/erikarn/if_rge_freebsd/commit/61fd3bba90ff0d8e1fd58bb228f23197e7871a31)

rge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
Packet size  1k bytes:  275.33 MByte/s Tx,  594.32 MByte/s Rx.
Packet size  2k bytes:  569.23 MByte/s Tx,  651.66 MByte/s Rx.
Packet size  4k bytes:  894.56 MByte/s Tx,  653.71 MByte/s Rx.
Packet size  8k bytes:  910.59 MByte/s Tx,  668.27 MByte/s Rx.
Packet size 16k bytes:  904.57 MByte/s Tx,  671.19 MByte/s Rx.
Packet size 32k bytes:  879.12 MByte/s Tx,  681.65 MByte/s Rx.

• OpenBSD rge ドライバの移植版
  • パケットサイズを大きくしても、Rx性能が伸びない
  • Tx性能の初動が net/realtek-re-kmodの半分程度しかない
  • 現時点では、WoL関連コードがコメントアウトされており、WoL待機状態に入らない

rge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000
        options=98<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
Packet size  1k bytes:  260.73 MByte/s Tx,  381.80 MByte/s Rx.
Packet size  2k bytes:  583.25 MByte/s Tx,  360.11 MByte/s Rx.
Packet size  4k bytes:  908.44 MByte/s Tx,  562.28 MByte/s Rx.
Packet size  8k bytes:  907.21 MByte/s Tx,  678.20 MByte/s Rx.
Packet size 16k bytes:  906.04 MByte/s Tx,  696.84 MByte/s Rx.
Packet size 32k bytes:  886.88 MByte/s Tx,  607.84 MByte/s Rx.

• TXCSUM OFFでも、性能はあまり変わらない
• RXCSUM OFFでは、小パケット性能が3割程度低下する
  • 大パケットでのトップスピードはそれほど変わらない

_ [FreeBSD]15.0-RC1きた

BETAが伸びぎみだったが、RCに入ったので大きめのトラブルが無ければ、概ね予定通りのリリースか？

_ [SAD]filevmアロケータアイデア

思いつきメモ

MAP_GUARD拡張を使ったvmアロケータはmmap(2)の拡張に依存するので移植性がないので、POSIX/SUSで移植性のあるアロケータのアイデアをメモメモ

初期化手順

• mkstemp(3)でbacking store fileをopen
• file system namespaceからunlink(2)する
• ftruncate(2)で、16GiBへ拡張する
• mmap(2)でbacking store fileを仮想メモリに割り当てる
• mprotect(2)で、一旦書き込み禁止にする or mmap(2)時点で PORT_NONEで割り当てる

割り当て

• backing store fileから新規割り当て領域分をmprotect(2)でPORT_READ|PORT_WRITEに変更する
  • 実際のページ割り当ては、Copy on Write時に行われる

リソース使用量の考察

• ftruncate時点では、hole fileなのでfile system blockは未割り当て
• 書き込み時のCopy on Write動作で、VM block割り当てが実施される
  • 未初期化ページのbacking storeはhole file backedなので、VMが最適化されていればzero fillされた単一のdummy pageで賄える
  • MAP_PRIVATEで割り当てるとCoWされたpage差分は、anonymous pageとしてVMから割り当てられる
    • over-commit有り環境だと、MAP_GUARD拡張による実装に近い動作になる
    • over-commit無し環境だと、VM backing storeが不足するとmmap(2)の時点で弾かれる点で、MAP_GUARD拡張実装と異なる
  • MAP_SHAREDで割り当てるとCoWされたpage差分は、file backed pageとしてVMから割り当てられ、適宜write backされ page drop対象になる
  • madvise(2)等でWrite Back動作を制御しないと、不要なWriteBackが負担になる
• 終了時は、file descriptor開放に伴い link count zeroとなりfile systemから開放される
  • Write backを発生させる場合、I/O性能的にlocal file system上が望ましい

実装上の考察

• 32bit環境のケースのfallbackは実装すべき
• MAP_GUARD拡張によるbackendと類似の構造になるので、コードの共通化を考えるべきか？
• 最初の初期割り当てサイズを制限するノブを付けておいたほうがよい (メモリリーク時に早期にアボートさせる用)
• MAP_SHAREDなbacking storeを採用する場合、backing storeのパスを設定可能にすべき

_ [FreeBSD]15.0-BETA5？

BETA phaseが延長されてBETA5まで来ている

15.0系は大きな問題は無かった気がするのだが、なんで遅れてるのかなぁ？

_ [雑記]CM695 + MasterLiquid 360 Atmos II VRM Fanファン調整実施

PWM指令値に対して、ファン回転数と騒音計をファン系統毎に個別測定

ファン系統毎のPWMプロファイルは、PBO 85℃運用想定で、 系統毎の騒音値 36dBを目安に調整実施

暗雑音を減らすために一時的にNetwork Switchを停止させたが、 再起動暫く冷却ファンの軸受け音が酷い

しばらくして、静になったが軸受けがヘタっている模様、次はNetwork Switchのファン交換かなぁ…　 →交換実施して、騒音レベルが43dB辺りから36dBぐらいに戻った。耳障りな軸受けの擦れる音が無くなったので、大分静になったように感じる

_ [雑記]USB IFカード導入

μPD720201搭載でPCIe Gen3 x1でUSB 19pinピンヘッダ + USB Type-Eな3ポートなカードと、19pin・Type-E延長ケーブルを導入してケースフロントUSB端子を不安定なB850 chipset側から全面的に切り替え実施

ASMediaなUSB 3.2 Gen2 USBカードもあるが、 XHCIコントローラの信頼性のデータが手元にない＆ Gen4 x4側は10Gbps NICに割り当て済みで空いてるスロットがGen3 x1しかない ため見送り (一応、m.2上にUSB 3.2 Gen2を実装するカードも何種類か密林に置いてあるが、調達してテストするのが面倒…)

μPD720201なのでUSB3.2 Gen1までに制限される上、PCIe Gen3 x1なので、同時使用時の合計帯域も5Gbps制限だが、用途はUSBメモリ・SDCardリーダー・スキャナ接続なので問題ないというか、ストレージ接続では転送エラーは許容できない… (Windows11のUSBスタックは書き込みエラー検知しても、File System層が破損ブロックの再書き込み等の補正を行ってくれないので、B850 chipset側のXHCIが信用できない)

導入製品は、接続チャンネルを変えながら32GBの書き込みを15パス以上クリアしているので、安定性に問題はない模様 (B850 chipset接続だと3パス以内にはエラーイベントに遭遇している)

勝手に再起動

Windows11シャットダウン後、電源落ち直後に再起動する症状発生

どうやら、増設したPCIe USBカード側からPCIe wakeupが出ている模様 (UEFI BIOSからPCIe wakeupをdisableすると止まる)

メインスイッチON時点では勝手に起動しなかったと思うので、ファーム or ドライバ側の問題か？要調査項目

Cold Start状態からFreeBSD側を起動 → shutdown -p nowで落とすで普通にWoL待機状態になり勝手に起動したりはしなかった。 Windows11側でXHCI設定の問題か？

_ [雑記]B850 TOMAHAWK MAX WiFiのUSB3接続 その後

XHCI動作をSDCardリーダーで色々検証した結果まとめ

現時点で分かっていること

• 手持ちのSDCard数種全てで、B850側のXHCIコントローラはNG
  • Ryzen内蔵のXHCIコントローラやμPD720201は問題なく動く
• フロントパネルコネクタをまともに動くUSB3 IFカードに繋げば良い模様
  • Type-A x2 → 19pinやUSB Type-C → Type-E変換ケーブルでリアから引き込むのも有りか？ただし、ケーブル2種を1スロットで引き込むにはブラケットをどうやって準備するかが…
    • 鉄を切削しての自作は面倒、やるならメッシュ仕様品をニッパー等で加工か？(強度は要検討)

_ [雑記]B850 TOMAHAWK MAX WiFiのUSB3接続

B850M SteelLegendと同じく、CPU側のUSB3は全てリアパネル側(Type-Cx3 / Type-Ax1)で、フロント側用のUSB3 19pinヘッダーx2及びType-Ex1はB850チップセット側から生えている

で、手元環境のSDCard Reader2種類でmicroSD Cardへの書き込みエラーの検証状況だが、リアのCPU側USB3.2 Gen2 Type-Aを1mの延長で引き出しものは現時点ではエラー無しの一方、フロントType-Aはエラーが発生している

フロントType-Aに関しては、B850M SteelLegendより心なしか発生数が少ないように見える

B850M SteelLegendから純増したPCIe Gen3 x1スロットへ玄人志向のUSB3.0RA-P2H2-PCIEを増設してμPD720201からフロントType-Aを引き出して試験する準備中(19pinヘッダーケーブルの長さが足りなかった)

オーディオデバイス

実は、Realtek ALC4080はUSBデバイスとして生えてる模様だが、 最近はKVMのHDMI2.1経由のDigital AudioをBenQ EX321UX側からスピーカー/BT Transmitterへ引き出しているので、オンボードオーディオは使っていない罠

_ [雑記]Cooler Master MASTERBOX CM695導入

5インチ光学ベイ付きで360mm AIO水冷をサポートする新ケース Cooler Master CM695へSilverStone SST-FA513-B-Cで組んであるWindows11機を移設

冷却系に、シミオシされてた最近の新AIO水冷 Cooler Master MasterLiquid 360 Atmos II VRM Fanを採用

あわせて、マザーボードをUSB3系とRTL8125にトラブルがあったASRock B850M SteelLegendからMSI B850 TOMAHAWK MAX WiFiへ入れ替え実施 (ASRock B850系でRyzen 9000シリーズの焼損トラブル報告が多いのもあり別メーカー品へ入れ替え)

• 360mmラジエータの取り付けは、5インチベイブラケット・排気ファンを一時撤去する必要あり
• ほぼ120mmファン1個分が光学ドライブと重なる
• MasterLiquid 360 Atmos II・光学ドライブ間のクリアランスは18mmほど
  • PBO 85℃設定でFan100%・ケース開放でのベンチマークでは、光学ドライブ実装時と光学ドライブと5インチベイブラケットを撤去時のベンチマーク性能差は1%未満なので、実用十分な模様
  • Arctic Liquid Freezer III Pro 360等のラジエーターが厚いモデルだと、先頭側のファンを薄くする必要があるかも？
• 個体差かも知れないが
  • フロントのUSB3 Type-Aのコネクタが固め、Type-Cは少し緩め
    • Type-Aは何度か抜き差しすると滑らかになってきた
  • 一番開閉する左側パネルを閉じた直後に上側ネジが渋め
    • パネル後部を押えるとネジが滑らかに締まるので、後方上側のパネル接触部のクリアランスが渋めの模様

ファン全開・ラック定位置に設置した状態で、作業机上の騒音計で50dBほど

WoL動作やUSB3まわりの検証・負荷試験とFan回転数カーブ調整(38〜39dBまで抑えたい)はこれからボチボチと…

CM695感想

光学ドライブと360mm TOPラジエータが載る現行ATXケースしては、コンパクトかつ作業性が良好で素晴らしい

• FA513と比べて、一回り以上大きく裏配線スペースに余裕があるので、作業は楽
• シュラウド内の3.5インチケージの電源側はネジ止めのようなので、電源取り付け・配線時に外すことができるかも？
  • フロント側のケージ壁はリベット締め
• ケースサイズの割にドライブベイが豊富
  • 3.5インチ - シュラウド内のケージに3個・吸気口の壁に1個 (多分、ラジエータ搭載時は干渉する？)
  • 2.5インチ - 裏配線スペースに2個・シュラウド上に3個
• 25mm厚吸気ファンをフロントカバー内に設置可能だが、ファン横の貫通穴はフロントカバーがかぶって来るのでケーブル配線には使えない
  • 5インチベイ下の開口部まで回せば配線可能の模様なので、フロントに分厚い240/280ラジエーターを積載する際は候補になるかも

これまで使ってきたFA513も、TOPラジエータや360mmラジエータが不要であればコンパクトATXケースとして 使い勝手が良いが、CM695に触った後だと裏配線・電源シュラウド内の作業性はやはり劣る

_ [FreeBSD]FreeBSD 15.0-STABLE (stable/15)への移行完了

再起動直後にZPOOLのインポートに失敗する(zpool.cacheがらみ？)とか、 www/apache24入れ直したらUserDirのデフォルト動作が変わっていたとか、 細かなトラブルはあったがstable/14→stable/15の移行作業自体は完了

残るは/etc/fstabにあるzvol UFSのfsck問題であるが、正攻法の解決だとsamba sysvol ACL実装をzvol+USF+POSIX 1e ACLからZFS+nfsv4 ACLへ切り替える必要がある

前回、samba-tool provisionしたときのメモを掘り出さないと…

_ [FreeBSD][samba]net/samba416にてdomain provisioning

sysvolからUFSを追放するために、前回のメモを参考にZFSでdomain provisioningをやり直し

• /usr/local/share/doc/samba416/README.FreeBSDを参考に--option="vfs objects"="dfs_samba4 zfsacl"オプションを追加する
• ldbeditの代わりにsamba-ldbeditを使う

Windows側からワークグループレベルの参照動作が動くことを確認したので、 fstabからZVOL UFSエントリを削除して、ZVOL解体かな…