トップ 追記

Orz日記 by Akio Morita

ToDo:

  • 15 SAD Fit[]回りの障害事例の解析
  • 10 smart pointer版PEGクラスの再実装(Left Recursionまわり)
2006|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|06|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|07|08|09|10|11|12|
2013|01|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|06|07|08|10|12|
2016|01|02|03|05|06|08|10|11|
2017|01|02|03|04|05|06|07|09|10|11|12|
2018|01|02|03|04|06|07|08|09|10|11|12|
2019|01|03|04|05|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

2024-11-19 [長年日記]

_ [FreeBSD]FreeBSDで144Hz生活

3840x2160 @ 144Hzだと、DP-HDMIアダプタ+HDMI2.1 KVMが挟まっている関係で、液晶Displayの電源を切ると画面が映らなくなる

一度VT-Switchする(TMDS互換のHDMI2.0に一旦切り替える)と映るので、 液晶Display側がPowerON時の転送モードがTMDSになっていて、KVMの出力側から転送モードネゴシエーションが走らないためと推定される(KVM側でEDIDエミュレーションが走っているので、GPUはDisplay Power Offに気づいていない)

VT-SwitchするとFirefoxの表示がGPUアクセラレーション絡みでバグるので、 xrandrを使って画面モードを一旦TMDS互換に切り替えて再度144Hzへ切り替えるスクリプトを書いて、window managerのkeyboard shutcutへ仕込んだ

Display ON後にShutcutを叩くだけで、画面が復帰するようになった


2024-11-17 [長年日記]

_ [雑記]120Hz↑を想定したminiDP1.4-HDMI2.1アダプターまとめ

  • miniDP-DPアダプタ + (株)ミヨシのDP-HDA8K1/BK-A
    • DP-HDMIアダプタ部は、amazonで2600円前後
    • 3840x2160 @ 144Hz 10bit HDRまで問題なく動く
      • Webには、8K 60Hz/4K 120Hzまで対応とあるが、3840x2160 @ 144Hzの実働を確認している
    • VRRは未対応 (ゲーム目的で無ければ問題無い)
    • 手堅く動くが、配線が嵩張り邪魔
    • DP-HDA8K1のminiDP版が欲しいが、存在しない模様(2024/11/17現在)
      • 4K60Hz仕様のminiDP1.2-HDMI2.0アダプタ DPM-4KA1/BKは存在するし、技術的には問題なく作れるはずなので、需要が少ないか?
  • CableMatters miniDP to 8K HDMI Adapter 101101-BLK
    • amazonで3000円前後
    • 3840x2160 @ 120Hz 10bit HDRまで問題なく動く
    • VRRは未対応 (ゲーム目的で無ければ問題無い)
    • スマートにまとまるし、実用的には充分なはずなのだが… 144Hz対応Displayなので、今ひとつ感が残る

2024-11-15 [長年日記]

_ [雑記]ELSA GTX1650 SP V2ファンひび割れ

検証用兼1slotカード予備品として保有していたELSA GTX1650 SP V2のファンブレード基部のプラスチックにひびが入っていた Orz

この状態では、検証作業はともかく本番には投入したく無いなぁ

最初は作業中に工具等をぶつけたかを疑ったのだが、観察した限り、構造上ストレスがかかる部分からひびが伸びているので、プラスチックの成形不良もしくは耐久性不足ではないかと疑っている (メーカー保証は2023年末に切れているので、製品保証的には充分かもしれんが、交換部品が一般に流通しない品なのでもう少しどうにかならんのかなぁ…)

最初の発見は、ブレード根元付近でスピンドル部がひび割れて出来た隙間である

しかし、よく観察するとブレードとスピンドル基部を一体成形したプラスチック部品の回転軸に穴が開けてあり回転軸の金属ピンと嵌め合わせになっている構造で、金属ピンの周辺から3本のひびが放射状に伸びており、うち1本が目に見えて広がった隙間を成している

ブレードが叩かれて割れたというより、成形部品の穴周辺からひび割れが広がり拡大したように見える。穴周辺からひび割れが進行しれいたのなら、成形・加工不良ないし材料の耐久性の問題に思える。

