29-Jun-2018に導入したSSL証明書、4年分買ってあって2年後に更新ということでその更新の時期がやってきたのですが、なんか色々変わっていてちょっと作業に手間取っておりました。

詳細は29-Jun-2018の記事に補足の形で追加してあるのでそちらを参照してほしいのですが…これからどうしましょうかね。とりあえず考える時間は2年あります。

COMODOのSSL証明書を購入したCheapSSLsecurityの価格を見るに、$5.45×5年で$27.25…VPSを引っ越さなければそれもそれでありな気はしますが、海外の安価でスペックの高いVPSへ移行できればそれもそれで良いかなとも。

IPv6側のSSL対応もやんないといけないなーとは思っているものの未だに対応していない状態が続いていますし（IPv4とIPv6のFQDNが同じならそもそもこんな問題は起こらないのだけど）、お前真面目にサーバー運用する気があるのか？と怒られてもおかしくないです、ごめんなさいごめんなさい。

ところで、24-May-2020でOpenBSD-6.6→6.7への移行に手間取ってとありますが、手元のマシンではなくVPSの更新で詰まっていました。どう頑張ってもbsd.rdが起動してくれない。

OpenBSD-6.7/amd64ではTSXの無効化処理がsys/arch/amd64/amd64/cpu.cに追加されているのですが、実機ならともかくQEMU上で動かす場合はQEMUがこれに対応していないといけません。なにしろadd support for MSR_IA32_TSX_CTRLなんて話があるくらいなので。

さくらのVPSのユーザサポートに相談してみたところ、QEMUのエミュレーションするCPUモデルを変更できるという回答を得たので、これによりOpenBSD-6.7が動くようになっています。CPUIDを見るに、TSX（正確にはHLE）が無効化されていることを確認しています。

で、変更前の状態、TSXが有効になっていてもOpenBSD-6.7/amd64を動かしたい！という場合にどう足掻いたかというのもメモとして残しておきますが…以下の手順を踏みました。

1. OpenBSD-6.6がインストールされている状態を作る
2. OpenBSD-6.7カーネルのソースコードを入手する
3. sys/arch/amd64/amd64/cpu.cにあるcpu_tsx_disable()を無効化する
4. OpenBSD-6.7 GENERIC.MPカーネルをビルドする（bsd.mp.tmpとしておく）
5. OpenBSD-6.7 RAMDISK_CDカーネルをビルドする（bsd.rd.tmpとしておく）
6. rdsetrootで、OpenBSD-6.7のbsd.rdからRAM disk（インストーラー他一式）をbsd.rd.tmpに移植する
7. bsd.rd.tmpで起動し、アップグレードを行う
8. アップグレード後、bsd.mp.tmpで起動する
9. OpenBSD-6.7 GENERIC.MPカーネルを再度ビルドし、インストールする

Theo曰く「んなもんQEMUが悪いに決まっとるわ」とのことなので、こういう面倒な手順で強引に動かすことを考える前にVPSのサポートセンターに相談した方が良いと思います。自分でQEMUを動かしているならQEMUのアップグレードを。57.35kg(20:45)

OpenBSD-6.6→6.7への移行に手間取ってしまい、しばらくHDBENCH cloneの作業が止まっていたのですが久々に再開。

HDBENCH cloneの画面デザインが（本家Windows版の）HDBENCH Ver3.30と違うなーと思っていたんですが…

どうもHDBENCH cloneが真似ていたのはVer2.61の方みたいで。おっかしーなーと思ってこちらもダウンロードして動かして（実際には測定できなかったのですが）初めて知ったという。

HDBENCH Ver3.30のUIを真似ても良いのかもしれませんが、Optionのウィンドウをいちいち作るのも面倒なのでVer2.61のスタイルを踏襲します。さらに、HDBENCH cloneでは未実装だった機能かつHDBENCH Ver3.30では廃止されたものを実装する必要もないだろうと思いますので（プラグインとかCD-ROMの速度測定とか読み出しテストが先になるとか）、ここは削ります。

