2019.10.14

ZYNQのLinuxにおける無線LANの速度を測ってみた

先日の検証でElecomのWDC-150SU2MがZYNQ Linuxから動くようになったので、ZYNQのLinuxから無線LANを使った場合どのくらいの速度が出るのかを、様々なWiFiアダプタで調査してみました。

使ったボードはZynqberryで、OSはUbuntu Linux 18.04です。

Zb_wifis

現状、ARM版Linuxで動くUSB-Wifiアダプタというと正直あまり多くないのが事実です。

上の写真のWiFiアダプタは、左から順にGW-USNano2、WDC-150SU2M、TL-WN725N、WLI-UC-GNM2です。入手できてARM版Liunxから使えるアダプタは現時点でこのくらいしかありません。

最近ではGW-USNano2も入手できなくなってきたので、これらのWiFiアダプタの実力を測り、GW-USNano2の後継となる品番を選定するのが目的です。

無線LAN親機にはTP-Linkを使いました。

Tplink

(画像は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とすれば日本にあるサーバの一覧が取得できるので、近くて速そうなサーバを選んでテストします。

Serverlist

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最高です!

 

| | コメント (0)

2019.10.12

台風到来

台風が来ました!

15:00~16:00ごろにかけて、錦糸町駅前~隅田川沿いまで自転車で走ってきました。

いつもは人通りと、違法駐車でいっぱいの錦糸町駅前ですが、閑散としています。

Taifu2

Taifu1

人っ子一人、違法駐車1台もいません。

空いているお店はコンビニとハナマサくらいでした。ありがたいことにハナマサは開いていたので、昨日のうちに食材を調達できなかった場合でも飢えずにすむかもしれませんね。(なひたふは前日におでんの具材を買っておいたので大丈夫ですよ。)

本当にどのお店もみんな臨時休業。

隅田川まで来てみると、見たことがないほどの水量。ただ、川の様子を見に来たひとが結構います。

Taifu4

普段はランナーがジョギングしている隅田川テラスもすっかり冠水。

Taifu6

階段の下まで降りられません。

Taifu3

ベンチも水没。

Taifu5

荒川と隅田川の堤防が持ってくれることを祈ります。

| | コメント (0)

2019.10.11

台風への備え

今日は台風が気になって仕事になりません。

なひたふは、本郷のビルにあった大量の荷物を格納するために、隅田川沿いの安い倉庫や、幹線道路沿いの1階のトランクルームにしまっています。

川沿い倉庫には古いトラ技や数年前の帳簿、古いパソコン、あまり使わない工具や資材などを入れているのですが、水没したらどうしようかと気になって見に行ってきました。

シャッターの隙間にダンボールを詰めて養生テープを貼ったりしていたのですが、川沿いの倉庫はどうみても海抜ゼロメートル地帯だし、川の水面より低いんですよね。

Sumida_river_1011

決壊したらどうしようもないので、そこそこのところであきらめて帰ってきました。

それなりに空調管理された「幹線道路沿いのレンタル倉庫」には借り物の高級オシロや、電子部品をしまっているのですが、こちらも道路が冠水したらひとたまりもありません。

万が一浸水しても無事であるように、お借り物の高級オシロや未使用の資材は高いところに上げておきました。

本当に隅田川や荒川が決壊したら、うちだけではなく、周囲のお店や工場とかみんな大損害ですから、そんなことは起きないだろうと祈りつつ。

帰りにスーパーで3日分の食材と、万が一の停電や断水にそなえておやつを買って帰りました。

それからDigikeyの荷物が5箱ほど届くはずだったのですが、通関が13:00ごろになったため到着しませんでした。

本当は木曜日に到着しているはずの荷物も含めてさらに遅配しています。UPSに電話してヤマトに委託して連休中に配達してくださいとの電話をしたのですが、同様の荷物が多すぎて無理ということでした。この状況では仕方がないですね。

 

| | コメント (0)

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つ取るのが一番早く簡単そうだったからです。

| | コメント (0)

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回同じファイルを転送しないようにして測ってみました。

Ftp_sd

・PUT from SD・・ZYNQのLinux上でPUTする(SDカードは読み出し)

・GET to SD・・・ZYNQのLinux上でGETする(SDカードは書き込み)

を意味します。

結果としては、転送サイズが50Mバイトを超えるあたりで速度が急に下がってしまい、それ以後は20Mバイト/秒前後に収束するというものでした。おそらく、この速度はSDカード上のファイルをアクセスするためのキャッシュのサイズなのでしょう。

これだとSDカードのベンチマークをしているにすぎないので、LinuxでRAMDISKを作成し、RAMDISK上に乱数ファイルを置いて試してみました。

その結果ですが、RAMDISKの場合はほとんど速度が下がることなく転送することができました。

 

Ftp_sd_ramdisk

bpsに直してみます。

Ftp_sd_ramdisk2

このZYNQのシステムのメモリ帯域は5Gbyte/sくらいあるので、RAMDISKの帯域がそれほど問題になることはないでしょうから、TCPによる通信速度がほぼ見えていると考えられます。

結果、GETは600Mbps弱、PUTは約400Mbpsという感じでした。

 

| | コメント (0)

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にしておくのが良いようです。

 

| | コメント (0)

2019.10.04

夜中に出社

錦糸町駅前の高層ビルのレンタルオフィスに入居したのですが、めっちゃ快適です。

正規会員になるとカードキーがもらえて24時間365日使用できるようになるので、夜中に会社に行くことが多くなってきました。

0時過ぎに出社すると駐輪場はガラガラ。

下の写真は2:40ごろの様子。ほとんどの窓の灯りが消えてますが、わずかに残業している人もいるようです。働き方改革が進んでいます。

Arca

夜中は空調が止まるので、この時期なのに暑い!

私の作業机。オシロも搬入して、だんだん環境も整ってきました。

Arca2

| | コメント (0)

2019.10.03

Cosmo-ZのMCAでK-40の効果を確認

Cosmo-ZのMCAをVivadoに移植でき、計測値が書き変わってしまうバグも直ったので、NaIで測ったバックグラウンドと、NaIの近くに塩化カリウムの試薬を置いた場合の比較をしてみました。

まずは、NaIを置かないバックグラウンドのみの場合。6時間測っています。

Normalbackground

次に塩化カリウムを置いた場合。

カリウム40のピークが見えています。

Withk40

画像上で比較してみます。

Diff

しっかりと差が表れています。

差が表れたK-40のピークの場所が1461keVであることがわかったので、上側にあるTl-208と思われるピークを2615keVとして、画像上で133pixelの差になります。1ピクセル当たり8.67keVとして横軸を読んでみると、低い方にあるピークは464,646,1140と読めます。

Numbering

おそらく1140keVと出たのがコンプトンエッジで、その下の646keVと出ているのがBi-204の609keVではないかと思われますが、使っている検出器ではエネルギーと波高の高さが直線的ではないのかもしれません。

内挿も外挿も上手くいっていなさそうな感じです。

| | コメント (0)

«ZYNQのXC7Z007Sにすれば消費電力は減るか?