From the blog

MPI Benchmarking on Google Compute Platform Revisit

gce
Three years ago we visited Google’s IaaS service – Google Compute Engine (GCE) for its networking performance and Ryan posted the results in his blog post. Back then, the conclusion was that GCE instances were more suitable for a typical workload of hosting web services but there was still performance tuning space for HPC applications. Recently, we revisited the GCE’s instances with their latest offering again.

Benchmark Tools
To make the results somewhat comparable with the old ones, we’re still using the OSU Micro Benchmarks but with the latest version 5.3.2. And among all the benchmarking tools being offered, we pick two most critical ones: osu_latency for latency test and osu_bibw for bidirectional bandwidth test.

Test Environment
Operating System: Debian GNU/Linux 8 (Jessie)
MPI Flavor: MPICH3

Test Instances
Since we are testing the interconnection performance between VM instances, we want to make sure the VM instances we launched are actually sitting on different physical hosts so the traffic actually goes through the underlying network but not the host machine’s memory.
So we picked the biggest instance of each series:
n1-standard-32, n1-highmem-32 and n-highcpu-32

Test Results
For latency (in microseconds):

Instance Type Trial #1 Trial #2 Trial #3 Average
n1-standard-32 45.68 47.03 48.46 47.06
n1-highmem-32 43.17 43.08 36.87 41.04
n1-highcpu-32 47.11 48.51 48.17 47.93

(size: 0-bytes)
For bidirectional bandwidth: (MB/s)

Instance Type Trial #1 Trial #2 Trial #3 Average
n1-standard-32 808.28 864.91 872.36 848.52
n1-highmem-32 1096.35 1077.33 1055.2 1076.29
n1-highcpu-32 847.68 791.16 900.32 846.39

(size: 1,048,576-bytes)

Summary of Results
For the network latency, we can see the average is around 40 ~ 45 microseconds, which is 4x faster than the previous result – around 180 microseconds. And the new latency is fairly consistent among other smaller instance types.

For bandwidth, we don’t have a previous result to compare to but among all the GCE instance types, we found n1-highmem-32 has the best performance which can be as high as 1070 MB/s. This result aligns with GCE’s official document https://cloud.google.com/compute/docs/networks-and-firewalls#egress_throughput_caps.

Related articles

EDEM Now Available on Rescale’s Cloud Simulation Platform

San Francisco, CA – Rescale and EDEM are pleased to announce the availability of EDEM software on Rescale’s simulation platform through collaboration with EDEM, the Discrete Element Method (DEM) specialist and market leader. EDEM is high-performance software for bulk material […]

read more »

複数ジョブ実行時の時間と経費を節約する新機能:Persistent Clusters (永続クラスター)

RescaleのRahul Vergheseが、2017年1月19日に記載したBlog記事の翻訳です。 元記事はIntroducing Persistent Clusters: a New Feature to Save Time & Money with Multiple Jobsをご覧ください。 Rescaleは、最新のデプロイメントで新機能のPersistent Clusters (以下、「永続クラスター」:マニュアルで起動/削除可能なクラスター)をリリースしました。この機能を有効にすることで、複数のインスタンスを起動してクラスタを構築し、シャットダウン(訳注:Rescaleシステムではシャットダウン後インスタンスは削除されます)することなく、Rescaleワークフロー(Web UI)を使用して複数のジョブを順番に同じクラスターへ投入できます。以前は、各ジョブ毎にクラスターが稼働し、ジョブの完了後は自動的にシャットダウンされるため、複数の小さなジョブを実行すると遅延が発生する可能性がありました。この新しい機能により、繰り返し処理の高速化が可能になります。これは、テストや同じハードウェア構成を必要とする複数のジョブに特に便利です。 時間とお金を節約 一般に、各クラスターがスピンアップしてシャットダウンするまでには数分かかります。永続的クラスターを有効にしておくと、クラスターに追加する各ジョブの時間とコストを節約できます。 なぜ? 標準のクラスターは、ジョブが完了すると自動的にシャットダウンし、後続のジョブも同じように起動してシャットダウンするため、別々のクラスターとしてそれぞれ課金されます。(訳注:通常、たとえ10分の計算であっても1時間分の課金となるため、10分で完了する連続する2つのジョブを実行した場合、2時間分が課金されます)一方で、永続クラスターを使用すると、クラスターはすぐに次のジョブの実行に使用できるようになるため、ジョブ間で別のクラスターをシャットダウンして起動させる時間を無駄にしません。それによって、同様のジョブを多数立ち上げるユーザーにとって、時間とコストを大幅に節約することになります。(訳注:上記の例だとちょうど10分の計算を待ち時間なく2つ連続的に実施できることになり、1時間分の課金で収まることになります。)

read more »