そんな訳で、今のところこんな感じです。日本語対応は諦めました（これくらいなら英語のままでも問題ないでしょう）。

個人的にはperform IMAGE testのチェックボックスやGRAPHのボタンは要らないし、左にOPTIONS・右にFORMATの方が自然に思えるのですが、デザインを引き継ぐという理由でこのようにしています。でもVer2.61とVer3.30がチャンポンになっているのは気持ち悪い、という声が聞こえてきそうですね…

大体動く感じではあるのですが、CAPACITYメニューの内容はHDBENCH Ver3.30に合わせた方が良さそうなのでこれは後で直す予定です。あとはドキュメントの整備が残っています。57.25kg(20:45)

02-May-2020の続き。AVX2命令を使った場合にどうなるのかが気になったので、話題のRYZENを…使うには一式組み替えないといけないためA8-7670KをAthlon X4 845に入れ替えてテストしてみました。グラフィックカードは某ゲームのためにGeForce GT1030を入れているので問題ありません（イマドキのゲームだとAPU内蔵のRadeon R7ではツラい）。

先に結論を書いちゃいますが、Turbo offだとA8-7670Kが3.6GHz、Athlon X4 845が3.5GHzとA8よりもクロックが低い割にAthlon X4 845の方が（コンパイルオプションに関わらず）速かったりします。テスト方法はこの日記で書いていた方法ではなく、GitHubのpull requestに付いたコメントにある方法です。A8-7670Kの結果はここにあるA8/64bitと同じです。

AVX2 + FMAと、AVXとの差はあまり大きくはないので、無理にAVX2対応する必要があるかというと多分無いです。

ただ、Athlon X4 845の素性はかなり良さそうです。OpenBSDマシンに入っているA10-7860KもExcavator搭載のSocketFM2+なAPUであるA8-7680に交換してみたくなりますが、ASRock A88-M/G3.1はこれに未対応ということになっています。

CPUコア部分は対応していたとしても、APUに内蔵されるGPUの世代が違うので動く可能性は低そうな気がするのですが…駄目元で試してみたいなあという気もします。(21:30)

23-May-2020補足：未来の自分への覚え書き。多分ここを見ているということはA10-7860Kを他のに変えたいという気分になっていると思うのですが、冷静になりましょう。色々考えた末にA10-7860Kを載せているはずなので、何故そうなったか思い出してみてください。

思い出せない？

OpenBSDを使うことを前提として、Turbo Coreが効かない（ブーストが効かないが内蔵GPUの発熱によるパフォーマンスダウンもそんなに考えなくて良い）こと、radeondrmが使えるという理由です。他のOSで使おうとしているのか、それともより良い選択肢があるというのであれば止めませんけど…でも素直にマシン組み換えた方がいいと思うけどなあ。

古のHDBENCH cloneをイマドキのマシンでも動かせないかなということで、コードを引っ張り出してあれこれいじってます（GitHubへのアップロードに際し、原作者の許可は得ています）。

画面表示周りの修正と./configureスクリプトは更新したんですが（って今FreeBSD-12.1で試したらlibX11の検索がうまくいかない…FreeBSD使っている人ならどうにかできますよね？）…COPY/PRINTによる結果の表示に手を入れるのはなかなか難しそうです。

マシンの性能向上に伴うベンチマークスコアの桁数増加については本家HDBENCHと同様に複数行に分けるとして、dmesgからディスクドライブの名称を収集する部分と、/etc/X11/XF86Configからディスプレイコントローラの名称を得る部分についてはちょっと厄介そうです。

Linuxはrootでないとdmesgで情報を得ることができないのは仕方がないとして、OSの起動速度のチューニング用にタイムスタンプが付いているのを抑止する必要があります（dmesg -tを使えば良いのですが）。