ファンの交換部品がないかネットで調べたが、GPUクーラーの故障事例写真でこの種の放射状のひび割れが結構見つかるので、薄型に成形するプラスチックファンブレード共通の問題かも?

一応、ノギスで測ったファンの諸元をメモ

  • 電源ケーブル 赤黒2本
  • ファンブレード 9枚
  • ファン直径 < 89mm(クーラーのファン穴直径)
  • スピンドル直径 〜 34mm
  • 固定ネジ 3箇所 (正三角形 一辺 〜 39mm)
  • ファン厚み < 12mm (クーラーのファン穴深さ)

ファン交換

とりあえず、密林さんでそれらしきファンの部品を手配した

届いたら、交換修理を試みる予定 (多分、カバーを開くのに2mmぐらいの六角レンチが必要…)

RTX A400の方は、β版ドライバでの安定動作が確認出来たので、実戦へのRTX A400(TDP 50W・LP可)を投入し GTX1650 SP V2(TDP 70W)は検証用・予備品として保持予定


2024-11-06 [長年日記]

_ [FreeBSD]4K 120Hz/144Hzモード

3840x2160 144Hz対応モニタ(BenQ EX321UX)・HDMI2.1対応KVM環境を構築したので、ぬるぬるスクロールを目指してFreeBSD + nvidia-driver環境でも 120/144Hzを試してみたメモ

  • GT1030(DP-HDMI変換アダプタ経由) + nvidia-drm-61-kmod-550.127.05_1
    • xrandr(EDID)の3840x2160は、60Hzまで (DP接続の公式スペックが 4K 60Hzまでなので想定通り)
  • RTX4070SUPER(HDMI2.1接続) + nvidia-drm-61-kmod-550.127.05_1
    • nvidia-settingのDisplay Device Informationには、Signal: HDMI FRL, Connection Link: Singleと表示 (HDMI2.1接続)
    • xrandr(EDID)の3840x2160に 100, 120, 144Hz有り
      • nvidia-settingから、120Hzへ切り替え・画面表示確認
      • nvidia-settingから、144Hzへ切り替え・画面映らず/15秒後自動復帰(default設定の不備)
        • /var/log/Xorg.0.logでは、EDID HorizSyncは15.000-255.000 kHzと報告されるが、EDID内の3840x2160 144HzモードはHorizSync 325.873 kHzと報告されている (Range Checkで排除された模様)
          • Screen sectionにて、HorizSyncオプションにて明示的にを15-325.873と記述したら、144Hzに切り替えられるようになった
        • EDID取得のHorizSync上限が255になっていることから、EDIDが間違っているのではなく表現域の上限に当たっている気がする
          • EDID Display Range Limits Descriptorの仕様を流し読みした範囲では、Horiz Sync Min/Maxはそれぞれ 8bitで1〜255を表現、修飾ビット2bitでMin/Maxにオフセット255加える仕様なので、nvidia-driverドライバがデコードし損ねてる?
    • xdm/XorgでKVM非選択状態での起動に関して
      • 3840x2160 120/144Hz設定だと、nvidia-modeset: WARNING: GPU:0: HDMI FRL link training failed.が発生し、KVMを選択しても画面が写らない (KVMが答えるDisplay EDID自体は認識している)
        • KVM選択後、Ctrl+RでXorgを再起動すると問題なく映る状態になる
        • HDMI FRL接続確立時に、トレーニング信号で通信するモニタが必要な模様… (HDMI FRL確立後は、KVMを切り替えても問題は起きない)
      • 3840x2160 60Hz設定だと、HDMI2.0互換のTDMS接続で立ち上がり、KVM選択後問題なく映る
        • nvidia-settingで120/144Hzに切り替えた時点で、HDMI FRL接続に移行する
  • RTX A400(DP-HDMI変換アダプタ経由) + nvidia-drm-61-kmod-550.127.05_1
    • xrandr(EDID)の3840x2160に 100, 120, 144Hz有り (144Hzが入るかは、DP-HDMI変換アダプタに依存)
    • X.orgにて、100, 120, 144Hzは写らない (モニタ側ではNo signal扱い)
      • nvidia-settingのDisplay Device InformationにはDisplayPort 4lanes @ 5.40Gbpsと表示されているので、DP1.2で認識されている?
  • RTX A400(DP1.4ケーブル経由) + nvidia-drm-61-kmod-550.127.05_1
    • xrandr(EDID)の3840x2160に 100, 120, 144Hz有り (DP2.1・144Hz対応モニタなので当然なのだが)
    • X.orgにて、100, 120, 144Hzは写らない (モニタ側ではNo signal扱い) RTX4070SのHDMI出力なら120Hz普通に映るのに何故 Orz

