テガラ株式会社 ホーム > 新着情報 > 2019年6月の記事一覧

新着情報

2019年6月の記事一覧

海外製品調達ユニポス

2019.06.28

様々なDBに対応したデータベース管理ツール「Navicat」を追加しましたnew


ユニポスWEBサイトに、様々なDBに対応したデータベース管理ツール
Navicat のページを追加しました。


navicat_img.jpg

Navicat は、MySQL, PostgreSQL, MongoDB, MariaDB, SQL Server, Oracle, SQLite の
7種類のデータベースに対応したDB管理ツールです。
1つのアプリケーションから同時に最大7つまで(※)の
データベースへ接続が可能です (※ Navicat Premium の機能)。

また以下のようなクラウドデータベースにも対応しています。
Amazon RDS、Amazon Aurora、Amazon Redshift、Microsoft Azure、
Oracle Cloud、Google Cloud、Alibaba Cloud、Tencent Cloud、
MongoDB Atlas、Huawei Cloud


navicat_reseller_logo.jpg

テガラ株式会社はNavicatのメーカー認定リセラーです。
以下の関連ツールについてもお取り扱いいたします。
お気軽にお問い合わせくださいませ。


Navicat Monitor

エージェントレス方式のリモートサーバ監視ツール

Navicat Data Modeler / Navicat Data Modeler Essentials
概念データモデル、論理データモデル、物理データモデルの構築に適したデータベース設計ツール

Navicat Cloud
同期・共有ソリューション (Navicatのアドオン)

Navicat Essentials
データベース管理の基本的かつ必須の機能をもったNavicatのコンパクトバージョン


■商品の詳細、お問い合わせはこちら
Navicat | 様々なDBに対応したデータベース管理ツール
メーカー(PremiumSoft CyberTech Ltd.) WEBサイト


研究PC関連更新情報

2019.06.28

【記事】「Metashape」のクラスタ構成での処理速度測定と傾向検証 (後編)

metashape_report_title.jpg

先日公開を致しました前編の記事では、同じ仕様のマシン4台のクラスタ構成での「Metashape」の処理速度測定の実施とその傾向を検証しました。
その結果を元に、こちらの後編では「CPUのコア数優先」処理の傾向を検証します。

※本ページの記事は「後編」となります。前編記事はこちら



検証環境について

計測は、前回同様の下記クラスタノードをベースとした構成に、CPUのコア数を増やした仕様を1台、CPUノードとして追加し、実施しました。

クラスタノード
CPU Intel Core i9 9900K (3.60GHz/TB5.0GHz, 8C/16T)
メモリ 40GB
SSD 1TB S-ATA
GPU Geforce RTX 2080Ti × 1
LAN Onboard(1GbE)
OS Microsoft Windows 10 Professional 64bit
Metashape Ver 1.5.2.7838

追加したCPUノードは以下のスペックとなります。
CPUのコア数は2CPU構成で16コアとなり、2CPUのXeon仕様としては最上位クラスの定格クロックとTBクロックの構成となります。

CPUノード
CPU Xeon Gold 6144 (3.50GHz/TB4.20GHz, 8C/16T) × 2 (合計16コア)
メモリ 768GB
OS Microsoft Windows 10 Professional 64bit


処理内容について

今回行った処理はオルソ画像処理の一連のバッチ処理となります。
この処理においては、前編で使用したDollのサンプルデータですと少し負荷が低めのため計測結果の差が判別しづらかったため、以下のようなデータを弊社で用意し、使用しました。

metashape_report2_drone.jpg

処理内容は前回同様、①MatchPhotos ②AlignCameras ③BuildDepthMaps ④BuildDenseCloud ⑤BuildModel ⑥BuildUV ⑦BuildTexture を実施します。

計測方法としては、上記CPUノード構成のマシンをCPUのみを使用する設定でノードとして使用し、ノード処理の優先順位をHighestに設定しております。これで⑤BuildModel~⑦BuildTexture でのCPU処理はこちらのノードで計算されることになります。ただし、他の処理においてもCPUでも計算する場合にはこのノードに処理が割り振られておりますので、個別の部分では多少の差異がある点はご注意ください。

Metshape側の処理は以下のパラメーターでの実施となります。
Aligen Photos : Highest
Build Dense Cloud : Ultra High
Build Mesh : High field&High
Build Texture : Orthophoto

(今回はBuild Meshの処理がHighクオリティとなります。理由に関しましては後述します)