問題はXF86Config。今はXorg.confですが、どちらにせよ今の時代は基本的にこの手の設定ファイルを用意しなくともstartxでXがばばーんと動いてしまうため、参照しようにも参照できません。/var/log/Xorg.0.logは人間が読むにはともかくプログラムが読み出してコントローラ名を得るようには書かれていないので、これを使ってどうにかすることも難しそうです。

という訳で、とりあえず動かせるようにはなったもののその先の仕上げでちょっとつまづいています。57.8kg(21:15)

17-May-2020補足：Puppy Linux導入記録 HDBENCH clone(update 2013.01.12)に、GTK+-1.2→GTK+-2.0対応パッチがあったのを今知ったのですが…このパッチでもPLUGIN部分のボタンレイアウトのズレ対応を行っていますね。

GtkFixed(fixed1)に貼り付けられた、PLUGIN用GtkFrame(plugins)の中にGtkFixed(fixed2)を貼り付けてその中にパーツを配置していくという処理をしているのですが、fixed2内の座標の扱いがGTK+-1.2と2.0とで違うらしく、単にGTK+-2.0化するとこうなります。

パッチではGtkFixed(fixed2)のまま、パーツの座標を変えることで対処しているようですが…自分はPLUGINの隣にあるOPTIONSの表示が崩れていない（こちらはGtkVBox/GtkHBoxを使っている）ならGtkTable(table1)を突っ込んじゃえということでそれで対処しています。なるべくオリジナルに近い見た目となるよう調整してはいるのですが、それでもほんの少し違いがあります。

気になるのはこの記録に記された、hdbench-0.14.99.1.patchなるFedora10用パッチの存在。置かれていたgeocitiesも閉鎖されてしまい、web archiveを漁っても見つからず、どのようなものだったか今となっては知る術がありません。

とりあえず自分は自分なりに、17-Sep-2011のi386依存をなくすパッチを取り込んだ形でまとめていくつもりです。

同じネタを3日引っ張るのは流石に読む方も辛いと思うので一旦ここで止めます。

03-May-2020, 04-May-2020で使った物（ここでは端末Aとします）とは別のAndroid端末（こちらは端末Bにします）で、マイクの周波数特性ごっこをやってみたらこうなりました。

この端末でも5kHz辺りに急激な落ち込みがありますが、二機種ともにこれが出てくるとなるとノイズを再生する側に問題があるのかもしれません。04-May-2020と同様に、録音した物はトリミング以外の処理はしていない状態でWavespectraにかけています。

これは自分の主観ですが、テスト用のノイズを鳴らしたものを録音して得られた結果は、こちらの端末の方が元のノイズに近いような気がします。

録音されたデータを加工してサンプリング周波数を48kHzから8kHzおよび16kHzに落とし、情報量を減らしてみるとどうなるでしょうか。テスト用のノイズも含め、音だけで比較してみます。

• テスト用ノイズ (8kHz) (16kHz)
• 端末A・無加工 (8kHz) (16kHz)
• 端末A・+10dB@2500Hz (8kHz) (16kHz)
• 端末B・無加工 (8kHz) (16kHz)

大体同じような感じになりますかね（端末A・無加工は除く）。

他に把握しておくこととしては、マイクがどの辺りの空間の音を拾いやすいかとか（電話機用なので口元にくるから多分そんなに広くないとは思うけど今はビデオ通話への対応もあるしよく分からない）、PCM録音アプリのレベルメーターの振れと実際に記録される音量レベルの対応とか、その辺？58.85kg(21:55)

03-May-2020で行った、Android端末に入ったマイクの周波数特性測定ごっこ、やり直してみました。PCM録音のマイク感度を調整し、GoldWaveでの加工はトリミングのみとしたものをWavespectraに食わせてみました。

音量調整をしなくてもカーブの傾向は変わらないようです。