試験したRTX A400について

  • ASK扱いのRTX Quadroシリーズの Ampere/GDRR6 4GB/1スロット/miniDP1.4a x4なカード
    • 国内流通では、ELSA扱いのカードもあるが、同一基盤?
    • X.orgで4K120Hzが確認済みのRTX 4070SUPER(Ada Lovelace・DP1.4a x3 + HDMI2.1a x1)の一世代前のGPU
    • カタログには、miniDP1.4にて 4096x2160 @ 120Hzでの 4画面出力をサポートするとあるので、DisplayPortなら3840x2160 120Hzは問題なく動くはず
  • DP1.4接続時は、カード付属の純正miniDP-DPアダプタ + Elecom DP1.4ケーブル
  • DP-HDMI変換アダプタは二種類試験
    • EDIDに144Hzが出る構成 - カード付属の純正miniDP-DPアダプタ + MCO DP1.4-HDMI2.1アダプタ(8K60Hz/4K120Hz対応)
    • EDIDが120Hzまでの構成 - CableMatters miniDP to 8K HDMI Adapter (101101-BLK)
  • まだWindows機には挿してないので、Windows11での動作は未確認

EDID Display Range Limits Descriptor(EDID HorizSync)の考察

  • 規格的には、Maximum Horiz SyncはkHz単位で1〜255と256〜510の表現モードがある (8bit整数値 + 1bitフラグで表現)
  • RTX4070SUPER(HDMI2.1接続)にて、Dual bootのWindows11は問題なく144Hz設定が出来ている
    • X.orgでは、nvidia driver 550の検出するEDID HorizSyncは、15-255kHzと報告され、3840x2160 144HzモードはHorizSync検査で無効モードになる模様 (HorizSyncのoverrideで問題なく動作するようになる)
  • EDID Maxmum HorizSyncが 255になっている件への仮説
    • EDID Display Range Limits Descriptorの記述が正しくない(Display firmware側のバグ)が、Windows11は無視して動いている
    • nvidia driver 550が、EDID Display Range Limits Descriptorのデコードに失敗している(nvidia driver側のバグ)
    • nvidia driver 550のMax HorizSyncの内部表現が8bitで最大値に丸められている(nvidia driver側の高リフレッシュレートサポートの不足)

追試(1)

  • RTX4070SUPER(DP-HDMI変換アダプタ経由HDMI2.1接続) + nvidia-drm-61-kmod-550.127.05_1
    • 使用アダプタは、(株)ミヨシのDP-HDA8K1/BK-A
    • nvidia-settingのDisplay Device Informationには、Signal: DisplayPort, Connection Link: 4 lanes @ 5.40Gbpsと表示 (DP1.2接続)
    • xrandr(EDID)の3840x2160に 100, 120, 144Hz有り
    • nvidia-setting上から、120・144Hz設定に問題なく切り替え可能
      • /var/log/Xorg.0.logではEDID HorizSyncは15.000-255.000 kHzと報告されている (HDMI2.1接続時と同様)
      • 追加の設定無しに144Hzに切り替えられた (HDMI2.1接続時と挙動が異なる/DPとHDMIでnvidia driver内のモード検査が異なる?)
      • AllowGSYNCCompatible=Onディレクティブを付与しても、G-SYNCが有効にならない
    • 当該DP1.2-HDMI2.1アダプタは、4K 144Hzで映せることが確認出来た