処理結果について

まずは①MatchPhotos~⑦BuildTexture までの一通りのトータル処理時間を計算した結果です。

クラスタ 1台 (RTX 2080Ti × 1) 4時間33分01秒
クラスタ 2台 (RTX 2080Ti × 2) 3時間45分45秒
クラスタ 3台 (RTX 2080Ti × 3) 3時間33分33秒
クラスタ 4台 (RTX 2080Ti × 4) 3時間31分35秒
クラスタ 4台 (RTX 2080Ti × 4) + CPU Node
3時間17分09秒
比較用単体システム (RTX 2080Ti × 2) 4時間16分33秒

※比較用単体システムのスペックについては前編をご参照ください


次に前編と同様に各フェーズについて検証します。
metashape_report2_img1.jpg
(Y軸=経過時間 : グラフが長いほど処理に時間がかかっている)

#単独システムの場合はログの出方が異なるため、上記のグラフには載せていません。


予想通り、⑤BuildModel~⑦BuildTextureの部分でCPUノードを追加した場合に大きな変化が見られました。同一ノードのみで実施の場合は前回同様に処理時間は横並びですが、CPUノードに処理をさせた事で差が発生しました。⑤BuildModelと⑦BuildTextureに関しては処理時間が短くなり、逆に⑥BuildUVに関しては長くなっています。

ここで改めて今回のクラスタノードとCPUノードのCPUを比較します。

クラスタノード
CPU Intel Core i9 9900K(3.60GHz/TB5.0GHz 8C/16T) ×1

CPUノード
CPU Xeon Gold 6144 (3.50GHz/TB4.20GHz 8C/16T) × 2 (合計16コア)


クラスタノード側の方が単独コアの動作速度は速く、CPUノード側の方がコア数が多いといった関係になります。ここから、⑤BuildModel 及び ⑦BuildTexture時間はコア数が有効に働く処理であり、⑥ BuildUVは単独コアの動作速度が重要であるということが推測されます。

また、④BuildDenseCloudの処理時間については、4ノード(クラスタ4台)の結果よりも時間がかかっています。これはGPU処理よりも処理速度が遅いCPUにCPUノードが増えた分だけ処理が分散されてしまい、GPU搭載のクラスタノードは処理が終わっていても、CPU側の処理が終わらず、その処理が終了するのを待ってしまっていた結果と推測されます。実際にはこの処理はログ上では複数の処理に分割され (今回の検証においては106~108 程度)、処理が終わったら次の処理...と渡されていくため、分割された最後の処理が終わるタイミングによっては逆に処理時間は速くなる可能性も考えられます。
なお今回のクラスタノードは同一のCPU/GPU構成ですが、異なるCPUやGPUでの構築をされた場合、速度の遅いCPUやGPUなどがこの処理でボトルネックになる可能性があるということが考えられます。

最後に、「処理内容について」の項目で挙げました、Build Meshの処理をUltra Highで実施しなかった理由については『実施できなかったため』となります。1クラスタあたり40GBのメモリでは今回のデータを処理するのには足りず、処理が進みませんでした。

潤沢にメモリをもっているCPUノード構成 (768GB)の場合はUltra Highでも処理が可能でしたので、Build Meshに関してはノード1台に処理が集中してしまう関係上、その1台に十分なメモリが必要であると推測されます。


まとめ

以上、クラスタを利用したMetashapeの処理速度の検証結果となります。

前編・後編を通してのここまでのデータを元に検討しますと、④BuildDenseCloud処理まではクラスタ構成が有利ですが、それ以降の処理についてはあまり効果的ではないと言えそうです。

また、上記でも触れております通り、Build Meshなどの処理は結局の所、 1台のCPUで処理をする必要があり、その1台に十分なメモリ容量も必要となってきます。クラスタ構成を検討する場合でも、全体の処理として考えた場合に、メモリが足りない事により必要としている処理ができないという可能性がございますので、少なくとも1台は十分なメモリを積んだPCを用意していただくのがよろしいかと思います。

単独クロックの速いCPUを選択しても、搭載できるメモリ容量には上限がありますので、メモリ搭載量の面で見れば、Xeonシステムのほうが有利となります。そのため、単純に単独クロックが速いCPUがお勧めとも言い切れないところがあります。
※今回検証に使用したCPU (Core i9 9900K)は64GBまでのメモリに対応となります (2019年4月時点。将来のRevでは128GBに対応が予定されています)。

 

