Cosmo-Z 6台の実装が上がってきた
Cosmo-Z 6台の実装が上がってきました。
これから出荷検査をし、今月中に3台出荷するのが目標です。
2019.10.29
2019.10.14
ZYNQのLinuxにおける無線LANの速度を測ってみた
先日の検証でElecomのWDC-150SU2MがZYNQ Linuxから動くようになったので、ZYNQのLinuxから無線LANを使った場合どのくらいの速度が出るのかを、様々なWiFiアダプタで調査してみました。
使ったボードはZynqberryで、OSはUbuntu Linux 18.04です。
現状、ARM版Linuxで動くUSB-Wifiアダプタというと正直あまり多くないのが事実です。
上の写真のWiFiアダプタは、左から順にGW-USNano2、WDC-150SU2M、TL-WN725N、WLI-UC-GNM2です。入手できてARM版Liunxから使えるアダプタは現時点でこのくらいしかありません。
最近ではGW-USNano2も入手できなくなってきたので、これらのWiFiアダプタの実力を測り、GW-USNano2の後継となる品番を選定するのが目的です。
無線LAN親機にはTP-Linkを使いました。
(画像はAmazonより)
まず、GW-USNANO2Aです。nmcliで接続の状況を確かめます。
root@zynqberry:~# nmcli device wifi
IN-USE SSID MODE CHAN RATE SIGNAL BARS SECURITY
* TP-Link_XXXX Infra 8 405 Mbit/s 72 *** WPA1 WPA2
速度の測定方法ですが、LANはFTPサーバを使いますが、今回はWANへの通信速度も測ることにしました。
Windowsではhttp://fast.com/jaとか回線速度測定サイトがいっぱいあるのですが、Linuxにはspeedtestという回線速度を測るアプリがあるので、これを使ってみます。
使い方は、speedtest --server サーバ番号 です。
サーバ番号はspeedtest --list | grep Japanとすれば日本にあるサーバの一覧が取得できるので、近くて速そうなサーバを選んでテストします。
SINETに20Gで接続されたOPEN Projectというのが強そうなので、これを使ってみます。
root@zynqberry:~# speedtest --server 15047
Retrieving speedtest.net configuration...
Testing from Fujitsu (124.26.42.4)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by OPEN Project (via 20G SINET) (Tokyo) [6.34 km]: 14.114 ms
Testing download speed................................................................................
Download: 4.21 Mbit/s
Testing upload speed......................................................................................................
Upload: 30.11 Mbit/s
WANへのダウンロードは4.21Mbit/sで、アップロードは30.11Mbit/sと出ました。
LAN上でのFTPの速度はPUTが4.9MbpsでGETが5.9Mbpsでした。WANのほうが速いですね。パケットがロスしているとか、再送とかのタイミングの問題なのでしょうか。
次に、切り替え候補本命のWDC-150SU2Mを試します。
Hosted by OPEN Project (via 20G SINET) (Tokyo) [6.34 km]: 15.966 ms
Testing download speed................................................................................
Download: 23.55 Mbit/s
Testing upload speed......................................................................................................
Upload: 27.19 Mbit/s
上り下りとも25Mbps前後出ていました。
FTPもPUTが28Mbps、GETが21Mbpsと4つの中では最優秀でした。
次はTL-WN725Nです。筐体金属部分が金色に光っていて格好いいのですが、その実力は如何に。
root@zynqberry:/ramdisk# nmcli device wifi
IN-USE SSID MODE CHAN RATE SIGNAL BARS SECURITY
* TP-Link_5D26 Infra 8 44 Mbit/s 93 **** WPA1 WPA2
Hosted by OPEN Project (via 20G SINET) (Tokyo) [6.34 km]: 19.176 ms
Testing download speed................................................................................
Download: 18.48 Mbit/s
Testing upload speed......................................................................................................
Upload: 22.74 Mbit/s
speedtestでは20Mbps前後を叩き出しています。
FTPの速度はPUTが26Mbps、GETが21Mbps前後でした。
最後はWLI-UC-GNM2。Ralink RT3070を使っているようです。
このWiFiアダプタではなぜかspeedtestツールがうまく動きませんでした。
FTPはPUTが14Mbps、GETが23Mbpsと中間の性能でした。
☀
結論としては、私の手元にあった4種類のWiFiアダプタの中ではWDC-150SU2Mがベストでした。
WDC-150SU2Mで使われているWiFiチップ「RTL8188EUS」のドライバがwpa_supplicantに対応していないらしく、Ubuntu 14の頃はなかなかうまく動かなかったのですが、Ubuntu 18になってNetworkManager(nmcli)を使うようになってからはすんなりと動くようになりました。
私の環境ではZynqberry + Ubuntu18なのでWDC-150SU2Mが素直に動きましたが、PetaLinuxやDebianを使っている方はどうなるかはわかりません。やはり、Ubuntu 18最高です！
2019.10.12
台風到来
台風が来ました！
15:00～16:00ごろにかけて、錦糸町駅前～隅田川沿いまで自転車で走ってきました。
いつもは人通りと、違法駐車でいっぱいの錦糸町駅前ですが、閑散としています。
人っ子一人、違法駐車1台もいません。
空いているお店はコンビニとハナマサくらいでした。ありがたいことにハナマサは開いていたので、昨日のうちに食材を調達できなかった場合でも飢えずにすむかもしれませんね。（なひたふは前日におでんの具材を買っておいたので大丈夫ですよ。）
本当にどのお店もみんな臨時休業。
隅田川まで来てみると、見たことがないほどの水量。ただ、川の様子を見に来たひとが結構います。
普段はランナーがジョギングしている隅田川テラスもすっかり冠水。
階段の下まで降りられません。
ベンチも水没。
荒川と隅田川の堤防が持ってくれることを祈ります。
2019.10.11
台風への備え
今日は台風が気になって仕事になりません。
なひたふは、本郷のビルにあった大量の荷物を格納するために、隅田川沿いの安い倉庫や、幹線道路沿いの1階のトランクルームにしまっています。
川沿い倉庫には古いトラ技や数年前の帳簿、古いパソコン、あまり使わない工具や資材などを入れているのですが、水没したらどうしようかと気になって見に行ってきました。
シャッターの隙間にダンボールを詰めて養生テープを貼ったりしていたのですが、川沿いの倉庫はどうみても海抜ゼロメートル地帯だし、川の水面より低いんですよね。
決壊したらどうしようもないので、そこそこのところであきらめて帰ってきました。
それなりに空調管理された「幹線道路沿いのレンタル倉庫」には借り物の高級オシロや、電子部品をしまっているのですが、こちらも道路が冠水したらひとたまりもありません。
万が一浸水しても無事であるように、お借り物の高級オシロや未使用の資材は高いところに上げておきました。
本当に隅田川や荒川が決壊したら、うちだけではなく、周囲のお店や工場とかみんな大損害ですから、そんなことは起きないだろうと祈りつつ。
帰りにスーパーで3日分の食材と、万が一の停電や断水にそなえておやつを買って帰りました。
☀
それからDigikeyの荷物が5箱ほど届くはずだったのですが、通関が13:00ごろになったため到着しませんでした。
本当は木曜日に到着しているはずの荷物も含めてさらに遅配しています。UPSに電話してヤマトに委託して連休中に配達してくださいとの電話をしたのですが、同様の荷物が多すぎて無理ということでした。この状況では仕方がないですね。
2019.10.10
SSLサーバの証明書有効期限切れとHTTPS化
うっかりやってしまいました。
trenz.jpのSSLサーバの証明書が有効期限切れを起こしてしまいました。
昔いたアルバイト君が残してくれた手順書を読み返しながら、証明書を再取得しています。彼の手順書にはわざわざ
「また、期限前に申請しても90日以前であればその分は延長されるので、ぎりぎりまで待つ意味はない。」
という注意書きまで残してくれたのに、ぎりぎりまで怠ってしまいました。
以下に、RapidSSLで更新した際の手順を書きます。基本的には秘密鍵→CSR→CRTの順に作ります。
CSRには公開鍵と、E、CN(Common Name)、O(Organization)、L(City or Locality)、S(State or Province)、C(Country)などの情報が入っているようです。有効期限とかを入れる場所はないので毎年作り直す必要はないのかもしれませんが、特電の場合は本社を移転しているので、LがBunkyoからSumidaに変更して作り直します。
keyファイル(秘密鍵)は毎年作り直す必要はないようなので、過去に使っていたものを使います。
まず、Linuxで/etc/sslに移動して、以下の操作をします。
$ openssl req -new -key 秘密鍵ファイル名.key > ファイル名.csr
Enter pass phrase for server.key:##秘密鍵のパスフレーズ##
You are about to be asked to enter information that will be inc
into your certificate request.
What you are about to enter is what is called a Distinguished N
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:Sumida
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tokushu Denshi Kairo Inc.
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:www.trenz.jp
Email Address []:info@tokudenkairo.co.jp
ここまで記入すると、追加オプションをきかれますが、何も入れずにEnterを連打します。
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
こうしてCSRファイルが出来たら、
-----BEGIN CERTIFICATE REQUEST-----
MIICoTCCAYkCAQAwXDELMAkGA1UEBhMCSlAxEDAOBgNVBAgTB3htbXMuanAxDjAM
(中略)
0mwYcho=
-----END CERTIFICATE REQUEST-----
の部分をRapidSSLのフォームに貼り付けます。
RapidSSLのサーバから「どこのディレクトリに、このファイルを置くこと」というメールが来るので、指定されたディレクトリにそのファイルを置きます。すると、Webサイトの管理権限のある人だということが認識され、CRTファイルが送られてきます。
そして、CRTファイルを/etc/sslに置き、Apacheの設定の
SSLCertificateFile "/etc/ssl/ファイル名.crt"
SSLCertificateKeyFile "/etc/ssl/秘密鍵.key"
の部分にファイル名を設定してApacheを再起動します。
これで新しい証明書がインストールされます。
せっかくSSLを更新したのだから、サイトをhttpからhttpsに完全移行しようと思ったのですが、ここで一つ問題が起きました。
一般的に、httpをhttpsにリダイレクトし、wwwなしをwwwありにリダイレクトしたいと思ったとき、.htaccessは以下のように書けばいいようなのですが、
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^trenz\.jp$
RewriteRule ^(.*)$ https://www.trenz.jp/$1 [R=301,L]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.trenz.jp/$1 [R=301,L]
</IfModule>
https://trenz.jp/でアクセスしてきたものをhttps://www.trenz.jp/にリダイレクトしたいと思ったとき、いったんはhttps://trenz.jp/でアクセスしてからリダイレクトされるので、trenz.jpの証明書も必要になるのです。
このやり方だと、SSL証明書はwww.trenz.jpとtrenz.jpで別々に取らなければならず、2倍の費用がかかります。
どうやればよいか悩んだのですが、結局、2種類の証明書を取ることにしました。
ワイルドカードのSSL証明書*.trenz.jpは10倍以上の値段がするので、2つ取るのが一番早く簡単そうだったからです。
2019.10.09
ZYNQのGigabitEtherの速度を測定
ZYNQのGigabitEtherがどの程度の速度が出るのかをもう少し丁寧に測ってみました。
昨日の結果ではWindowsのIISをサーバとして測るのが良いとわかったので、今日は様々なサイズのファイルを用意して測ってみます。
使ったZYNQボードはCosmo-Zです。
測り方は以下のとおりです。
- Windows 10のマシンでIISを動かし、FTPサーバを動かす
- ZYNQのボードとWindows10のマシンをGigabitEtherでつなぐ
- ZYNQのLinuxからFTPで16～256MByteの乱数ファイルをPUT/GETする
というものです。
まず、ddを使って乱数ファイルを作ります。
dd if=/dev/urandom of=rand16 bs=1048576 count=16
これで16MByteの乱数ファイルが出来ます。同様に32,48,64,80,96,128,160,192,256MByteのファイルを作っておきます。
そして、WindowsのFTPサーバにログインして、バイナリモードにして、PUTやGETを行います。
軽くやってみたところ、
ftp> get random
local: random remote: random
200 PORT command successful.
125 Data connection already open; Transfer starting.
226 Transfer complete.
258207980 bytes received in 3.48 secs (72419.1 kB/s)
と、72Mバイト/秒でています。560Mbps相当だから明らかに100Mbpsを超えていてGigabitEtherの性能が出ているな・・と思ったのですが、実行するたびに速度が変わることに気が付きました。
おそらく、これらのファイルをSDカードに入れているから、何らかのキャッシュが効いてしまっているためでしょう。
そこで、連続して2回同じファイルを転送しないようにして測ってみました。
・PUT from SD・・ZYNQのLinux上でPUTする（SDカードは読み出し）
・GET to SD・・・ZYNQのLinux上でGETする（SDカードは書き込み）
を意味します。
結果としては、転送サイズが50Mバイトを超えるあたりで速度が急に下がってしまい、それ以後は20Mバイト/秒前後に収束するというものでした。おそらく、この速度はSDカード上のファイルをアクセスするためのキャッシュのサイズなのでしょう。
これだとSDカードのベンチマークをしているにすぎないので、LinuxでRAMDISKを作成し、RAMDISK上に乱数ファイルを置いて試してみました。
その結果ですが、RAMDISKの場合はほとんど速度が下がることなく転送することができました。
bpsに直してみます。
このZYNQのシステムのメモリ帯域は5Gbyte/sくらいあるので、RAMDISKの帯域がそれほど問題になることはないでしょうから、TCPによる通信速度がほぼ見えていると考えられます。
結果、GETは600Mbps弱、PUTは約400Mbpsという感じでした。
2019.10.08
ZYNQのGigabitEther性能を測る
ZYNQのGigabitEtherの性能を測ってみました。
最初に、Windows10上のOracleVM上でUbuntu16を動かし、その上でTFTPサーバを立ててPUTやGETを行ってみました。
その結果を示します。
- 100M Ether, TFTP GET 256MByte・・・Received 268435456 bytes in 189.7 seconds → 11.3Mbps
- 100M Ether, TFTP PUT 256MByte・・・Sent 268435456 bytes in 172.4 seconds → 12.4Mbps
- GigabitEther, GET 256MByte・・・Received 268435456 bytes in 117.1 seconds → 18.3Mbps
- GigabitEther, PUT 256MByte・・・Sent 268435456 bytes in 112.5 seconds → 19.1Mbps
なんと、100Mbpsにも達していないという結果でした。
Virtual Machineが悪いのか、TFTPが悪いのかわからないので、OracleVM上のUbuntu16にFTPサーバを立てて、こんどはFTPでやってみました。
- 100M FTP GET (256MByte) 268435456 bytes received in 24.95 secs (84MB/s)
- 100M FTP PUT (256MByte) 268435456 bytes sent in 22.75 secs (92MB/s)
- 1G FTP GET (256MByte) 268435456 bytes received in 20.66 secs (102MB/s)
- 1G FTP PUT (256MByte) 268435456 bytes sent in 12.20 secs (172MB/s)
大分速くなりました。UDPが悪いのか、TFTPサーバのソフトが悪かったようですね。
相手方はWindows10 IISです。
- 100M FTP GET (256MByte) 268435456 bytes received in 27.84 secs (75MB/s)
- 100M FTP PUT (256MByte) 268435456 bytes sent in 22.89 secs (92MB/s)
- 1G FTP GET (256MByte) 268435456 bytes received in 24.54 secs (86MB/s)
- 1G FTP PUT (256MByte) 268435456 bytes sent in 7.53 secs (278MB/s)
だいぶん速度も改善されてきました。
FTPの速度を測る相手方はWindows上のIISにしておくのが良いようです。
2019.10.04
夜中に出社
錦糸町駅前の高層ビルのレンタルオフィスに入居したのですが、めっちゃ快適です。
正規会員になるとカードキーがもらえて24時間365日使用できるようになるので、夜中に会社に行くことが多くなってきました。
0時過ぎに出社すると駐輪場はガラガラ。
下の写真は2:40ごろの様子。ほとんどの窓の灯りが消えてますが、わずかに残業している人もいるようです。働き方改革が進んでいます。
夜中は空調が止まるので、この時期なのに暑い！
私の作業机。オシロも搬入して、だんだん環境も整ってきました。
2019.10.03
Cosmo-ZのMCAでK-40の効果を確認
Cosmo-ZのMCAをVivadoに移植でき、計測値が書き変わってしまうバグも直ったので、NaIで測ったバックグラウンドと、NaIの近くに塩化カリウムの試薬を置いた場合の比較をしてみました。
まずは、NaIを置かないバックグラウンドのみの場合。6時間測っています。
次に塩化カリウムを置いた場合。
カリウム40のピークが見えています。
画像上で比較してみます。
しっかりと差が表れています。
差が表れたK-40のピークの場所が1461keVであることがわかったので、上側にあるTl-208と思われるピークを2615keVとして、画像上で133pixelの差になります。1ピクセル当たり8.67keVとして横軸を読んでみると、低い方にあるピークは464,646,1140と読めます。
おそらく1140keVと出たのがコンプトンエッジで、その下の646keVと出ているのがBi-204の609keVではないかと思われますが、使っている検出器ではエネルギーと波高の高さが直線的ではないのかもしれません。
内挿も外挿も上手くいっていなさそうな感じです。
2019.10.02
ZYNQのXC7Z007Sにすれば消費電力は減るか？
ZYNQにはシングルコアのXC7Z007Sというのがあります。
CPUが1個しか入っていないし、PLも小さいはずだから、これを使うと消費電力が削減できるかと思ったのですが、どうでしょうか？
実験してみました。
使ったボードは、ZynqberryのTE0726-03MとTE0726-S。型番の末尾が-03MのほうはXC7Z010が、-Sのほうは007Sが搭載されています。
Zynqberryでは同じ基板でZYNQのサイズだけが違うので、消費電力の比較が容易にできます。
今回はUSBのバスパワーではなくて、ピンを立てて安定化電源から給電し、安定化電源の表示から電流を読み取ります。
その結果は以下のとおり
- リセット中・・・007S=200mA、010=200mA
- SPI ROMにboot.binがなく起動しない状態・・・007S=230mA、010=230mA
- U-Bootが起動した状態・・・007S=380mA、010=380mA
- Ubuntu 18.04起動中・・・007S=最大500mA、010=最大560mA ※常に変動
- 起動完了・・・007S=470mA、010=470mA
- LAN接続・・・007S=520mA、010=520mA
と、消費電流に全く差はありませんでした。
起動時のメッセージを見ると確かに7SのほうはCPU1が存在していないのですが、それでも消費電力の差には表れてこないようです。
BitStreamのサイズも007Sと010でほとんど違いがないので、ひょっとしたら007Sは010と同じダイを使っていて、何かのヒューズを切っているだけなのかもしれませんね。
☀
では、処理速度はどうでしょうか。
Unixbenchというのを走らせてみました。Unixbenchの各測定項目の意味は、https://blog.idcf.jp/entry/cloud/unixbench/ のページが詳しく書かれています。
まずは、シングルコアの007Sの結果です。
Benchmark Run: Wed Oct 02 2019 03:02:57 - 03:31:48
1 CPU in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 3431135.0 lps (10.0 s, 7 samples)
Double-Precision Whetstone 519.8 MWIPS (10.0 s, 7 samples)
Execl Throughput 493.7 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 70046.9 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 20825.9 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 168673.4 KBps (30.0 s, 2 samples)
Pipe Throughput 180698.7 lps (10.0 s, 7 samples)
Pipe-based Context Switching 38948.6 lps (10.0 s, 7 samples)
Process Creation 1415.2 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 953.3 lpm (60.1 s, 2 samples)
Shell Scripts (8 concurrent) 122.6 lpm (60.2 s, 2 samples)
System Call Overhead 299745.8 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 3431135.0 294.0
Double-Precision Whetstone 55.0 519.8 94.5
Execl Throughput 43.0 493.7 114.8
File Copy 1024 bufsize 2000 maxblocks 3960.0 70046.9 176.9
File Copy 256 bufsize 500 maxblocks 1655.0 20825.9 125.8
File Copy 4096 bufsize 8000 maxblocks 5800.0 168673.4 290.8
Pipe Throughput 12440.0 180698.7 145.3
Pipe-based Context Switching 4000.0 38948.6 97.4
Process Creation 126.0 1415.2 112.3
Shell Scripts (1 concurrent) 42.4 953.3 224.8
Shell Scripts (8 concurrent) 6.0 122.6 204.3
System Call Overhead 15000.0 299745.8 199.8
========
System Benchmarks Index Score 160.9
トータルスコア160.9という値でした。
次に普通のZYNQの010ですが、Unixbenchは、CPUコアが複数ある場合は1個、2個と順にスレッドを増やしていって実力を測ってくれます。
最初の結果はコアを1個だけ使った場合の値です。
Benchmark Run: Wed Oct 02 2019 03:36:57 - 04:05:40
2 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 3433203.0 lps (10.0 s, 7 samples)
Double-Precision Whetstone 519.7 MWIPS (10.0 s, 7 samples)
Execl Throughput 474.6 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 70368.4 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 20844.5 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 170183.5 KBps (30.0 s, 2 samples)
Pipe Throughput 179739.3 lps (10.0 s, 7 samples)
Pipe-based Context Switching 25262.2 lps (10.0 s, 7 samples)
Process Creation 1372.7 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 1202.7 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 215.8 lpm (60.1 s, 2 samples)
System Call Overhead 295821.1 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 3433203.0 294.2
Double-Precision Whetstone 55.0 519.7 94.5
Execl Throughput 43.0 474.6 110.4
File Copy 1024 bufsize 2000 maxblocks 3960.0 70368.4 177.7
File Copy 256 bufsize 500 maxblocks 1655.0 20844.5 125.9
File Copy 4096 bufsize 8000 maxblocks 5800.0 170183.5 293.4
Pipe Throughput 12440.0 179739.3 144.5
Pipe-based Context Switching 4000.0 25262.2 63.2
Process Creation 126.0 1372.7 108.9
Shell Scripts (1 concurrent) 42.4 1202.7 283.6
Shell Scripts (8 concurrent) 6.0 215.8 359.6
System Call Overhead 15000.0 295821.1 197.2
========
System Benchmarks Index Score 164.9
結果は164.9と、ほぼシングルコアのZYNQと同じ値でした。わずかに高い値が出ているのはシステムのバックグラウンドなプロセスにCPUパワーを割かなくていいからではないかと思います。
最後は010のPSのCPUを2コア使った場合です。
Benchmark Run: Wed Oct 02 2019 04:05:40 - 04:34:42
2 CPUs in system; running 2 parallel copies of tests
Dhrystone 2 using register variables 6865760.4 lps (10.0 s, 7 samples)
Double-Precision Whetstone 1040.0 MWIPS (10.0 s, 7 samples)
Execl Throughput 850.3 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 126927.2 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 34896.2 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 312419.7 KBps (30.0 s, 2 samples)
Pipe Throughput 359498.4 lps (10.0 s, 7 samples)
Pipe-based Context Switching 75371.8 lps (10.0 s, 7 samples)
Process Creation 2314.4 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 1659.5 lpm (60.1 s, 2 samples)
Shell Scripts (8 concurrent) 214.6 lpm (60.2 s, 2 samples)
System Call Overhead 582074.3 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 6865760.4 588.3
Double-Precision Whetstone 55.0 1040.0 189.1
Execl Throughput 43.0 850.3 197.7
File Copy 1024 bufsize 2000 maxblocks 3960.0 126927.2 320.5
File Copy 256 bufsize 500 maxblocks 1655.0 34896.2 210.9
File Copy 4096 bufsize 8000 maxblocks 5800.0 312419.7 538.7
Pipe Throughput 12440.0 359498.4 289.0
Pipe-based Context Switching 4000.0 75371.8 188.4
Process Creation 126.0 2314.4 183.7
Shell Scripts (1 concurrent) 42.4 1659.5 391.4
Shell Scripts (8 concurrent) 6.0 214.6 357.7
System Call Overhead 15000.0 582074.3 388.0
========
System Benchmarks Index Score 295.0
だいたい2倍弱の性能が出ました。
この結果からわかることは、複数スレッドを同時に走らせればシングルコアの7Sよりも010のほうが2倍ほど速いという当然の結果ですが、逆に今まで動かしていたZYNQのLinuxは間違いなく2コア同時に動いていたのだと安心できる結果でした。
007Sと010の消費電力は変わらないことと、複数スレッドの時には010は2倍のパワーが出るということが確認できました。
最近のコメント