双発電脳 と USB3.0 UASP プロトコルオーバーヘッド

NUMAノードの違いで、なんじゃこりゃぁ?というくらいの差が出てしまいました。ある程度想定していたとは言え、筆者の予想を遥かに上回っておりましてこんなに違うなら今までのUSB3.0検証は速度や負荷に付いて全てやり直しですorz

 この件に関しては Interrupt-Affinity Policy ツール が活躍しそうですが、このツールはNUMA対応が本格的に成る前のVista世代のツールなのでうまく動くかこれから検証してみます。->エラーが出ますがデバイスとコアの紐付け設定は(完全では有りませんが)機能します(後述)。
 というかWindows7/8世代では自動的に最適なスケジューリングがされる様に成っているだろうという先入観が有りましたが、個別にデバイス毎にNUMAノードを手動で設定する必要が有るとは思いもよりませんでした・・・


 下の二つのスクリーンショットを速度とCPU負荷の両面からみますと別物か?と思うくらいの差が出ている事に気付くと思いますが、二つの条件の違いはNUMAノード0で実行したか1で実行したかの違いしかありません。判り易く言えば実行するコアの位置を変えて2度実行しただけです。2番コアと8番コアで4K-QD32では最大34%もの速度差が出ています。この30%以上もの差は何度計測し直しても埋める事の出来ないものでした。検証環境の詳細は記事の最後に記載しております。

 デバイスドライバ・ワーカスレッドと別ノードでCrystalDiskMarkを実行した場合
Renesas_D720200_4KQD32_0FILL_HOSTNODE0_CDMNODE1_C.png

 デバイスドライバ・ワーカスレッドと同一ノードでCrystalDiskMarkを実行した場合