現状でMetashapeクラスタ構成を検討する場合、通常は個別で利用しているMetashapeを、大規模な処理が必要な場合に一時的にクラスタとして利用する使い方や、④BuildDenseCloud処理までの作業を行わせるサーバーファームとしての運用等が考えられます。

なお、今回の検証では速度計測をメインにおいておりましたので、すべて1ジョブのみで実施をしておりましたが、当然複数のジョブを実行することも可能です。この場合、処理がBuild Meshに入った時点で、計算している1台のマシン以外がフリーになった場合には次のジョブが走り始めますので、複数のジョブを投げて短時間で処理をさせるという用途でもクラスタ構成は有効であると思われます。


■ 2019年7月11日追記  : こちらの検証に利用したクラスタノードPCを事例として公開しました

海外製品調達ユニポス

2019.06.26

「STERLITECH 社製 フィルタ(無機膜)」を追加しました

ユニポスWEBサイトに、
STERLITECH 社製 フィルタ(無機膜) のページを追加しました。


 sterlitech_img.jpg
膜技術と精密ろ過技術を有する STERLITECH社の高性能の各種ろ過製品を
取り扱っております。

STERLITECH 社は、独自のマイクロ・サブミクロン領域の濾過に重点をおき、
個々のニーズに合わせてソリューションを調整、展開しています。
工場などで使用されることの多いメンブレンフィルターをはじめ、
シリンジフィルター、カプセルフィルター等、実験室規模のろ過に対しても、
製造基準・製品性能ともに満たしています。

処理時間短縮・分析効率・一貫した測定結果を得るために最適化された
ろ過製品は、さまざまなご用途で利用頂けるよう、
多孔性膜、孔径ポリマー、ガラス繊維、およびセラミック膜等、
数多くのラインアップがあります。

お問い合わせの際にはご希望の製品名や型番、URLなどをお知らせください。


【取り扱い実績のある製品の一例】

Filters
- Membrane Disc Filters
- Syringe Filters
- Cellulose Filter Papers
- Capsule Filters

・Polyester (PETE) Membrane Filters
- メンブレンフィルター 親水性ポリエステルトラックエッチ(PETE) -

PETEメンブレンの表面は滑らかで平らで、
薄い半透明の微孔質ポリエステルフィルムで作られており、
血液分析、顕微鏡分析、および一般的なろ過に最適です。

想定されるご用途:
- Precise General Filtration and Prefiltration (一般的なろ過 / 精密ろ過 / プレろ過)
- Removal of red blood cells from plasma (血漿からの赤血球の除去)
- Flow control of reagents through assay (アッセイによる試薬のフローコントロール) 等
※上記のほか、幅広い用途にお使い頂けます。


本ページでご紹介の製品は取り扱い実績のある製品の一例です。
この他の製品につきましても、お気軽にお問い合わせください。


■商品の詳細、お問い合わせはこちら
STERLITECH社 / メンブレン膜フィルター等のろ過製品
メーカー (Sterlitech Corporation) WEBサイト

>>全文を読む

海外製品調達ユニポス

2019.06.18

「FUTEK製 力測定センシング技術 関連製品」を追加しました

ユニポスWEBサイトに、
FUTEK製 力測定センシング技術 関連製品 のページを追加しました。


futek_products_img.jpg
FUTEK 社製のロードセル、トルク、圧力センサー、多軸センサー等の
力測定センシング技術関連製品 (センサーソリューション製品)を取り扱っています。
さまざまな業界向けに設計・開発されたこれらの製品は、
汎用性が高く、自動車・航空宇宙および防衛・農業・医療・製薬用途・工場・
ロボットシステム・材料および耐久性試験用途等、
あらゆるテクノロジー分野で使用されています。

充実した製品ラインアップがございますので、
お問い合わせの際にはご希望の製品名や型番をお知らせください。

お問い合わせの際にはご希望の製品名や型番、URLなどをお知らせください。


【取り扱い実績のある製品の一例】

load_cells_img.jpg
Load Cells -詳細
FUTEKのロードセルは、航空宇宙、医療、および自動計測プラットフォームで
使用されており、海底から火星表面までの幅広い試験環境実績があります。
具体的な活用例はこちらをご覧ください

-Load Button
-Load Cells
-Pancake Load Cells
-S Beam Load Cells
-Thru Hole / Donut Load Cells
-Tension and Compression Load Cell

