【その他】リモートデスクトップでrdpファイルにselectedmonitorsの記述をしてもうまく動かないときの確認点 



  Windowsのリモートデスクトップですが、実はマルチモニター環境で特定の画面だけにまたがって全画面表示する、という機能があります。この機能を使ってとあるVMで作業するときに「1枚の全画面だと微妙に使いにくいけどマルチモニタすべての画面をリモデに使いたくない」という要件を満たすべく2枚の画面だけを使うようにしていました。

https://www.hanselman.com/blog/how-to-remote-desktop-fullscreen-rdp-with-just-some-of-your-multiple-monitors
https://qiita.com/yusuke-sasaki/items/5f70dc266caf13021838

 先に結論を書くと、 RDPで複数画面が使えない!というときは、使いたいディスプレイ同士が0pxで隣接しているかを確認する必要があります。以下、検証のメモです。


 実際のモニターのセットアップはこうなっています。グラボの出力順を考慮していないのでぐちゃぐちゃになっていますが、この中から5,6を使ってRDPを全画面表示する、ということをしていました。




 今までこれは動いていたのですが、モニターのつながっているグラボの出力端子を入れ替えたタイミングで画面をまたがっての表示が動かなくなってしまいました。 mstsc /lで調べてみると、端子が入れ替わったことによってモニターのIDが変わっていたので、IDを確認してrdpファイルに書かれている順番を入れ替えれば動くだろう、と思いました。しかし、若干の移動はあったもののIDは大きく変わっておらず、何をやってもモニタをまたがって全画面表示ができずプライマリモニタだけ全画面で表示される挙動を示しました。

 よくわからないので一度マシンを再起動し、もう一度mstsc /lをすると今度は何故かモニターIDが大きく変わっていた(1,3,10,11,12,13から0,1,2,3,4,5になっていた)のですが、それを直しても動かず、色々検証すると下記設定の赤字0,2の2画面表示と5,3の2画面表示は問題なく動き、なぜか5を含むと動かなくなるということがわかりました。




 検証に使った最低限の要素だけ含めたrdpファイルは以下になります。

## NG ##
full address:s:VM1
use multimon:i:1
selectedmonitors:s:4,5
dynamic resolution:i:0


## OK ##
full address:s:VM1
use multimon:i:1
selectedmonitors:s:0,2
dynamic resolution:i:0


 プライマリモニタがRX7900XTXにつながっていることもあり、最初はRadeon仕草かと思いましたが、 mstsc /lの値をよく見るとmstsc側ID(画像赤文字)の5の起点座標がおかしい事に気が付きました。この場合、0,0から3839,2159が4の値なので5が3840から始まらないといけないのですが、なぜか3853となっており、赤字4と5の間に13ピクセルの隙間があるいうことがわかりました。

 カッコ内部の値はそれぞれプライマリモニタ(この場合は赤字の4)の左上を0,0として右下に向けて座標がプラスになり、プライマリモニタより左にモニタがあればxはマイナスに、プライマリモニタより上にモニタあればyがマイナスになります。

 Windowsの仕様として隣り合うモニタ同士はどこかでくっついていないといけないのですが、赤字5は赤字3とくっついているという扱いになり、4と5は13ピクセル離れている、という認識になっているようです。出力端子を入れ替えたのがちょうど赤字の5にあたるものだったのですが、Windowsで画面の位置を移動したときにそれがズレたようです。わかるかそんなモノ…。

 離れてるのであればマウスの移動もできないのではと思いましたが、ある程度の加速度があると多少の隙間を乗り越えて隣のモニタに行けるようです。逆に、隙間があるととてもゆっくりマウスを動かしてモニタの境界線をまたごうとするとブロックされます。密着しているとマウスカーソルの加速度が1px/sでも境界をまたげるようです。たまに感じた違和感はこれだったのか…。




 ディスプレイのスナッピングとの格闘の末、最終的に一回り小さい赤字の1以外は0pxで整列できたのですが、どうしても最後の1つが完全密着になりませんでした。1の値は1279,ー1440,3840,ー1になるべきなのですが、Windowsのディスプレイ設定は2辺と隣り合うことを想定していないのか、赤字の3の左辺、もしくは4の上辺のどちらかにしかスナップせず、逆にどちらかにスナップすると絶対にもう一方は合わないという動きをしていました。

 ただ、赤字の0,2,4,5の横一列は整列されたので、当初赤字4,5の2画面でリモデが使えないという問題は解決しました。現状、赤字の1,3を使って画面をまたいでリモデをする、ということができませんが、このパターンはないと思うので諦めました…。座標を使ってディスプレイの場所を指定できる方法があればいいんですが…。



 変な環境でディスプレイを出力していてRDPで複数画面が使えない!というときは、使いたいディスプレイ同士が0pxで隣接しているかを確認する必要がある、という、ほんとに使い所のないナレッジを得たのでここに供養します。