追試(2)

  • RTA A400(同梱miniDP-DPアダプタ + DP-HDMI変換アダプタ経由HDMI2.1接続) + nvidia-drm-61-kmod-550.127.05_1
    • 使用DP-HDMIアダプタは、追試(1)で用いた(株)ミヨシのDP-HDA8K1/BK-A
    • nvidia-settingのDisplay Device Informationには、Signal: DisplayPort, Connection Link: 4 lanes @ 5.40Gbpsと表示 (DP1.2接続)
    • xrandr(EDID)の3840x2160に 100, 120, 144Hz有り
    • nvidia-setting上から、120Hz設定に一度だけ切り替え成功 (起動直後?)
      • 120 → 144Hzに切り替え失敗後の120Hz復帰後にブラックアウト、Xorg再起動後も120Hzへの切り替えは成功しない(画面暗転のまま)
      • miniDP-DPケーブルを挟んだ動作が不安定? (当該DP-HDMIアダプタは、RTX4070SUPERとの組み合わせで144Hzまで動作確認済み)
      • miniDPポートは他3ポートあるので、ポートの個体差の可能性は?
        • コネクタ並び順とnvidia driverが識別する出力番号が綺麗な並びになっていないので、設定変更が面倒… Orz

追試(3)

Windows11機 + RTX A400 on x16 slot(Nvidia driver 553.24)での3840x2160での動作検証 ... 普通に動く模様

  • RTX A400 + CableMatters miniDP to 8K HDMI Adapter (101101-BLK) + HDMI2.1 KVM
    • リフレッシュレートメニューは120Hzまで (Xorg上の動作と同様)
    • G-SYNCの設定メニューは現れない
Mode Rate 表示 備考
RGB/SDR 60 default 動作
RGB/HDR 60 10bitRGB動作
RGB/SDR 120
RGB/HDR 120 10bitRGB動作
  • RTX A400 + 同梱miniDP-DPアダプタ + MCO DP1.4-HDMI2.1アダプタ + HDMI2.1 KVM
    • リフレッシュレートメニューは144Hzまで (Xorg上の動作と同様)
    • G-SYNCの設定メニューは現れない
Mode Rate 表示 備考
RGB/SDR 60 default 動作
RGB/HDR 60 10bitRGB動作
RGB/SDR 120
RGB/HDR 120 10bitRGB動作
RGB/SDR 144
RGB/HDR 144 10bitRGB動作
  • RTX A400 + 同梱miniDP-DPアダプタ + DP1.4ケーブル
    • リフレッシュレートメニューは144Hzまで
    • G-SYNCの設定メニューが現れる
Mode Rate 表示 備考
RGB/SDR 60 default 動作
RGB/HDR 60 10bitRGB動作
RGB/SDR 120
RGB/HDR 120 10bitRGB動作
RGB/SDR 144
RGB/HDR 144 10bitRGB動作

追試(4)

  • GTX1650 SP V2 on x1 slot(DP-HDMI変換アダプタ経由HDMI2.1接続) + nvidia-drm-61-kmod-550.127.05_1
    • 使用アダプタは、(株)ミヨシのDP-HDA8K1/BK-A
    • nvidia-settingのDisplay Device Informationには、Signal: DisplayPort, Connection Link: 4 lanes @ 5.40Gbpsと表示 (DP1.2接続)
    • xrandr(EDID)の3840x2160に 100, 120, 144Hz有り
    • nvidia-setting上から、120・144Hz設定に問題なく切り替え可能
      • /var/log/Xorg.0.logではEDID HorizSyncは15.000-255.000 kHzと報告されている
      • 追加の設定無しに144Hzに切り替えられた
    • nvidia-setting上には、G-SYNCのcheckboxは現れない
      • AllowGSYNCCompatible=Onディレクティブを付与しても、G-SYNCが有効にならない
    • RTX A400で動かない理由が、ますます分からなくなった