まずは2500Hz辺りを持ち上げてみると良さそうに見えます。Goldwaveに限らずイマドキのPCMエディタは色々なイコライザを持っていますが、設定が簡単そうなParametric EQを使い、Center 2500Hz, Width 1000Hz, Gain +10dBで加工してこんな感じにしてみました。

こうなると4800Hz辺りの急激な落ち込みも気になりますが、前回の結果ではあまり気にするほどでもないように見えるのでこちらはこのまま放っておきます。もう少しこだわるならSpectrum Filterでお望みの設定カーブを描けば良いのでしょうけど、そこまでやらなくても良いかな…

今使っているAndroid端末のマイクがこういう癖を持っていることが分かったので、以前使っていた端末も同じ方法で調べてみたいです。58.50kg(21:00)

Podcast風(?)の実験を23-Apr-2020で行ってみましたが、Android端末のマイクの周波数特性ってどんな感じなんだろうと雑なテストを行ってみました。

ノイズを作ってTEAC A-H01-B/LS-WH01-Bで鳴らし、それをAndroid端末で録音。本当はこういう加工をすべきではないのかもしれませんが、録音されたノイズの音量が小さかったのでGoldWaveでトリミングするついでに+10dBの音量調整を入れてこんな感じにした物をWavespectraでチェック。

200Hz〜7kHz辺りまではなんとなく拾うもののそれ以外はあんまり考えていないマイク、のように見えます。あと、特性が全然フラットじゃない。

こんなマイクで録って、300円くらいのUSBオーディオアダプタが出した音を100円ショップのイヤホンで鳴らして編集するような状況では、ちゃんとしたオーディオセットではとても聞けない音質のファイルが出来てもおかしくなさそうです。

とはいえ、自分の喋った声をFreeDV 700D/1600/2020に通すとどんな風に聞こえるかというのを試してみたいので（実はここ数日の日記はその準備だったりします）、そのうち原稿書いて喋ってまとめてみますかね…

ARM基板でLPCNetを動かした場合のベンチマーク、とりあえずすぐに動かせそうなのがBanana Pi BPI-P2(Allwinner H2+, 4×Cortex-A7)だったのでこれにBanana Pi公式のDebianイメージ(2019-10-20-debian-10-lite-k4.19-grub-beta-bpi-m2z-p2z-sd-emmc.img)を突っ込んで試してみました。

うーん、これは厳しそう…58.25kg(20:55)

25-Apr-2020の続き。SSE対応のpull requestはマージされ、色々ベンチマーク取ったりして使い物になるかどうか評価中という状況だと思います多分。

amd64でSSE4.1じゃないとパフォーマンス出ないなーと思っていたのですが、-O3に色々組み合わせたベンチマークを見るに-ffast-math（と-DFLOAT_APPROX）を指定することでamd64だけでなくi386でもSSEでイケるんじゃね？という速度が出ているように見えます。実際に使えるかどうかまでは分かりませんけど。

とはいえ-ffast-mathを付けた場合、何らかの不具合が出てくる可能性も無いとは言い切れないので今後の動向に注意が必要です。あと、アマチュア無銭家なんて冗談言っちゃうような界隈なので、今となっては化石級のマシンでFreeDV 2020（のエンジンとなるLPCNet）を動かしたいという要求が出そうな気がしますが、それは諦めた方が良いです。

FreeDV 700D/1600についてはマイコン(STM32F4)で実装されたSM1000というアダプタが作れる程度には軽いですが、FreeDV 2020はそれとは全く比較にならないくらい計算量が多く、処理が重いのです。マイコンで実装可能なくらいに軽量化されたアルゴリズムや、そのままのコードで動くパワフルなマイコンが登場する可能性に期待したいところです。Raspberry Pi 4などのARM基板で実用的なパフォーマンスが出れば、それを使うのも手かもしれません。

ARM基板でLPCNetを動かした場合のベンチマークも取らないと駄目かなあ…57.80kg(20:25)