[ コメントを書く ] ( 111 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 2.9 / 68 )  |  
【Monitoring】 ZabbixからESXiホストに刺さってるMegaRAIDの状態をLLDで動的に取得して監視する 
 個人でESXiを動かしていると、何かとLSIのRAID情報を取得したいと思うことがありますが、LSAではなくて既存のZabbixからデータを取得したいと思うことがあります。ありますよね(同調圧力)。
 何かいい方法がないかと見ていたらstorcliがjsonでデータを出力できることに気がついたので、ZabbixのLLDと組み合わせていい感じにデータを監視する方法を作りました。先にテンプレートのJSONを置いておきます。

Template_LSI-storcli.json


 storcliが動けばLinuxであっても情報を取得できるので、agentのsystem.run形式で作ったものも同梱しておきます。storcliの実行にroot権限が必要になるので、storcliにスティッキービットをつけたりsudoを許可したりagent自体をrootでうごかしたりしていい感じに対応してください。
 system.runは悪だ!!!!!という方は、最終的にjsonが取れればいいので、userparameterにしたりrootのcronでstorcliを実行して結果をテキストデータとして出力してログ監視するなど、linuxであればやりようはいくつもあるのでいい感じに工夫してください。
 まあ、linuxでエージェントが入っているようであれば/var/log/kernelなどをmegaraid_sasといったようなキーワードで監視していれば大体のイベントが取得できますが…。

 ESXi用のテンプレートはSSHで接続してstorcliの実行結果を取得するので、Zabbix-agentが入っていないLinuxを監視したい場合にも使えます。

前提条件


 利用するにあたり、以下の前提条件が必要になります。

Zabbixのバージョンが6系であること
監視対象上でstorcliが動かせること
作成したLDに対して名前がついていること
ssh接続が有効になっていること
ESXiホストの/etc/ssh/sshd_configのPasswordAuthentication が yesになっていること


 注意点としては、LLDとJSONのクエリの関係で、作成した論理ディスクに対して名前が必要になります。デフォルトではついていないので、storcliで監視対象全てで被らない一意な名前をつけてあげてください

/opt/lsi/storcli/storcli  /call/vall show all #一覧を確認
/opt/lsi/storcli/storcli  /c0/v0 set name=myhost01-boot #/c0/v0に対して名前を付ける


 ESXi側のSSHに関しては共通鍵認証でもいいですが、テンプレートの変更が必要なのでそのへんの設定は今回は省きます。デフォルトのkeyboard-interactiveになっていても動きそうな気がしますがテストしてません。
 また、テンプレートの形式がZabbix6形式になっているので4系では入らない気がします。LLDのためにJSONpathとカスタムスクリプトでJSを使っているので、これを元に一から作る場合であっても、Zabbix側のカスタムスクリプトでJSの拡張がされていないと動かない気がします。

 いずれにしても、4系の環境がもうないのでテストしてないですが、JSONpathは4系でも使えたはずなのでなにかのヒントにはなるかと思います。