追試(5)

  • RTA A400(同梱miniDP-DPアダプタ + DP-HDMI変換アダプタ経由HDMI2.1接続) + nvidia-drm-61-kmod-550.127.05_1
    • 使用DP-HDMIアダプタは、追試(1)で用いた(株)ミヨシのDP-HDA8K1/BK-A
    • ホスト環境は、追試(3)で使用したWindows11機に構築(FreeBSD 14.2-STABLE)
    • 追試(2)と同様に、120/144Hzモードへの切り替えでは画面暗転のまま映らず → 動作が安定しないのは、nvidia driverのsoftwareの問題の模様
      • 2024/11/17時点で最新のβ版 560.28.03を導入してみると、問題なく映るようになった
      • G-SYNCに関しては追試(3)(4)と同様なので、当該DP-HDMIアダプタはAdaptive Sync/VRRサポートしていない模様

検証課題

  • MCO DP1.4-HDMI2.1アダプタをRTX4070Sに接続した試験 (DP-HDMIアダプタの4K120Hz対応の検証)
  • RTX A400をWindows機に挿して、Windwos上での動作確認 (RTX A400の4K120Hz・144Hz動作確認)
  • RTX A400にてDP直結配線での追試 (以前の試験は活線差し替えで経路変更しているので、Cold Startを検証すべき)
  • 1slotカードの予備品ELSA GTX1650 SP V2で検証 (HDMI側は2.0bだが、DP側は1.4なので 4K 120Hz動作をサポートするはず・基盤サイズ/TDPとものRTX A400より大きいので当方の用途的にはあまり使いたく無いのだが…)
  • RTX A400で120/144Hz動作を確認できたWindows11機にFreeBSD/Xorgを導入して検証する
    • nvidia-drm-61-kmod-550.127.05_1では、安定した120/144Hz切り替え動作を確認出来ない・β版 560.28.03にて、120/144Hz切り替え動作確認 → nvidia-drverの問題の模様
    • RTX A400 + nvidia-drm-61-kmod-550.127.05_1にて、DP直結配線で動作が安定しなかった件も nvidia-driverの問題だったと推定される

2024-10-28 [長年日記]

_ [FreeBSD][Ryzen]amdtemp on Ryzen 9 9950X

備忘録としてまとめておく

  • 既に動くRyzen 9 7950Xとの比較
    • amdsmn driverがprobeする hostb0@pci0:0:0:0のPCI device IDは同一 (device=0x14d8)
    • amdsmn/amdtemp driver共に FamilyID checkで拒絶される
  • FamilyID/ModelIDまとめ
Processor FamilyID ModelID Stepping
Ryzen 9 9950X 1Ah 44h 0
Ryzen 9 7950X 19h 61h 2
  • 最低限必要な修正
    • 1Ah Family support
    • 1Ah Family向けのamdtemp_probe_ccd__sensors19h相当関数
  • stable/14上で書いたパッチ
diff --git a/sys/dev/amdsmn/amdsmn.c b/sys/dev/amdsmn/amdsmn.c
index a0a7b9db60f8..e5c5656c5f11 100644
--- a/sys/dev/amdsmn/amdsmn.c
+++ b/sys/dev/amdsmn/amdsmn.c
@@ -205,6 +205,7 @@ amdsmn_probe(device_t dev)
       case 0x15:
       case 0x17:
       case 0x19:
+      case 0x1a:
               break;
       default:
               return (ENXIO);
diff --git a/sys/dev/amdtemp/amdtemp.c b/sys/dev/amdtemp/amdtemp.c
index 583ff80cac69..0220887134fd 100644
--- a/sys/dev/amdtemp/amdtemp.c
+++ b/sys/dev/amdtemp/amdtemp.c
@@ -229,6 +229,7 @@ static int32_t     amdtemp_gettemp15hm60h(device_t dev, amdsensor_t sensor);
 static int32_t        amdtemp_gettemp17h(device_t dev, amdsensor_t sensor);
 static void   amdtemp_probe_ccd_sensors17h(device_t dev, uint32_t model);
 static void   amdtemp_probe_ccd_sensors19h(device_t dev, uint32_t model);
