https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
この中で、
arp_announce
arp_ignore
rp_filter
の3つは、要注意。rp_filterは、ディストリビューションによっても、デフォルト値が違う(適用パッケージに依存しているかもしれないが)。
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
この中で、
arp_announce
arp_ignore
rp_filter
の3つは、要注意。rp_filterは、ディストリビューションによっても、デフォルト値が違う(適用パッケージに依存しているかもしれないが)。
少しディープなところにダイブする(バスタブ レベルだが)。一般的なNICカードでサポートされているPTPハードウェアタイムスタンプが具体的に何をしてくれるのか、いまひとつ把握できていなかった。ここでは、特に、タイムスタンプ送信に関する実装について調べる。なお、PTPの原理そのものは、ここでは追わない。
Precision Time Protocol (PTP) は、隣接ノード間(距離には依存しない)でマイクロ秒オーダの誤差範囲で時刻同期するプロトコル。PCで普通に実施できるNetwork Time Protocolより精度が高く、スマホ基地局間タイミング同期、ロボットアーム同期、オーディオスピーカ同期等で適用される。10年前ならホットな技術だったかもしれないが、今は成熟し枯れている様子。LinuxでのPTPデーモンは2種類あり、主要ディストリビューションでは両方のパッケージがある。なお、OSの上でPTP時刻同期を実施しても、精度面での効果は無く、従来のNTPで十分である。
パッケージ名 | デーモン名 | Hard Time Stamp |
---|---|---|
linuxptp | ptp4l | 対応有り |
ptpd, ptpd2 | ptpd, ptpd2 | 対応無し |
ptp4lの「4l」は「for Linux」の略。
PTPの伝送レイヤも2種類ある。業界毎にプロファイルがあり、サポート範囲が異なる。原則はマルチキャストだが、UDPはユニキャストでも対応できる様子。
Layer | Ethernet Type | Port |
---|---|---|
L2 Ethernet | 0x88F7 | ─ |
L4 UDP | IPv4 0x0800, IPv6 0x86DD | 319, 320 |
INTEL 82574Lを搭載したPCIe NICカード とする。デバイスがどこまで対応しているかは、ethtool -Tコマンドで確認できる。但し、ここでの表示はあらかじめソースに埋め込まれた内容を表示しているにすぎず、レジスタアクセス等は無い様子。
# ethtool -i enp1s0 driver: e1000e version: 3.2.6-k firmware-version: 1.8-0 ## # ethtool -T enp1s0 Time stamping parameters for enp1s0: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 1 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on (HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
82574Lのデータシート 7.7.2項や7.7.3.2項によれば、送信ディスクリプタExtCMD bit0(TimeStamp)をセットすると、PTPフィールドにタイムスタンプが刻印されると解釈できる。82574LにはPTPクロック専用のH/Wカウンタが内蔵されており、phc_ctl コマンドによって、OS時間やRTCとは別の時刻が刻まれている様子を確認できる。phc_ctlはlinuxptpのS/Wパッケージに含まれている。
~# echo "OS TIME:"; date; echo "RTC TIME:"; hwclock; echo "PTP TIME:"; phc_ctl eth0 get OS TIME: 2019年 6月 20日 木曜日 21:45:03 JST RTC TIME: 2019-06-20 21:45:36.827508+0900 PTP TIME: phc_ctl[3345.712]: clock time is 1561034696.559877320 or Thu Jun 20 21:44:56 2019
82574Lよりも新しいI350では、PTPに関連付けたGPIO/SDPピン出力を定義できる。この信号上のタイミングに基づくエッジでのデバイス制御が王道の使い方だろう。
ここに、送信ディスクリプタ ExtCMD bit0(E1000_TXD_EXTCMD_TSTAMP)をセットするLinuxデバイスドライバのソース実体がある。ptp4lを使った場合、/etc/linuxptp/ptp4l.confにおけるtime_stampingの設定が「hardware」ならばこのビットがセットされ、「software」ならセットされないことを確認した。
つまり、S/WはPTP送信フレームを生成するが、ディスクリプタにマークすれば、あとはH/Wが内蔵64bitカウンタを元によろしくやってくれるという感じである。
なお、インテルのNIC/Ethernetコントローラを本格的なPTPシステムに含める場合、ドライバS/Wをメーカのホームページから入手し更新するべきである。
他のオフロード機能と同様、PTPについてもNIC(またはEthernetコントローラ)がフレームの上位機能に介入する。フレームはS/Wが作るが、NICは勝手に判断して正確なタイムスタンプを付与する。その時、UDPの内部が変わるので、当然、UDPチェックサムも(再)生成/付与される。 試しに82574L搭載のUbuntuマシンで「sudo apt install linuxptp」を実行したら、何の設定も無しに1秒に2〜3フレームのPTPをマルチキャストし始めた。このPTP時刻精度を評価するには、高精度なマスタークロック源に同期した上で、専門の測定機材での評価が必要。
linuxptpをインストールすると、phc2sys (ptp hardware clock to the system)もインストールされる。実運用では、これの使い方、要否についても把握しておく必要がある。たいていは不要と判断できる。
ptp4lデーモンが起動しない場合、下記ファイルをチェックする。
/etc/linuxptp/ptp4l.conf ## time_stamping を software にすることも可
/lib/systemd/system/ptp4l.service ## -i でPTP対応のLANポートを指定
## ptp4l.serviceを更新したら、systemctl daemon-reload ; systemctl restart ptp4l
その他、redhatのマニュアルも見ておくと良い。
ラズパイをPTPスレーブにして同期させる手早い方法。
apt install ptpd ptpd -i eth0 -s -C
OS上だけでPTPを実施してもPTP本来の精度的には無意味だが、例えば、狭いネットワーク内の機器でログ時刻を合わせたいといったシーンはよくある。そうしたシーンではPTPはお手軽な時刻合わせ手段となる。但し、Windowsで動く手軽なPTPソフトは見つかっていない(仮想マシン上のLinuxでは動く)。
エアロ/ダンスのスタジオプログラムに参加するときは、軸を上、脱力、顔面垂直キープ等、その日のコンディションに合わせて2〜4テーマを持って臨むが、エアロ中上級クラスでは、そんなことは頭からきれいにブッ飛ぶ。動きの中で振りやタイミングを考えている余裕は全く無い。なので、振りをフィーリングで一発キャッチするセンスが欲しい!ダンス経験の無い私が今の年齢でどこまで行けるか、まぁ、楽しみながらマイペースでチャレンジしよう。
自己流 一発キャッチへの試み
毎年、春と夏の境い目で、痛い目にあう。背中・首・腰のどこかを痛めることが多い。気温が高くても湿度が低いうちは、まだ体は冬モード。湿度が上がりモワっとした空気に包まれる6月中旬〜下旬が要注意。対策はいたって簡単なことだが、これが、毎年、できていない。私にとって重要な順序で記述すると、
これだけで、無難に乗り切れるはず。今年こそ、無難に夏モードの体にモードチェンジしたい。
【結果】
「ヨガ友」からピックアップしたストレッチが功を奏し、背中・首は問題無く、腰はぎりぎりセーフで乗り切った。しかし、、、
6月中旬〜 倦怠感がつきまとうようになる。毎日が月曜日という感じ。
6月下旬〜 頭頂部にイボが育ち始める。原因不明の高周波の耳鳴り(右)が突然始まる。耳鼻科では異常無し。
7月上旬〜 頭頂部のイボは直径5mmの楕円に膨れ上がる。耳鳴り(右)は依然として解消せず。酸性体質を疑い、飲料水をアルカリイオン水(メーカ品と地方取寄品)に変更。
7月中旬〜 アルカリイオン水の効果が徐々に出たか?それとも梅雨明けが近くて気圧が上がったせいか?倦怠感が解消の方向。3週間続いた耳鳴りが止む。頭頂部イボが硬直し始める。
7月下旬〜 倦怠感は解消。頭頂部イボは縮小。8月中旬時点で、イボはほぼ消滅。
うーん、、、いったい何が悪くて、何が良かったのだろうか。単に頭頂部の虫さされだったのか。。。
もうすぐ来ますね、CentOS 8。完全にノーマークでした。組込開発ホストをCentOS7からUbuntu Mate 18.04に移行しつつありましたが、Screenletsを無事起動させることがてきたらCentOS 8で行こうと思います。
CentOS 8 のビルドステータスは、下記で確認できます。・・・あと1〜2ヶ月かな?
wiki.centos.org
Debian10 (Buster)も、もうすぐstableに昇格しそうです。こちらは、下記グラフの動きで進捗の雰囲気を確認できます。Debian9は2017年6月にstableに昇格しており、そこからの動きです。深緑の線が落ち着いてきたら、Debian10がstableになると推測できます。
https://bugs.debian.org/release-critical/
CentOS8とDebian10、どちらが先にリリース or stableとなるでしょう?いろいろと楽しみでもあり悩ましいことでもあります。
なお、確定ではないようですが、CentOS8、Debian10とも、新規インストールではデスクトップマネージャに「Wayland」が採用されるとのことです。しかし、仮想マシンではまだ「Xorg」を使っている方が良さそうです。前バージョンからのアップグレードならば、Waylandは入らないと思います。
物理ディスクを仮想ディスクとして認識させる方法は、下記で検索すれば情報源には困らない。
https://www.google.com/search?q=vboxmanage+rawdisk
例えば、下記のコマンドによって物理ディスクを仮想ディスクとして見せるテキストファイルを生成できる。物理ディスクはSATA接続でもSATA-USB変換接続でも構わない。これを使った仮想マシンは、起動も早い。
cd C:\Program Files\Oracle\VirtualBox VBoxManage.exe internalcommands createrawvmdk -filename C:\temp\rawdisk.vmdk -rawdisk \\.\PhysicalDrive1
※ コマンドプロンプトは「管理者として実行」で起動すること。物理ディスクを使う場合、VirtualBox自体も「管理者として実行」で起動すること。
この手法を使って、私は下記のように利用している。
ホスト=Windows10、VirtualBoxゲスト=Linuxとしている開発PCは多いが、ネットワーク系の調査支援でLinuxをホストで動かしたい!というシーンがよくある。そんなとき、PC起動時に「F7」か「F11」を押しBIOSメニューで起動ディスクを選択することで、普段はゲストOSとして利用しているLinuxを、ありのままホストOSとして利用できる。
古いLinuxサーバの本体は処分し、HDDはそのまま別のPCに挿入。VirtualBoxで上記のマウントを実施し、元のサーバのまま運用を継続。
そもそも私は仮想ディスクを信用していない。リリース作業でddのようなプリミティブなコマンドを使うシーンでは、仮想ディスク上では作業を行わないようにしている。
これをやっていいのは、有識者かつ個人の趣味レベル。さもなくば、いろいろな意味で危険なので、素直にWindows10 Proへアップグレードしましょう。Windows10 Proならば、Windows10 Home、Linux、スマホ等から比較的安全かつ安定的にリモートデスクトップ接続が可能です。
Windows10 Homeへリモートデスクトップ接続するには、rdpwrapで潜在的なWindowsの機能を呼び起こせば良いのだが、Windows Updateした後にアクセスできなくなることがよくある。こんなとき、google先生に普通に聞くと情報が多すぎるので、直近期間を指定して検索するか、またはgithubの掲示板の英語をこまめに読む。
今回は下記投稿による救済がヒットした。rdpwrap.iniを更新するたけだが、中身は全く理解していない (^^;)
https://github.com/stascorp/rdpwrap/issues/763
https://github.com/stascorp/rdpwrap/files/3138022/rdpwrap_corrected_single_10.0.17763.437.zip
rdpwrap.iniが上書きできないときは、「Remote Desktop Services」を一旦停止してから上書きすると良い。
備考:
・この処置を実施する前にUltraVNCを使ってみたが、何かいまひとつという感じだった。
・Ubuntuからのリモートデスクトップ接続には「remmina」を使用している。