・Miniature Threaded In Line Load Cell Model LCM300 Item No.FSH02702
・Miniature Threaded Tension and Compression Load Cell Model LCM325 Item No. FSH00671
・Jr. Miniature S-Beam Load Cell Model LSB200 Item No. FSH00102

futek_torque_semsor_img.jpg
Torque Sensor -詳細
FUTEKのトルクセンサーは、プロセス制御と監査に多用されています。
反作用、回転トルクセンサーのラインアップを兼ね備えるだけでなく
ほとんどの工業規格のアプリケーション要件を満たしています。
具体的な活用例はこちらをご覧ください

futek_pressure_sensor_img.jpg
Pressure Sensor -詳細
FUTEKの圧力センサは、小型化と出力オプションの2つの設計要素に
重点を置いており、さまざまなプラットフォームや環境に容易に統合できます。
また、FUTEKのUSBソリューションやデジタルディスプレイ等へも組み合わせでき
汎用性にも優れています。
具体的な活用例はこちらをご覧ください

futek_multi_axis_sensor_img.jpg
Multi-Axis Sensor -詳細
FUTEKの多軸センサーは、最大6成分(力とトルク)を正確に測定できます。
トルクと張力の2軸センシング、2軸ロードアームセンシングなど
さまざまな構成で利用できます。
FUTEK社のトルクセンシングの活躍の場は、自動キャッピングプレス、
ロボットアーム、風洞試験、クアドコプタープロペラテスト等幅広く
応用も可能です。
具体的な活用例はこちらをご覧ください

futek_instruments_img.jpg
INSTRUMENTS -詳細
センサー、ケーブル、デジタルディスプレイ、シグナルコンディショナー、
アクセサリー、センサー検証システム等もございます。

・Signal Conditioner (Amplifier) Model CSG110 Item No.FSH01449

futek_accrsories_img.jpg
Accessories -詳細
ロードセル、トルクセンサ等のケーブルアクセサリから
クレビスピン校正器具まで、多種多様なアクセサリーがございます。


本ページでご紹介の製品は取り扱い実績のある製品の一例です。
この他の製品につきましても、お気軽にお問い合わせください。



研究PC関連更新情報

2019.06.12

【記事】「Metashape」のクラスタ構成での処理速度測定と傾向検証 (前編)

metashape_report_title.jpg

弊社でも引き合いをいただく事が多いMetashape (旧Photoscan)ですが、実はネットワークを組む事でクラスタ構成でも処理ができるソフトとなります。
以前にはPhotoScanでのGPUなどにおける処理速度の測定を行った事がありますが、ではクラスタ構成にした場合はどのような傾向になるのか...という事を検証してみました。


検証環境について

今回のテストに使用したクラスタ構成は以下の環境となります。
下記システムを4台用意しまして、3台は完全にクラスタノードとして動作させ、
1台はMetashape用のServe兼ストレージサーバー兼ノードとしての検証となります。

クラスタシステム
CPU Intel Core i9 9900K (3.60GHz/TB5.0GHz, 8C/16T)
メモリ 40GB
SSD 1TB S-ATA
GPU Geforce RTX 2080Ti × 1
LAN Onboard(1GbE)
OS Microsoft Windows 10 Professional 64bit
Metashape Ver 1.5.2.7838

また比較用としまして、1台単独で動作させた以下 仕様のマシンでのデータも参考として表示します。

比較用単体システム
CPU Intel Xeon W-2155 (3.30GHz/TB4.50GHz, 10C/20T)
メモリ 256GB
SSD 1TB M.2
GPU Geforce RTX 2080Ti × 2
OS Microsoft Windows 10 Professional 64bit
Metashape Ver 1.5.2.7838


処理内容について

まずは、前回のテストでも利用したメーカー(Agisoft)が公開しているサンプルデータのDoll (Agisoft データダウンロードページ) で、①MatchPhotos ②AlignCameras ③BuildDepthMaps ④BuildDenseCloud ⑤BuildModel ⑥BuildUV ⑦BuildTexture の処理を実施しました。

photoscan_doll.jpg

※なお実施した処理は以下のパラメーターでの実施となります。
Aligen Photos : Highest
Build Dense Cloud : Ultra High
Build Mesh : Arbitray&Ultra High
Build Texture : Generic



処理結果について

以下がサーバーログで ①MatchPhotos~⑦BuildTexture までの一通りのトータル処理時間を計算した結果のグラフとなります。

metashape_report_img1-640x345.jpg