Renesas_D720200_4KQD32_0FILL_HOSTNODE0_CDMNODE0_コントローラをノード0にのみ接続_C
問題は、デバイスと同一か否かではなく、デバイスドライバのワーカスレッドらしきスレッドとアプリのスレッドが同一ノードか否かが重要だという事です。何を言ってるのか判らないかも(ryしれませんが、下の表を参照下さい。

 デフォルトのままでは、ドライバ・ワーカスレッドらしきスレッドはデバイスの位置とは無関係にランダムなノードで実行されてしまうので最速の結果を出そうとすると追いかけっこに成りがちです。
NUMA_DEVICE_AFN.png

 そこで、追いかけっこを防止するために、初めにドライバ ワーカースレッドのNUMA nodeを固定します。冒頭のInterrupt-Affinity Policyツールを使ってデバイスが接続されたNUMA nodeの特定コアにデバイスの割り込みを手動で明示的に紐付けします。これによりドライバのワーカスレッドがデバイスと同じNUMA nodeで実行される様に固定出来ます。自動設定(IrqPolicyAllCloseProcessors や IrqPolicyOneCloseProcessorなど)は筆者の環境では機能しませんでしたが手動でコア固定(IrqPolicySpecifiedProcessors)で設定すると機能しました。
USB30_NUMA_node_affinity.png
これらの設定を行う事で、最適な状態で計測出来そうです。(実際、今までより平均的にみて高速かつ低負荷に成りました。)
このツールは操作中にエラー(Registry value for affinity mask has unexpected type)が時々発生しますが無視して継続しました。このエラーはOS起動時に作成されるレジストリ上のログの型がVista世代とWin7以降で異なる事に起因する様で、実害は無い様です。(MSサポート談
このエラーが出る場合の対処方法は、下記のバッチを作り InterruptAffinityPolicyツールを利用する直前に1回だけ実行します。OSをリブートしますとログが上書きされる為、リブート後は再度バッチを実行して下さい。


@ECHO OFF
SETLOCAL ENABLEDELAYEDEXPANSION
SET VNAME=TargetSet

FOR /F "tokens=1,2,3,*" %%a in ('reg.exe query HKLM\SYSTEM\CurrentControlSet\Enum /s /v %VNAME%') DO (
IF /I "%%a" EQU "%VNAME%" (
IF /I "%%b" NEQ "REG_BINARY" reg.exe delete "!_key!" /v %%a /f
) ELSE (
SET _key=%%a %%b %%c %%d
)
)


下のグラフは上記の設定を行った上で更にCrystalDiskMark本体スレッドを同一のNUMA nodeに固定し、3回:100MB:0Fill設定で5回実行(つまり合計3x5=15回測定)した平均値を元にグラフ化しています。
CDM_InterruptAffinityPolicy_1台_2
全体的にみて速度が安定して底上げされた感じですが傾向としては以前の結果と同じです。傾向が以前の検証と同一でしたので同時実行などの時間の掛かるものは再検証する予定でしたが中止する事にしました。

以下は、速度とCPU負荷以外に付いて比較した表です。
USB30card.png
余談ですが、USBの規格に則って段階的な電流調整をちゃんとしている製品は、これだけ(7つ)並べて Made in Japan の BUFFALO IFC-PCIE2U3 しか無いのは少し悲しい現実ですね。

NUMAでの割り込みやデバイス接続位置については別の記事も参照下さい

以下、以前の記述


 USB3.0 はプロトコルオーバーヘッドと通信速度の相乗効果で結果的にCPU負荷が高くなってしまうのが現状の様です。

例えば、このスクリーンショットはHIGHPOINT RocketU 1142Aの4個あるUSB3.0ポートにSSDを4台接続してCrystalDiskMarkで4台同時に4K-QD32の負荷を掛けた時のCPU負荷です。概ね右側の4コアがドライバ・ワーカスレッドらしき負荷、左側の4コアがCrystalDiskMark本体のCPU負荷です(タスクマネージャにてコアとCDMプロセス間の関係設定をしており、ドライバ・ワーカスレッド負荷らしきものはスケジューラによって自動的に分散されています)。但しシーケンシャルアクセスではCPU負荷がほぼゼロです。
HIGHPOINT_4台同時

 プロトコル間の変換処理をUSB3.0の速度にあわせてCPUが行う為、高速な変換処理が求められ、結果として高速転送=高いCPU負荷となって現れるのだと思います。この現象はSATA3世代のSSDの様にランダムアクセスが高速なデバイスで顕著に成ると思われます。つまり高速なランダムアクセス=それだけプロトコル変換を多量に処理する必要が有る。という事に成るかと思います。逆にシーケンシャルアクセスの様にデータサイズに対してプロトコルヘッダが少ないケースではCPU負荷がゼロに等しい状況ですから単純なデータ転送中には転送量に対して相対的にプロトコルヘッダの量が少ない=プロトコルオーバーヘッドが殆ど発生していないと思われます。

 但し、これはCrystalDiskMarkもしくはファイルシステム自体の限界なのかもしれません。
 例えば、これは19号機のシステムドライブでCrystalDiskMarkを実行した時の4K-QD32のCPU負荷ですが8番目のコアが100%に張り付いています。この負荷はCrystalDiskMark本体ですから、CrystalDiskMark本体プログラム自身(とシステムコール=ファイルシステムやドライバ・ワーカスレッド)がボトルネックに成っています。
CDM_CPU_NO19.png

 CPU負荷を低減する目的で高性能なNICを選択する事が有りますが、NICの現状は一般には1Gbitかつ使い切っていませんから、USB3.0の5Gbitと比較して5倍以上も低速です。その1GbitのNICですらCPU負荷を気にしてプロトコルオーバーヘッドの低減策がとられているくらいですから、USB3.0の5Gbitの帯域がいかにCPUにとって負荷に成るかは容易に想像出来ると思います。

 筆者は今まで USB3.0 の検証(1,2,3,4,5)を進めてきた中でCPU負荷を見てきましたが傾向としてUSBポート数ではなくホストコントローラ1個に付き1つのシングルスレッドで動作するドライバ・ワーカスレッドが対応しているのがWindowsでは一般的な様です。例外的にTexasInstruments社のTUSB7340用ドライバはCPU負荷が非常に低かったので何らかのハード支援の仕組みが有るのではないかと思っています(後ほどデータシートを見てみます)(但しTUSB7340でもWindows8の標準ドライバではドライバ・ワーカスレッドのCPU負荷が高かったので仮にハード支援が有るとしてもMS製ドライバは汎用的に作られておりTIのハードを活かしきれていない可能性が有りそうです)。

 ホストコントローラが複数有る場合は、コントローラの数だけドライバ・ワーカスレッドが立ち上がり負荷が分散され、言い換えるとホストコントローラが1個の場合は、シングルスレッドのドライバ・ワーカスレッドが全てのUSB3.0転送のプロトコル変換を(USB3.0の高速転送にあわせて)高速に処理する事に成ります。
 この事はシングルスレッドのドライバ・ワーカスレッドによるプロトコル変換処理がボトルネックに成り得る事を意味していますので、CPUクロックやCPUアーキテクチャが関係してきそうです。後ほどCPUアーキテクチャの違いによるUSB3.0プロトコル変換処理の負荷状況を比較してみます。

 加えて、今回の記事の主題ではブログタイトルにも成っている双発電脳=デュアルソケットでの負荷を見てゆきます。永らくUSB3.0の検証を重ねてきて、ここでようやく筆者らしい変態ぶりを発揮出来そうですが、主にNUMAでホストコントローラの接続位置とCPU負荷がどの様に関係してくるか(もしくは全く関係していないか?)を検証してみようと思います。はっきり言ってNUMAでUSB3.0は誰の得にも成らない検証作業ですが、延々と真剣に取り組んでみます。

 検証を進めつつ記事を追記してゆきます。

検証環境1:17号機
DSC02089.jpg
まず、この2つの異なるノードに直結されたスロットを使い、USB3.0では基準的な位置付けのNEC(現:Renesas)製μPD720200を採用したBUFFALO IFC-PCIE2U3を接続して測定し、その結果を基準点として、検証作業を進めようと思います。
DSC02093.jpg
このカードは近年では珍しいMade in Japanです。
DSC02090-3.jpg
このカードは部品点数が多く贅沢な作りで(部品点数が多い事だけが必ずしも良い訳では有りませんが)精密かつ丁寧な作りで好感が持てます。例えば過電流保護に使われている電子部品は他社製品では抵抗値が高い旧式のポリマーPTCサーミスタが使われている事が多く、接続したデバイス側での電圧降下の主要原因に成っていますが、BUFFALOのIFC-PCIE2U3では高価な積層PTCサーミスタが利用され抵抗値が低減されデバイス側で起きる電圧降下を緩和しています。こういった細かな配慮をしている事をBUFFALOは宣伝していませんが、それがMade in Japanでもあるように思います。(但し、同じBUFFALOでも玄人志向ブランドの製品には旧式のポリマーPTCサーミスタを使った製品を多く見掛けます。)
DSC02090.jpg

今回の検証で利用したUSB3.0カード
DSC02098.jpg
※SilverStoneのSST-EC04はVbusに過電流保護回路とバックアップコンデンサを追加・交換しました。
※玄人志向USB3.0F-P7-PCIeはVbusのバックアップコンデンサを大容量品に交換しました。

補助電源はSATA電源に統一されつつあるとは言え、各製品バラバラですから、この様に延長ケーブルも適宜自作しております。(作り過ぎて赤と黒のコードが無くなってしまいましたorz)
DSC02101.jpg
関連記事
スポンサーサイト

コメントの投稿

非公開コメント

プロフィール

DualSocketTheWorld

Author:DualSocketTheWorld
自作を始めて20台目くらいになりますが、最初からデュアルソケット限定(始めた当時はデュアルスロット)で自作しており、近年になってAMD K6を試したくなりSocket7でK6-2+のシングル構成で組んだのがシングル初です。

シングルマザー(含:シングルソケットマルチコア)や4ソケット以上の自作は基本的にしませんし、メーカー製PCの改造も基本的にはしません(ノートPCのSSD化くらいはしますが・・・)

基本路線はワークステーションと呼ばれる分野での自作で、OSもWindows系であればProfesionalが主な対象に成ります。

ゲーマーの様なOverClockは行わず、WS路線としてハイエンドCPUとハイエンドGPUの組み合わせで定格或いはDownClockで発熱を抑えつつ、その時のアーキテクチャに置いて爆速かつ静音を目指し、30年以上の長期に渡り稼動状態をキープする事を目指します。

※基本的にリンクフリーです。どこでも自由にどうぞ。

※画像は時々変ります。

※お決まりの文章ですが、改造は個人の責任で行ってください。ここに記載された情報は間違いを含んでいる可能性が有り、それを元に製作や改造などをして失敗しても筆者は一切責任持てませんので悪しからず。

筆者略歴:
小学生時代にゴミ捨て場で拾ったジャンクテレビ数台を分解して部品を取り出し真空管アンプを自作、中学生時代にPC8801mkⅡsrでZ80アセンブラを始める。社会人になって初のプログラムは弾道計算、後に医療系・金融系プログラマ~SEを経て100~200人規模プロジェクトのジェネラルマネジャを数年経験、独立して起業。現在は不動産所得で半引退生活。
(人物特定を避ける目的で一部経歴を変更しています)

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
アクセスカウンター
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR