ToDo:
通常ネットワークとDMZでrouting policyを変えるために net.add_addr_allfibsをoffに代えて、明示的なstatic routingによる設定へ移行
defaultrouter_fib#形式のFIB毎のdefaultrouter定義がうまく機能しない
単純なtypoだった
diff --git a/libexec/rc/rc.d/routing b/libexec/rc/rc.d/routing index 37b3da0f0cef..3ef1571ad931 100755 --- libexec/rc/rc.d/routing.orig +++ libexec/rc/rc.d/routing @@ -171,7 +171,7 @@ static_inet() ;; *) static_routes="${static_routes} _default_fib${_fibnum}" - eval route__default_fib${fibnum}="'default ${_fib_gw} -fib ${_fibnum}'" + eval route__default_fib${_fibnum}="'default ${_fib_gw} -fib ${_fibnum}'" ;; esac done @@ -248,7 +248,7 @@ static_inet6() ;; *) ipv6_static_routes="${static_routes} _default_fib${_fibnum}" - eval ipv6_route__default_fib${fibnum}="'default ${_fib_gw} -fib ${_fibnum}'" + eval ipv6_route__default_fib${_fibnum}="'default ${_fib_gw} -fib ${_fibnum}'" ;; esac done
同じバグの影響を受けた人が他にもいた模様(2023.07.19追記)
MFCされた(2023.08.31追記)
昔、秋月電子で買ったGPS受信モジュールとUSBシリアル変換で作ったGPS受信機をNTPサーバーに導入したために、NTPサーバーは10μsecオーダーでUTC同期した状態を維持できるようになったのだが、NTPがGPSに対して周波数同期を保持する際に調整している周波数偏差が、0.3ppm/℃程度の温度係数で室温と相関している(w
どうやら、NTP・カーネルで経時に使っているクロックソースがエアコンのON(在室時)/OFF(不在時)で発生する5℃程度の温度変化で周波数ドリフトしているのが観測されている模様
一応、数ppm/℃の温度係数はそれなりに優秀か…
あと、複数の計算機を同期させていると、製品間でクロックソース校正精度が数十ppm程度バラついているのが見える
1号機と3号機のアンテナを窓際のほぼ同じ位置に設置して比べた限り、アクティブアンテナ採用の3号機の方が捕捉衛星数が多い(例 8機 vs 12機)模様、細身のアンテナケーブルであることも併せて窓に張り付ける等の設置では扱いやすい
GPSレシーバ1号/Intel N350 と GPSレシーバ3号/AMD Ryzen 7950Xで比べてみたが、GPS 1PPS(kernel pps)基準で GPS NMEAが -200~-300msec offsetがある模様(おそらく、NMEA出力のSerial->USB->割り込みの処理遅延)
GPS 1PPSのジッターは 7μsec @ N305、50μsec @ Ryzen 7950Xぐらいで、7950X系はジッターが瞬間的に150μ辺りまで増えて減衰するのが観測されるが、CPU PBO負荷の変動でTSCがブレている? (GPSのモジュール仕様だと1PPSの精度は±10μsecなので、N305系はほぼカタログ値)
GPS NEMAのジッターは、20~30msec程度で、 GPSレシーバのボーレートを増やしたり、センテンスレポートを絞ってもあまり変わらない
傾向としては、N305の方が小さめに見えるので、offsetの件も含め USB-Serial変換からの割り込み遅延のバラツキが主な原因だと思う
千石電子の店頭にRaspberry Pi4が並ぶようになっていたので、 オモチャとして8GB版を手に入れたので、FreeBSD-13.2-STABLE-arm64-aarch64-RPIをためしてみた
13.2-RELEASE時点でRPIイメージは、8GB版でもそのまま動くという話だが、microSD・USBともにFreeBSDの /boot/loaderを見つけられないで止まる
どうやら、2023.01版Firmwareと PRIイメージに載せているu-boot.binのメモリマップが整合していない模様 (詳しくは、PR269181辺りを参照)
手順的には、以下でブート可能な状態にできた
upstreamの修正が入り始めている模様なので、そのうちports側にも反映されるはず(何時になるか分からんが…)
あと、u-boot.binと /boot/loader.efiコンソール環境では、USBキーボードサポートが無いので、 プロンプトでごそごそ作業するには事前にGPIOヘッダーからシリアルを引き出して接続しておく必要がある
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記
_ Daniel [Hi, I've noticed that you occasionally post some patche..]
_ Daniel [Friendly ping Best regards, Daniel]