(Y軸=経過時間 : グラフが長いほど処理に時間がかかっている)

クラスタ 1台 (RTX 2080Ti × 1) 20分35秒
クラスタ 2台 (RTX 2080Ti × 2) 18分33秒
クラスタ 3台 (RTX 2080Ti × 3) 17分09秒
クラスタ 3台 + サーバー兼用 1台 (RTX 2080Ti × 4) 16分44秒
比較用単体システム (RTX 2080Ti × 2) 20分03秒


クラスタ1台での処理速度が少し遅いのが目につきますが、クラスタの結果を見た限りでは 台数に応じて速度が速くなっています。ただ、GPUの枚数による差が少なく見え、果たしてクラスタ構成処理の効果があるのか...?という疑問がでてきます。

そこで、上記の処理時間についてログを確認し、Metashapeの各フェーズと思われる部分の実施結果ごとにデータをまとめてみました。この結果が以下のグラフとなります。

metashape_report_img2-1.jpg
#単独システムの場合はログの出方が異なるため、上記のグラフには載せていません。

この分布から判断しますと前半の ①MatchPhotos~④BuildDenseCloud までの処理速度は、ある程度GPUやクラスタ台数のスケールを反映していますが、⑤BuildModel~⑦BuildTexture までについてはクラスタ台数によっての速度はあまり変わらないという結果になりました。
なお実際の検証時には計測中の負荷を確認していたのですが、⑤BuildModel~⑦BuildTexture のあたりの処理はすべて1台のクラスタノードでのみ実施されており、他のクラスタノードでは処理がされていないという状況が確認できました。

 
そしてもう一つ気になる点として、それぞれのフェーズにかかる時間にも注目する必要があります。
今回の計測では⑤BuildModel~⑦BuildTexture の時間が今回テストしたトータル処理時間の50%以上をしめています。

ここで最初に示した ①MatchPhotos~⑦BuildTexture までの一通りの処理時間を計算した結果のグラフを再度確認していただきたいのですが、本来であればGPUを2枚搭載したかなりのハイスペックであるはずの比較用単体システム(紺色のグラフ)ですが、実際には同じくGPU2枚のクラスタシステム2台(水色のグラフ)での処理よりも時間がかかっているという結果が出ていました。この原因を考えた場合に、比較用単体システムとクラスタシステムとの間でのGPU枚数以外のスペック差が、トータル処理時間の50%を占める⑤BuildModel~⑦BuildTexture の処理において、大きく影響しているのではないかと推察されました。

それを前提にスペック比較したところ、CPUにその要因があるように見受けられました。
改めて2つのCPUを比較して見てみます。

クラスタシステム
CPU Intel Core i9 9900K (3.60GHz/TB5.0GHz, 8C/16T)

比較用単体システム
CPU Intel Xeon W-2155 (3.30GHz/TB4.50GHz, 10C/20T)


クラスタ側のTB (Turbo boost)が 5.0GHzで動作するのに対して、単体システム側はTB 4.50GHzでの動作となっています。つまり⑤BuildModel~⑦BuildTexture については、CPUの単独クロックが処理速度に対して特に有効となるという推測が成り立ちます。


では⑤BuildModel~⑦BuildTextureを、今回の例より十分に多いコア数優先の処理 にした場合にどうなるのか...?という疑問が発生します。
この疑問については近日公開いたします"「Metashape」のクラスタ構成での処理速度測定と傾向検証 (後編)"でのオルソ画像処理の一連のバッチ処理の検証結果と共にご報告します。

■ 2019年6月28日追記  : 後編記事を公開しました!

■ 2019年7月11日追記  : こちらの検証に利用したクラスタノードPCを事例として公開しました

ページの先頭へ

月別アーカイブ

2019
7
6
5
4
3
2
1
2018
12
11
10
9
8
7
6
5
4
3
2
1
2017
12
11
10
9
8
7
6
5
4
3
2
1
2016
12
11
10
9
8
7
6
5
4
3
2
1
2015
12
11
10
9
8
7
6
5
4
2
1
2014
12
11
10
9
8
7
6
5
4
3
2
1
2013
12
11
10
9
8
7
6
5
4
3
2
1
2012
12
11
10
9
8
7
6
5
4
3
2
1
2011
12
6
  • TEGSYS 研究用・産業用PCの製作・販売サービス
  • テガラの研究開発向け海外製品調達・コンサルテーションサービス「ユニポス」