8ONEのスピーカーケーブルESC-2100を買った。

サラウンドスピーカーの配線用に、電材屋の切り売りケーブル含め色々と検討したが、白くて細くて手ごろの3拍子揃ってるのは（特に通販では）本製品しか見当たらなかった。片チャンネル10mほど要るので、切り売りでもそれなりのお値段になってしまう。

長尺ということもあり、太さは0.75sq欲しかったのだけど、これといった情報は見当たらず。サラウンド用だし細くてもいっかーと割り切りダメ元で買ってたら、やっぱりダメだった(´・ω・｀)。導体の直径は実測で0.85mmほどの0.5sq相当だった。

ちなみに、被覆含んだ直径は約2.4mm。これなら0.75sqのVFFケーブルで良かったかもしれない…。

まぁ細いだけあって目立たず綺麗に配線できたのでヨシとしよう。結局、片側は10mじゃ足りなくて手持ちの太めのケーブルを継ぎ足すことになったけどな！

• Amazon | 8ONE スピーカーコード 先バラ-先バラ 2本1組 10ｍ ESC-2100 | Eight one | スピーカーケーブル
• 【共立エレショップ】>> 【電子部品・半導体・ケース】/ケーブル/配線材(サムネイル) << 電子部品,半導体,キットの通販
• 配線材の選択と使い方 - My Tube Amp Manual

FreeBSDのネットワークブリッジ機能、if_bridge(4)が遅いってのは以前書いたとおりなのだけど、今後、おおむね5倍に高速化される見込みらしい。

FreeBSD Foundationの記事によれば、現状のif_bridgeは、重いBRIDGE_LOCK mutexのせいで、CPUのコア数によらずスループットは最大3.7Mpps程度に制限される。この度、Kristof ProvostがFreeBSD 13-CURRENT上でロックフリーのepoch(9)を使った実装にしたところ、概ね18.6Mppsのパケットフォワードが行え、5倍の改善となったとのこと。

これはなかなかムネアツ。

一方で、現状の実装でも3.7Mpps出るってことは、最大フレームなら理屈上41Gbpsの帯域を有するハズ。にもかかわらず、iperfの実測で3.5Gbpsほどに止まるのは何でだろーなー。全二重通信で帯域が分割される点を考慮しても低すぎのような気が。

• 5x if_bridge Performance Improvement | FreeBSD Foundation
• epoch - FreeBSD Manual Pages

超絶ハマったのでメモ。

QtのPostgreSQLドライバ（QSqlDatabaseの“QPSQL”）で連続したクエリを大量に発行すると、ポスグレのログに以下のようなログが記録されて正しく実行されない現象に遭遇した。

2020-06-11 19:41:00.598 JST [2593] db@postgres STATEMENT:  DEALLOCATE qpsqlpstmt_10
2020-06-11 19:41:00.633 JST [3924] db@postgres LOG:  SSL error: decryption failed or bad record mac
2020-06-11 19:41:00.634 JST [3924] db@postgres LOG:  could not receive data from client: Connection reset by peer
2020-06-11 19:41:00.634 JST [3924] db@postgres LOG:  unexpected EOF on client connection with an open transaction
2020-06-11 19:41:00.645 JST [3925] db@postgres ERROR:  invalid input syntax for type timestamp: " " at character 77
2020-06-11 19:41:00.645 JST [3925] db@postgres STATEMENT:  EXECUTE qpsqlpstmt_16 (TIMESTAMP WITH TIME ZONE '2020-06-11T10:41:00.634Z', '[, )', FALSE, 0, 0, 0, 0, 0, 10, '', 0, 2020061110480001, 0, 1, 0, 10)
2020-06-11 19:41:00.646 JST [3925] db@postgres WARNING:  there is no transaction in progress
2020-06-11 19:41:56.266 JST [12492] db@postgres LOG:  SSL error: tlsv1 alert protocol version
2020-06-11 19:41:56.272 JST [12492] db@postgres LOG:  could not receive data from client: Connection reset by peer

Qt側のログは消失してしまったが、SSL SYSCALL Resource temporarily unavailableやSSL SYSCALL error: EOF detectedといったエラーが出てDBとのコネクションが破壊され、トランザクションに失敗したりとかそんな感じ。