+static void   amdtemp_probe_ccd_sensors1ah(device_t dev, uint32_t model);
 static int    amdtemp_sysctl(SYSCTL_HANDLER_ARGS);

 static device_method_t amdtemp_methods[] = {
@@ -316,6 +317,7 @@ amdtemp_probe(device_t dev)
       case 0x16:
       case 0x17:
       case 0x19:
+      case 0x1a:
               break;
       default:
               return (ENXIO);
@@ -475,6 +477,7 @@ amdtemp_attach(device_t dev)
               break;
       case 0x17:
       case 0x19:
+      case 0x1a:
               sc->sc_ntemps = 1;
               sc->sc_gettemp = amdtemp_gettemp17h;
               needsmn = true;
@@ -538,6 +541,8 @@ amdtemp_attach(device_t dev)
               amdtemp_probe_ccd_sensors17h(dev, model);
       else if (family == 0x19)
               amdtemp_probe_ccd_sensors19h(dev, model);
+      else if (family == 0x1a)
+              amdtemp_probe_ccd_sensors1ah(dev, model);
       else if (sc->sc_ntemps > 1) {
               SYSCTL_ADD_PROC(sysctlctx,
                   SYSCTL_CHILDREN(sysctlnode),
@@ -889,3 +894,24 @@ amdtemp_probe_ccd_sensors19h(device_t dev, uint32_t model)

       amdtemp_probe_ccd_sensors(dev, maxreg);
 }
+
+static void
+amdtemp_probe_ccd_sensors1ah(device_t dev, uint32_t model)
+{
+      struct amdtemp_softc *sc = device_get_softc(dev);
+      uint32_t maxreg;
+
+      switch (model) {
+      case 0x40 ... 0x4f: /* Zen5 Ryzen "Granite Ridge" */
+              sc->sc_temp_base = AMDTEMP_ZEN4_CCD_TMP_BASE;
+              maxreg = 8;
+              _Static_assert((int)NUM_CCDS >= 8, "");
+              break;
+      default:
+              device_printf(dev,
+                  "Unrecognized Family 1ah Model: %02xh\n", model);
+              return;
+      }
+
+      amdtemp_probe_ccd_sensors(dev, maxreg);
+}
  • それっぽく動く模様
CPU: AMD Ryzen 9 9950X 16-Core Processor             (4292.17-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0xb40f40  Family=0x1a  Model=0x44  Stepping=0
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x7ed8320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>
  AMD Features2=0x75c237ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT,TCE,Topology,PCXC,PNXC,DBE,PL2I,MWAITX,ADMSKX>
  Structured Extended Features=0xf1bf97ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,PQE,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,AVX512CD,SHA,AVX512BW,AVX512VL>
  Structured Extended Features2=0x19405fde<AVX512VBMI,UMIP,PKU,OSPKE,AVX512VBMI2,GFNI,VAES,VPCLMULQDQ,AVX512VNNI,AVX512BITALG,AVX512VPOPCNTDQ,RDPID,MOVDIRI,MOVDIR64B>
  Structured Extended Features3=0x10000110<FSRM,AVX512VP2INTERSECT,L1DFL>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  AMD Extended Feature Extensions ID EBX=0x791ef257<CLZERO,IRPerf,XSaveErPtr,RDPRU,BE,WBNOINVD,IBPB,INT_WBINVD,IBRS,STIBP,STIBP_ALWAYSON,PREFER_IBRS,SAMEMODE_IBRS,NOLMSLE,SSBD,CPPC,PSFD,BTC_NO,IBPB_RET>
  SVM: Features=0xfebb9dff<NP,LbrVirt,SVML,NRIPS,TscRateMsr,VmcbClean,FlushByAsid,DecodeAssist,<b8>,PauseFilter,EncryptedMcodePatch,PauseFilterThreshold,V_VMSAVE_VMLOAD,vGIF,GMET,<b19>,GuesSpecCtl,<b21>,<b23>,<b25>,<b26>,<b27>,<b28>,<b29>,<b30>,<b31>>
Revision=1, ASIDs=32768
  TSC: P-state invariant, performance statistics
...
amdsmn0: <AMD Family 1ah System Management Network> on hostb0
amdtemp0: <AMD CPU On-Die Thermal Sensors> on hostb0
amdtemp0: Found 32 cores and 1 sensors.
...
% sysctl dev.amdtemp
dev.amdtemp.0.ccd1: 40.2C
dev.amdtemp.0.ccd0: 40.0C
dev.amdtemp.0.core0.sensor0: 50.6C
dev.amdtemp.0.sensor_offset: 0
dev.amdtemp.0.%parent: hostb0
dev.amdtemp.0.%pnpinfo:
dev.amdtemp.0.%location:
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent:

2024-10-27 [長年日記]

_ [雑記]FNS-3200導入

宅内LANのコアスイッチとしてQSW-M1208-8Cを運用しているが微妙に検証作業等でポートが足らんことがあるので、FOXNE FNS-3200を導入

最近流行りのRealtekの2.5G Ethernet SoCを使ったハブで、 SFP+ 1ポートに 2.5GBASE-TなRJ45が 8ポートのファンレススイッチで 9000円前後で購入できる

ファンレスになっているが、筐体が熱を持つ訳でも無く(10GBASE-TなFSP+モジュールを刺した場合は知らんが…)、マネージメント機能も無いプレーンな小型スイッチングハブである

まあ、電源が12V ACアダプター(PSEマークは入っていた)なのは、インフラ用途では不満だが、価格帯と大きさから考えればBuffaloやElecomのやつも同様なので価格相応といったところか

1G/2.5Gポート増設用途でアンマネージド型を選択したが、1000〜2000円上乗せすると同SoCベースなマネージド型もある模様、ただ価格帯が価格帯だけにUIまわりの完成度は期待出来ない気がする Orz

QNAPとかNetgear等で10Gスイッチの新作が投入されているが、大抵規模が大きすぎて高いか一台に纏めるにはポートが足らない or SFP+が多すぎる辺りなのが、逸般家庭用の難しいところ

理想的には、VLAN使えて、SFP+ 4ポート・10G RJ45 4ポート・2.5G RJ45 8ポートぐらいが繋がるハーフラックスイッチで10万円前半の製品が欲しい

QNAPだとQSW-M3224-24Tはデカすぎ&SFP+が無いのがネック、QSW-M3216R-8S8Tだと総ポート数的にはマッチするが、RJ45がもう少し欲しいところ (モジュールは意外に単価と発熱が…/あとQSW-M1208-8Cの経験だと10GBASE-Tモジュール挿すとFirmwareでエラーが出るケースが難、通信遮断は一時的だが、以後マネージドポートのMACアドレスとファン回転数が見えなくなる)


2024-10-16 [長年日記]

_ [雑記]NTP offsetジッターの件

とりあえず、現状までに分かったことを纏める

  • Ryzen 9 9950X/B650M PG Riptide Wifi環境で、同一ネットワーク内のGPS付きNTP serverとのNTP offsetが不定期に300msecほどずれる
    • 2024/09/14頃から発症し、現在も続いている
  • 使用マザーASRock B650M PG Riptide WiFiのFirmwareリリース日
Ver.Date備考
3.082024/09/19NTP offsetジッター発生より後
3.062024/07/30Ryzen 9 9950X運用開始時点のFirmware
3.012024/05/16
  • 同一ネットワーク内ノードまとめ
    • A - Ryzen 9 9950X機 (問題のノード)
      • インターネットGatewayとして運用している
        • 2024/08/30頃にRyzen 9 7950Xから9950Xに換装している
      • (B)への経路は、LAN内の10G core switch経由 (Connext-X6 -DAC-> Switch -CAT.6A-> (B))
      • nict.go.jpへの経路は、インターネットプロバイダ経由 (RTL8125(100BASE-TX) -Cat.6A-> ONU)
      • nict.go.jpと(B)および予備のGPSレシーバでNTPを構成すると、nict.go.jp・GPSを基準に、(B)のoffsetが不定期に+300msec飛んで見える
        • (B)のoffsetは±0付近と+300msec付近に二値化しているように見える
      • sysutils/clockspeedに含まれるsntpclockで、(A)の時計を基準に(B)のNTP時刻を観測すると、24時間以上連続で±1msec内のoffsetで安定している (1秒周期の観測)
    • B - GPS NTP server
      • GPS 1PPSとnict.go.jpに同期しているNTP server
      • (A)への経路は、LAN内の10G core switch経由 (I-225V -Cat.6A-> Switch -DAC-> (A))
      • 外部ネットワーク接続自体は、(A)をgatewayにしている
      • nict.go.jpとGPS 1PPSは±1msecで同期しており、offsetの日格差も小さい
    • C - Ryzen 9 7950X機 (テストノード)
      • (A)と同型のマザーボードを搭載した試験機
      • (A),(B)への経路は、LAN内の10G core switch経由 (RTL8125(2.5GBASE-T) -> Switch -> (A) or (B))
      • nict.go.jpへの経路は、(A)をgatewayにしている
      • nict.go.jpと(B)でNTPを構成すると、nict.go.jpと(B)へのoffsetは追従している
        • (A)のようなoffsetの不定期な飛びは見られない (連続的な変動は、7950X機側のクロックドリフトの模様)
  • 調査まとめ
    • (A)のConnect-X6インターフェースの遅延ばらつきとは考えにくい
      • (A)以外のnict.go.jpの通信で影響が出るはず
      • sntpclockによる(A)-(B)間の観測結果と一致しない
    • (A)にて(B)のNTP offset変動時に、(A)および(B)ではGPS offsetの変動が観測されていない
      • (A)および(B)のローカルクロックは問題なく同期している (先のsntpclockの観測事実と整合する)
    • 観測されるoffsetの飛びの幅と符号が一定である (約 +300msec)
    • (A)と(B)のNTP clientとしての違いは、マザーボード・メモリ等に欠陥が無ければ、CPUモデル・使用NICとGatewayであるか否か (OSは同一)

現状の調査状況からは、ntpdのソフトウェアのバグもしくは、NTPDがやりとりするNTPパケット(UDP port 123→port 123)の混線((A)がNAPTな外部Gatewayなのでパケットがあつまる)あたりしか原因が思いつかん Orz

時間が取れたら、RTX830を本番投入してGateway機能を分離してみよう…NTPパケットの混線ならこれで治るはず


2024-10-09 [長年日記]

_ [雑記]NTP offsetジッターの件

buildworldし更新・再起動したが、解決していない…違う原因の模様

ネットワーク経路まわりの変更をトライすべきか…


2024-10-08 [長年日記]

_ [雑記]NTP offsetジッターの件

先日から調べてるNTP offsetジッターの件であるが、muninに記録されているジッターの悪化が始まった時刻帯とNTP clientノードの再起動時刻が被っている上に、以後リブートしていない…

一方、同一のGPS NTP serverに同期している正常なNTP clientのbuildworldはそれよりも新しい

ひょっとして、stable/14で更新途上の変なbuildを引いている?

少なくともCPU更新(Ryzen 7950X → 9950X)に伴うハードウェア入れ替えは2024/08/30前後なので、CPU起因では無い模様…


2024-10-04 [長年日記]

_ [雑記]NTPのoffsetジッターがおかしい

ここ最近、GPS同期しているNTPを参照していると妙にoffsetジッターが大きいホストがある…

どうも、10G switchの問題っぽぃぞ…

  • offsetジッターが大きいホストは10G SFP+ DA接続のホストだけ
    • 2.5GBASE-T接続とかは問題が出ない…
  • Switchをリブートすると症状が改善した
  • SFP+ポートに 10GBASE-Tモジュール刺していると、スイッチ自身が一時スタックする不具合が前からある (モジュール発熱起因の誤作動 or ファームのバグな気がする…)
    • スタック時は、ホスト側から見てると一時リンクダウンしたあと再リンクする挙動

カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記