利用方法


 まず、Zabbixに監視するためのホストを作ります。ESXiの場合はSSHで接続するので、インターフェースは参照しないので127.0.0.1のままでOKです。ホスト名だけ入れてください。



 次に、マクロに色々仕組みます。利用しているマクロは以下になります

{$IP} 接続先IP
{$PASS} SSHの接続パスワード
{$STORCLI} Storcliの配置先 ESXiデフォルトは/opt/lsi/storcli/storcliのはず
{$USER} SSHの接続ユーザ




 今思うと{$IP}はホスト作るときにIPで作って{#HOST.IP}でも良かったのでは??という気がしますが、作ってしまったのでそのままにします。また、PASSについてはデバッグが終わったあとであればSecret textに変更可能ですが、最初はクリアテキストでデータが取れるかを見たほうがいいです。

 作成したホストに今回のテンプレートをリンクさせ、LD Data from StorcliExecute nowで実行します。正しく設定されていれば、LLDが発動してアイテムが増えるはずです。LDが増えない場合、上記の制限事項にある手順のstorcli /cx/vx set name=uniquename で名前をつけたか確認してください。Latest dataでデータが取得できているのにLDが増えない場合おそらくこれが原因です。
 同じくPD Data from Storcliを実行すると、刺さっている物理ディスクの一覧が取得できると思います。

 Latest dataが取れない場合、ZabbixからESXiにSSHが届くか、storcliのパスが合っているかなどを確認してください。

制限事項


 物理ディスクの監視ですが、ディスク、HBAのファームウェアのバージョンによっては取得できない項目があります。BBM Error countShield State Countなどはある程度のクラスのディスクでないと値を持っていないので、ディスクによっては取得できないかもしれません。その場合は取得不可のマークが付きますが、影響がないのでそのままにするかLLDで作成されたアイテムから監視の無効化をしてください。




 また、物理ディスクの監視のために実行しているstorcli /call/eall/sall show all jで応答するJSONがかなり大きいため、搭載ディスク本数が24本などの巨大なマシンの場合はうまく取れないかもしれません。

 Zabbix6系ではTEXT型アイテムの場合、history_textテーブルに格納され、使っているDBがMariaDBであればmediumtext型で格納されるため1回のデータ取得で16MBまでは入りますが、使っているDBの種類によっては入り切らない可能性があります。参考までに、ディスクを8本搭載したマシンでstorcli /call/eall/sall show all jを実行すると22KBのJSONが出来上がります。

 調べた限り、Zabbixは1つのセッションで1GBくらいのデータを流せるようなので、おそらくSSHからのデータ取得で問題になることは少ないかと思いますが、場合によってはタイムアウトの時間を伸ばす必要があるかもしれません。 

 storcli /call/eall/sall show all jの結果については依存アイテムを分解するために実行しているだけなので、Zabbixが6系であればヒストリを「Do not keep history」にしてもLLD分解後のデータ取得は可能です。
 もともとデバッグのために1時間しか保持していませんが、コマンド実行に問題がなさそうであればstorcliの履歴については取得しない設定でも問題ないです。

→テンプレートの微調整の際にデフォルトではstorcliの実行結果を保存しないようにしました。storcliのコマンド実行結果を眺めたい場合は PD Data from Storcli のアイテムヒストリをnoneから適宜変更してください


技術的内容(うらみつらみ)


 今回、JSONとLLDを使うにあたってかなり多くの問題にあたりました。まず1つめはstorcliの返すJSONの作りが悪すぎること、そして2つめはZabbix側のJSONの処理がイケてないことです。両方じゃねーか!!!

ZabbixのJSONの扱いが微妙


 ZabbixでJSONを扱うときに2つの問題がおきます。まず1つ目は、LLDでJSONを扱う場合、見つかったキーが["LLDNAME"]とダブルクオートとブラケットに囲まれた状態で取得します。中身だけ見つけてくれ…と、せめてどうにか値に対してtrimやiregsubなどが使えないか試したのですが、どうやらここをどうにかする方法はないようです。

 そのため、アイテム名を整形するためにTemperture of {{#MR_PD_NAME}.iregsub("\[\"(.*)\"\]", \1)}というような正規表現をところどころで書く必要がありイケてないです。
 LLDで見つかったアイテムのキーについてもmrstat.pd.temp.["[\"/c0/e252/s0:WDC WD1005FBYZ-01YCBB1:WD-WMC6M0F4M8WN\"]"]というような状態で入ってしまうのですが、どうせこれは他では使わないしもういいや…と諦めました。

 2つ目は、LLDを実行するときにJSONから複数の値が見つかった場合、それぞれ[{"key": "value"},{"key": "value"}]で返答する必要があり、["value","value"]だとイテレータが動いてくれないという点です。
https://www.zabbix.com/forum/zabbix-help/419391-utilizing-jsonpath-to-setup-an-lld-macros
 これもハマりましたが、上記のスレッドのカスタムスクリプトに助けられました。なおしておいてくれ~~~~~

storcliのJSON構造がカス


 storcliのJSONの構造で苦労したのは物理ディスクの応答内容がカスなことです。一例としては以下のようになります

{
  "Controllers": [
    {
      "Response Data": {
        "Drive /c0/e252/s0": [
          {
            "DG": 0,
            "DID": 14,
            "EID:Slt": "252:0",
            "Intf": "SATA",
            "Med": "HDD",
            "Model": "WDC WD1005FBYZ-01YCBB2",
            "PI": "N",
            "SED": "N",
            "SeSz": "512B",
            "Size": "931.000 GB",
            "Sp": "U",
            "State": "Onln",
            "Type": "-"
          }
        ],
        "Drive /c0/e252/s0 - Detailed Information": {
          "Drive /c0/e252/s0 Device attributes": {
            "Coerced size": "931.000 GB [0x74600000 Sectors]",
            "Connector Name": "Port 0 - 7 x1",
            "Device Speed": "6.0Gb/s",
            "Firmware Revision": "RR07    ",
            "Link Speed": "6.0Gb/s",
            "Logical Sector Size": "512B",
            "Manufacturer Id": "ATA     ",
            "Model Number": "WDC WD1005FBYZ-01YCBB2",
            "NAND Vendor": "NA",
            "NCQ setting": "Enabled",
            "Non Coerced size": "931.012 GB [0x74606db0 Sectors]",
            "Physical Sector Size": "512B",
            "Raw size": "931.512 GB [0x74706db0 Sectors]",
            "SN": "WD-WMC6M0J95THT",
            "WWN": "50014EE0AF2FC003",
            "Write Cache": "N/A"
          },
          "Drive /c0/e252/s0 Policies/Settings": {
            "Certified": "No",
            "Commissioned Spare": "No",
            "Connected Port Number": "7(path0) ",
            "Cryptographic Erase Capable": "No",
            "Drive position": "DriveGroup:0, Span:0, Row:0",
            "Emergency Spare": "No",
            "Enclosure position": "1",
            "FDE Type": "None",
            "Last Predictive Failure Event Sequence Number": 0,
            "Locked": "No",
            "Multipath": "No",
            "Needs EKM Attention": "No",
            "PI Eligible": "No",
            "Port Information": [
              {
                "Linkspeed": "6.0Gb/s",
                "Port": 0,
                "SAS address": "0x4433221107000000",
                "Status": "Active"
              }
            ],
            "SED Capable": "No",
            "SED Enabled": "No",
            "Sanitize Support": "Not supported",
            "Secured": "No",
            "Sequence Number": 2,
            "Successful diagnostics completion on": "N/A",
            "Wide Port Capable": "No"
          },
          "Drive /c0/e252/s0 State": {
            "BBM Error Count": 0,
            "Drive Temperature": " 32C (89.60 F)",
            "Media Error Count": 0,
            "Other Error Count": 0,
            "Predictive Failure Count": 0,
            "S.M.A.R.T alert flagged by drive": "No",
            "Shield Counter": 0
          },
          "Inquiry Data": "7a 42 ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00 00 00 00 00 20 20 20 20 57 20 2d 44 4d 57 36 43 30 4d 39 4a 54 35 54 48 00 00 00 00 00 00 52 52 37 30 20 20 20 20 44 57 20 43 44 57 30 31 35 30 42 46 5a 59 30 2d 59 31 42 43 32 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 80 00 40 00 2f 01 40 00 00 00 00 07 00 ff 3f 10 00 3f 00 10 fc fb 00 00 5d ff ff ff 0f 00 00 07 00 "
        }
      }
    }
  ]
}


 各情報について、なぜ変動する値がキーになっているのか、微妙に違うキーに値を入れるのやめろ、と言いたくなります。例えば、ディスクの温度とシリアルを取りたい場合のデータの位置は以下になります。

json.Controllers[0]["Response Data"]["Drive /c0/e252/s0 - Detailed Information"]["Drive /c0/e252/s0 State"]["Drive Temperature"] = " 32C (89.60 F)";
json.Controllers[0]["Response Data"]["Drive /c0/e252/s0 - Detailed Information"]["Drive /c0/e252/s0 Device attributes"].SN = "WD-WMC6M0J95THT";


 なぜ以下のようにしなかったのか…

json.Controllers[0]["Response Data"]["PhysDrive"][0]["Path"]= "/c0/e252/s0";
json.Controllers[0]["Response Data"]["PhysDrive"][0]["SN"] = "WD-WMC6M0J95THT";
json.Controllers[0]["Response Data"]["PhysDrive"][0]["Detailed Information"]["State"]["Drive Temperature Celsius"] = 32


 もともとディスクのシリアルと型番を元にクエリを投げて温度を取ろうと思い、上記のような構造であればJSONだけでクエリが完結したのですが、このような構造のためLLDのキーに色々仕込む必要がありました。
 内容としてはカスタムスクリプトに正規表現でパスを取り出すものを仕組み、LLDの名前として取得して、LLDのアイテムプロトタイプで正規表現で取り出す、という内容です。

 LLDのカスタムスクリプト

var array = JSON.parse(value)
var drives = []
for (var a in array) {
for (var ar in array[a]){
if ( ar.indexOf("Detailed Information") != -1){
prefix=ar.replace(/(Drive\s\/[\w\/]+)\s.*/,"$1");
path=ar.replace(/Drive\s(\/[\w\/]+)\s.*/,"$1");
detail=prefix+" Device attributes";
drive=path+":"+array[a][ar][detail]["Model Number"].trim()+":"+array[a][ar][detail].SN
drives.push(drive)
}
}
}

var len = drives.length;
var x = 0
output = "{ \"data\" :["
for (; x < len - 1; x++){
output += "{\"Name\": \"" + drives[x] + "\"},"
}
output += "{\"Name\": \"" + drives[x] + "\"}"
output += "]}"
return output


 上記のカスタムスクリプトでこのような名前が取れるので、これをLLDで見つかったディスクとして認識させます。




 そして、LLDのアイテムプロトタイプにて、JSONpathでデータを取得する際に.iregsub("\[\"([0-9a-z\/]+):.*\"\]", \1)}で一番最初のスロットナンバーの情報を切り出してJSONのキーに埋め込んでいます。

$.Controllers..["Response Data"]..["Drive {{#MR_PD_NAME}.iregsub("\[\"([0-9a-z\/]+):.*\"\]", \1)} State"]["Drive Temperature"]


 イケてねえ…。まあイケてないものをイケてない方法でどうにかしようとしているので汚くなるのは必然ですが…。

まとめ


 Zabbixは仕事でもプライベートでも使うことが多く、いろいろな意味で一番柔軟性が高い監視方法だと感じています。特定のログを検知しても水曜日の6-7時だけは検知を除外する、というような要求でも、Zabbixであればそれなりに複雑なトリガーの条件式で対応できますが、他の監視方法だとかなりキツイ、もしくはそんな方法はない、という事なりがちで、良くも悪くも使い込めば使い込むほど他のものが使えなくなります。

 Zabbixは以前の仕事でそれなりに使っていたつもりだったのですが、今回やった内容は全く知らず、「え、そんなことできたの…」という発見もかなりありました。Zabbixはパズルですが、どうにかする方法はあるのでみんなで沼に沈みましょう。

 おそらく、今回の方法ももう少しスマートな方法がある気がしますが、とりあえず動いたので参考にはなるかと思います。

追記:
 その後実際に役に立ってしまったので動作については問題ないと思います。また、storcliのデータについてはデフォルトではヒストリを取らない設定に変更し、ディスクのステータスの追加のデータを取るように変更しました。何が起きてるかを知りたいときには手動でヒストリの取得を有効にしてください。
 また、コントローラーが複数存在する場合に、2台目以降のコントローラーのデータが上手くパースできていない問題も修正しました。




[ コメントを書く ] ( 319 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 264 )  |  
【その他】BlogをホストしてるVMを新しくした 
 なんだかんだ長くこのブログも動いているのですが、中のOSが古くなってきたので新しくしました。もともとは物理マシンでDebian 6(の超初期版)が動いていたのですが、VM環境ができあがりつつあったのでイメージをddでVMに持ってきて、その後式年遷宮(新規VM作成後にコンテンツコピー)でDebian7に移行しました。その後dist-upgradeでDebian8までは持ってきたのですが、OSデフォルトのPHPのバージョンアップ等の絡みでそのまま塩漬けになっていました。

 しかし、7から移行した関係でApacheのバージョンが2.2のままだったので(果たして8になったと言えるのか…)いい加減新しくしたいと思っていたのですが、家で動いているZabbixも7から9に移行しようとして失敗したのでdist-upgradeはやめ、環境が古すぎてなんで入っているのかわからないパッケージやもはや使ってないDBなどもあり、この辺をきれいにする意味も兼ね、今年7月に出たDebian10の評価を兼ねてまた式年遷宮しました。

 ちなみにZabbixマシンもMySQLのダンプを吐いてまっさらなDebian9のVMにインポートし、Zabbix-server周りの設定だけよしなに変えて式年遷宮しました。MySQLからMariaDBに変わったり、昔から残ってるinitスクリプトとsystemdの関係がうまく行かなかったりしてdist-upgradeで色々つらい感じになりました。

 ただ、Debian10のマシンにそのままコピーだと(シンプルな作りのこのブログシステムであっても)いくつかPHP7で廃止された関数を使われていた関係で500が帰ってきてしまい、それを直したりデザインを少し変えたりしたらなんだかんだで丸2日くらいかかってしまいました。


 とりあえず表面上は動いているのですが、何が問題が出そうで怖いです…

[ コメントを書く ] ( 543 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3.1 / 813 )  |  
【その他】スマホが死んだ/USBハブ付きGibEケーブル買った 
 自分は1-2世代前の安くなった中古のスマホを買って適当なSIMを挿して使っているのですが、去年の2月くらいに買ったSOL25 (Xperia Z2)が車に轢かれて死にました。手元に来て享年1年でした。




 顛末としては、

雨が降っていたので、出ようとしたバスに駆け乗る→帰宅→1時間後、直前まであったスマホがないことに気がつく→Ggoogleのデバイスマネージャからもオフライン→駅前の交番までいき、遺失物届け出がないか確認→遺失物には来てないのでとりあえず紛失届を出す→帰り際、ちらっと見たら道端に転がっている見覚えのあるフォルム→死体発見→5分前に出した紛失届を取り下げ

 といった感じでした。 割と気に入っていたのにあまりにも悲しい別れでした。まあ、盗まれてデータ抜かれるよりはマシなので見つかってまだ良かったというべきでしょうか…

 発見当初は電源も入らない状態だったので、とりあえずUQMobileのSIMとマイクロSDを摘出したところ、マイクロSDは生きていたのですが、SIMはマイクロSIMが刺さる機種が手元になかったので生死が不明でした。
 手元のゴミ箱を漁ったところ、4000円だったのでとりあえず買ったSHL24が見つかったので、SIMを切って差し込み、動くかどうかだけみてみました。
 結果は、APN設定は必要でしたが、SIM自体はそのまま動いたので、しばらく代替としてSHL24を使う事にしたのですが、さすがに今となってはちょっと動作が厳しいです。

 その後、Zeonfone GoとButterfly 3(HTV31)を入手したのですが、ZenfoneはSIMサイズがマイクロなので 再度変換が必要になり、HTV31はVoLTE対応のSIMが必要(手持ちの物は非対応)になったので、どちらを使うにしてもそのままでは使えないのでしばらくはSHL24にルーターになってもらう必要がありそうです。。

 Xperia Z2の方は、バッテリへのダメージに依る爆発におびえながら、しばらく電源に繋いでいたところ電源は入るようになったので、いくつか欲しいデータがあったので何とか取得できないかあれこれしました。幸い?カスタムファームを入れていたので電源+VolDownでTWRPのリカバリシェルに入り、ADBドライバが通じたので何とかデータをサルベージで来ました。





 まあ、画面が見えないので多分リカバリシェルが立ち上がってるだろう、なのですが。。ちなみにリカバリ画面だとMHLケーブルを繋いでも何も出力されません。こういった事態に備えて何かしらの方法でリモート接続を出来るようにしておいても良いかもしれませんね…。



 閑話休題、最近のUltrabookのような薄型PCだとUSBポートが枯渇したり有線イーサネットポートが無かったりして不便なので、秋葉原PCネット地下の何とも怪しげなUSB3.0+GibE搭載ハブ?ハブ付きNIC?を買ってみました。




 前情報は何もありませんでしたが、開けてみるとKY-688というモデルで、中身はVIAのスイッチチップ+Realtek RTL8153という当たり障りのない構成でした。

 ネットワークパフォーマンス的には、iperfで940Mbps/上り下りが出て、USB3.0のスピードも200MB/s程度まで出ることは確認しましたが、手元にそれ以上速いデバイスがないのでどこで飽和するかは謎です。
 Surface3ProとL2的に繋がっているVM(AX3650S-48T4XW経由で10Gスイッチ接続)との計測結果です。

$ iperf -c Surface3Pro -i 10 -t 60
------------------------------------------------------------
Client connecting to Surface3Pro, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 172.20.1.66 port 60313 connected with 172.20.1.211 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 10.0-20.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 20.0-30.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 30.0-40.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 40.0-50.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 50.0-60.0 sec 1.09 GBytes 935 Mbits/sec
[ 3] 0.0-60.0 sec 6.57 GBytes 940 Mbits/sec


 クライアントとサーバを逆転しても変わらないので逆は省略

 RTL8153チップは最近のLinuxカーネルやWindows10ならそのまま認識できるので、軽作業用途には癖が無くておすすめです。ヘビーユースに耐えられるかは謎ですが。

以上です。



[ コメントを書く ] ( 726 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1542 )  |  
【その他】ごみスクリプト置き場 
 某所にいたときに不毛な作業を少しでも楽にしようと足掻いた時に作ったゴミを置いておきます。たまにこれをベースに何かを作ったりするので主に自分のためのメモですが。
 内容としては、Expectで複数サーバに対して同一コマンドをsuして実行するだけのゴミと複数のサーバから一か所にファイルをSCPで集めるか送るだけのゴミです。

もっと読む...

[ コメントを書く ] ( 2237 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1832 )  |  

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 進む> 最後へ>>