両方のログから読み取れるのは、クエリ発行時にプログラムとポスグレ間のSSL接続が通信途中で切れたり、データが破壊され変なクエリを実行しようとしたり、SSLの認証に失敗したりしてる。どーしてそんなことが起こるの？

それらしい単語でググると、postgresのSSLを無効にして解決とか出てくるけど、それって何の解決にもなってなくね？っていう。自分が加えた変更以後に発生するようになったので、原因は間違いなく自分ってことだけはハッキリしてる( ˘ω˘ )。

DBドライバとコネクションについて調べ、コードを追ってみたところ、スレッドをまたいで同一のDBコネクションを使ってたのが原因のようだった。一般的に、1つのデータベースコネクションを複数のスレッドで操作するのは禁じ手だそうで、Qtのドキュメントにも

A connection can only be used from within the thread that created it. Moving connections between threads or creating queries from a different thread is not supported.
（訳：コネクションは生成されたスレッドからしか使用できない。コネクションのスレッドをまたぐ移動や異なるスレッドからのクエリ生成は非対応。）

という記述がある。でーびーしょしんしゃなのでしらんかった。

DB操作スレッドで作られ使われていたコネクションに対し、今回メインスレッドからクエリを発行する変更を加え、なおかつ、特定の操作を行うと両スレッドが入り乱れてコネクションを使うために、問題が顕在化したようだった。

というわけで、メインスレッド用に別途コネクションを用意し問題を回避した。解決ではなく回避なのは、かなりアレな設計で緊急措置的な対応だから…。元の構造がアレすぎていい対処方法が思いつかなかったの……。

3月末にeBayで注文したPCパーツが2ヵ月ちょい掛かって、ようやく6/16に届いた。キャリアは4PXだった。

購入時点での配達予定は4/21～6/9で、結果的に予定日を少々オーバーしたものの、この新型コロナ騒動下において無事届いただけでも御の字。6/9には国内に入ってて一応期日は守ってるし、ある意味で優秀なスケジューリング＆荷捌きと言えるかも？

4PXの追跡はこんな感じ。

日本に着いてからの追跡はこんな感じ。

ルータ用にと思って買った小型PCに、トランセンドのM.2 Type 2242なSSD MTS400シリーズの32GB、T32GMTS400が入っていたのでベンチなんぞを取ってみる。公式サイトによると、32GB版のスペックは読み込み200MB/s、書き込み40MB/s、90TBWの2DWPD(3年)となっている。

ディスクの状態は↓こんな感じ。新品で買ったPCの割に電源投入回数と書き込み量が多いような…。

ベンチは↓な感じ。

------------------------------------------------------------------------------
CrystalDiskMark 7.0.0 x64 (C) 2007-2019 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
Sequential 1MiB (Q=  8, T= 1):   279.169 MB/s [    266.2 IOPS] < 29939.73 us>
Sequential 1MiB (Q=  1, T= 1):   268.454 MB/s [    256.0 IOPS] <  3902.29 us>
    Random 4KiB (Q= 32, T=16):   107.224 MB/s [  26177.7 IOPS] < 19488.81 us>
    Random 4KiB (Q=  1, T= 1):    28.066 MB/s [   6852.1 IOPS] <   145.41 us>

[Write]
Sequential 1MiB (Q=  8, T= 1):    53.481 MB/s [     51.0 IOPS] <153808.46 us>
Sequential 1MiB (Q=  1, T= 1):    53.065 MB/s [     50.6 IOPS] < 19666.44 us>
    Random 4KiB (Q= 32, T=16):    53.459 MB/s [  13051.5 IOPS] < 39015.26 us>
    Random 4KiB (Q=  1, T= 1):    52.687 MB/s [  12863.0 IOPS] <    77.35 us>

Profile: Default
   Test: 1 GiB (x5) [Interval: 5 sec] <DefaultAffinity=DISABLED>
   Date: 2020/04/12 13:20:08
     OS: Windows 10 Professional [10.0 Build 16299] (x64)
Comment: Transcend TS32GMTS400

カタログスペック以上の速度は出ているが、最初期のコンシューマ向けSSDと比べても遅めですな…。128GB版でも書き込み160MB/s程度っぽいので、このシリーズはこんなものなのだろう。

• SATA III M.2 SSD | M.2 SSD 400S - トランセンド
• トランセンド SATA接続M.2 SSD MTS400 128GB TS128GMTS400 ベンチマーク – メカニカルマンブログ