2026/07/16(木)椅子の蒸れを解消するのにござを買った

投稿日:

前にデスクチェア探しの終わりで椅子を買い替えたわけだが、以前使っていたNシールドカルカと比べると蒸れやすい問題があり、夏になりちょっと耐えられないレベルになってきたのでござを買って対処することにした。

買って気に入ったもの

ニトリの竹マット(ブルー 45X65 SQ07)を買った。椅子全体を覆うサイズ感があり、胡坐をかいたり、片足を下ろしてもカバーしてくれるので丁度いい。

クッション性もほとんどなく、裏地に薄い布地がある他は、ほぼ竹なため、通気性がいいのが特徴だ。裏に滑り止めがついているため上で動いても滑らないのもいい。

買ったけどイマイチだったもの

竹シートクッション(SQ09)はクッション性があったのと、中綿が少し蒸れてちょっとこれはないなと思った。

チェアシート(Nクール極冷26 ネイビー)は触り心地は悪くないのだが、ちょっと小さすぎるのが残念だった。

2026/07/16(木)R86S U1のNICを交換した

R86S U1のNICについているSFP+ポートの片方が不安定という問題があり、これがずっと悩みの種だった。

しかしR86S U1のNICはOCP2.0のメザニンカードという特殊な規格であり、入手が難しかった。あと最近なんでも高いことや、ここ一年近く財政が悪く資金がショートしていたこともあり、中々購入のタイミングがなかったが、偶然安いのを見つけたので交換を決意した。

購入したもの

ほぼ新品 Mellanox ConnectX-4 CX4421A MCX4421A-ACQN ネットワーク インターフェイス PCIe カード (OCP2.0 用)

ほぼ新品とあるが中古なのは間違いない。

写真を見る限り左右でコネクタが異なるといったこともなく、3,745円でConnectX-3からConnectX-4に上げられて不調もなくなるならアリではないか?と思い、購入することにした。

配送

荷物はいつも通りCainiaoから発送され、国内ではエスポ便という聞いたこともない業者に引き渡された。軽く調べたところ株式会社エスポリアという越境ECのサービス会社がやっているようで、ここ最近のアリエクに増えているらしい。ここ自体は仲介業者で配送はしてないらしい。

そういえば最近中華特有のテカテカしたプチプチ袋減った気がする。

実際の配送はかつてAmazon便で悪名を馳せたTMG、椿本グループだった。久々に見たので、一般消費者向け宅配便事業で生きてたのかお前…となった。

開封の儀

結構ちゃんとした箱に入っていた。

中身。緩衝材が底にあり、本体も一応元袋らしきものに入っていた。いい感じのヒートシンクがついているのが素晴らしい。

賞味期限ラベルみたいなものが貼ってあったが非常に強力なシールで、爪でカリカリすると爪が削れるレベルで剥がせなかったため剥がすのを諦めた。

新旧比較をすると上が今まで使っていたやつで、下が今回新たに買ったやつだ。

裏返したところ。裏面には薄いアクリルフィルムが基板を保護するように付いていた。短絡防止用だろうか?ヒートシンクを支えるプッシュピンも見えた。

ラベルを見る限り2019年6月製とみられ、比較的新しい製品なのも嬉しい。以前使っていたConnectX-3は製造時期不明だがCX342Aは2015年のモデルらしいので、だいぶ古い。

どこで見たか記憶にないがConnectX-3はサポート切れが近いか、切れていることもあるという話も見た気がするのでConnectX-4を入手できたのはよかった。メイン機もサーバー機もNICはConnectX-4なのでお揃いになった。

装着は既存のConnetX-3を外し、カードを刺す場所に元々ついてたチップクーラーを除去して取り付けたら、そのまま何事もなく普通に装着できた。

このクーラーがあるとヒートシンクに干渉するので、外す必要があった。

OpenWrt上でのセットアップ

OpenWrt 24.10.0にはドライバがなかったのでドライバを入れるのをやっていく。

SFP+以外に接続手段のない私の環境ではルーターのSSHに繋ぐ術がなかったので、R86S U1本体にキーボードとモニタを接続して作業した。

# まずはNIC周りの調査ツールを入れる
opkg update
opkg install pciutils ethtool

# ドライバの状態とかが見れる
# Kernel driver in use: igcならドライバがない
lspci -nnk

# ドライバを入れる。kmod-mlx4-coreは後で消した
opkg install kmod-mlx5-core
# JISキーボードだとアンスコが出せないので頑張って探して打った
modprobe mlx5_core

あとはこのまま再起動したら普通に繋がった。

そのまま使うと温度が上がりすぎた

現状片側のSFP+しか使っていないうえ、それも初日なので不具合は何もない。以前使っていたのも最低でも一週間は使ってないと不安定化しなかったので、まだ安定性は不明だ。

ただソケットが両方とも同じ形に見えるので、以前使っていたものよりは安定するのではないかと考えている。

温度については高くなりがちなようで、R86S U1本体のCPU温度が51度に達することもあった。

以前のNICの温度はデータがなく比較できないのだが、ここまで上がっていることはなかった気がしている。

NIC本体の温度は取得する方法が今のところ分かっていない。mstflintでmstflint -d xxxx -reg_name MTMPとかしたら、提供されていないとか出た気がするがログは取っていない。

参考までに以下の手順でレジスタの値が取れるっぽい。参考:man/mstreg

# 必要なツールのインストール
opkg install lspci mstflint
# MellanoxのデバイスIDの取得
lspci | grep Mellanox | awk '{print $1}'
# レジスタ名一覧
mstflint -d <デバイスID> -show_regs
# レジスタ値の取得
mstflint -d <デバイスID> -reg_name <レジスタ名> -g

関係ないがデータがないのはGrafanaに出しているデータを永続化していないため、tmpが吹き飛ぶと消える状態なので、ここはそのうち何とかしないといけない。

冷却対策

端的に言うとヒートシンクを剥がし、R86S U1に元からついてるクーラーを装着した。

まずはConnectX-4を取り出し、ヒートシンクを外し、グリスを塗りなおす。この時ついでに裏のフィルムも剥がし、熱が溜まらないようにした。

R86S U1に元々ついてたチップクーラー(前述の奴)を持ってきて、付け直した。

ファンレス冷却(ヒートシンク)とファン冷却(クーラー)で同時刻に温度を比べたところ、5度ほど下がるという結果が出たので、かなり効果があった。

新しい奴のヒートシンクの方が目が細かく作りもしっかりしているように見えるが、風のあるなしがそれほどまでに大きいということだろう。

しょぼいヒートシンクと小さいファンの組み合わせなのであまり意味がないだろうと侮っていたが、結果は歴然だった。恐らくこれはケースが小さく通気の余地が少ないこともあり、自然対流には期待できないということの表れなのだろう。

ベンチマーク

以下の構成で速度を計測した結果。そもそもLAN内でパケットがルーターの中を通っているかが謎なのでルーターNIC交換の影響があるかどうかは不明である。

Windows - R86S U1 - MikroTik CRS305-1G-4S+IN - Ubuntu

以前の計測結果はこっち

Windows → Ubuntu

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec  1.07 GBytes  9.13 Gbits/sec
[  5]   1.01-2.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   2.01-3.00   sec  1.08 GBytes  9.36 Gbits/sec
[  5]   3.00-4.00   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   4.00-5.01   sec  1.10 GBytes  9.36 Gbits/sec
[  5]   5.01-6.00   sec  1.08 GBytes  9.36 Gbits/sec
[  5]   6.00-7.01   sec  1.10 GBytes  9.36 Gbits/sec
[  5]   7.01-8.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   8.01-9.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   9.01-10.00  sec  1.08 GBytes  9.36 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  10.9 GBytes  9.34 Gbits/sec                  sender
[  5]   0.00-10.00  sec  10.9 GBytes  9.33 Gbits/sec                  receiver

Ubuntu→Windows

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.08 GBytes  9.30 Gbits/sec    0   1.54 MBytes       
[  5]   1.00-2.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.62 MBytes       
[  5]   2.00-3.00   sec  1.08 GBytes  9.27 Gbits/sec    0   1.70 MBytes       
[  5]   3.00-4.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   4.00-5.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   5.00-6.00   sec  1.08 GBytes  9.29 Gbits/sec    0   1.78 MBytes       
[  5]   6.00-7.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   7.00-8.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
[  5]   8.00-9.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
[  5]   9.00-10.00  sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  10.8 GBytes  9.28 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  10.8 GBytes  9.28 Gbits/sec                  receiver

まとめ

前回と比較すると若干速度が落ちているが、サーバーとして動かしてて帯域を食っている分減っているのかもしれない。

Windows→Ubuntu(上り) Windows→Ubuntu(下り) Ubuntu→Windows(上り) Ubuntu→Windows(下り)
9.34 Gbps 9.33 Gbps 9.28 Gbps 9.28 Gbps

交換前のConnectX-3が改造品だった話

以前使っていたPCB000620は元々SFP+片ポートモデルで、どうやらR86S U1では2ポートに改造していたようだ。

その影響なのか明らかに片方だけソケットの形が異なる。上側のほうが綺麗で、下側は使いこまれているのか、ややぼろ目に見える。

裏面を見ると片方ははんだ付けされているが、片方は差し込んであるだけ。シールも一度剥がしたものを貼り付けているのか、ペラペラしていてすぐに剥がせた。

おそらく上側(PORT 0)のはんだ付けされていた方が本来のソケットで、後から付けたやつ、つまり下側(PORT 1)が差し込んだだけの奴と思われる。

本来のソケットがぼろい方、後付けのが綺麗な方である。

奥の方の作りも異なる。左がPORT 0、右がPORT 1。

R86S U1のNICについているSFP+ポートの片方が不安定だった話で不安定だったのはPORT 1の方なので、改造して無理に取り付けていた方が不具合を発していたのだろう。本来できないことをしているので無理もない。

裏面の形も異なる。

恐らくよくある片ポートの奴にソケットを増設したのだと思う。

ソケットが片ポートしかなくても回路が実装されていることはよくあるので、この回路を流用しているのだと思う。回路もあるし、チップも恐らく同じなので原理的には問題なく動きそうに思える。

R86S U1のSFP+を使い始めたのは2025年の9月17日からだった[1]が、同年12月13日にはリンクアップとリンクダウンが繰り返される事象を確認していて、同年12月25日にSFP+差し込みポートの変更を行ってからは一度も起きていない。

この時の気温が落ちたので金属製のSFP+ソケットの接触不良になったのではないか?と考えていたが、恐らくソケットではなく、基板本体との接触が寒暖差でダメになったのかもしれない。実際、先ほどの写真を見ても基板の穴からピンが出たり出ていなかったりするので、寒暖差でここが僅かに狂った結果、基板と接触不良になり、回路がチャタリングした結果、リンクアップとリンクダウンをミリ秒単位で繰り返す状態が起きていたのかもしれない。

もし、この理屈が正しければ強く押し込んではんだ付けすれば改善しそうではある。

あとがき

NIC交換の時に取り出した時、酷い埃まみれになっていたのでいい加減、冷却面をどうにかしたい気がしている。

普段は上に80mm角ファンを載せて運用しているため、埃の元凶はこれである。一旦はファンフィルターを買ってその場を凌ぎたいところだが、本質的にはちゃんとしたケースに収めてちゃんとしたクーラーをつけるのが最良だと思っている。

R86S U1を冷やそうとした作業の残渣にも書いているが、R86S U1の冷却機構は耐久性があるように見えず、また大して冷やしてもくれない。上にファンを載せて風を入れていると、いつの日か中が埃まみれになってしまうし、このケースはメンテナンス性が良くないので清掃も面倒だ。

理想論としてはこんな感じのケースに組み込めればよいだろう。これならメンテナンスがしやすいし、NICのヒートシンクも元の奴が生かせそうだ。ファンも40mm角ファンだろうから壊れても交換が容易である。

まぁこれは行き過ぎとしても、ラズパイのタワークーラーを載せるとか、そういうのができるとよいなとは思っている。基板むき出しは埃が溜まってショートしそうなので、ケースもあった方がいいだろう。

ただそれをどう実現するかが難しいところで、まず本来的には3D CADでケースやCPUクーラーをモデリングし、CNCで金属を削るという工程が必要だろうが、そんなものはないし、仮に3Dプリンタである程度何とかするにしても、3D CADの使い方を学ぶところからだと気が遠くなる話で、なかなか難しい…。

そもそもノギスで測っても測るたびに数ミリ単位の誤差が出るので、アナログな図面を書くことすら困難だ(多分ノギスの角度が微妙に毎回ズレてる)

こんなことであれば去年アリエクのセールでファンレスのR86SであるR86S-FLN100を買っておけばよかった。今は22.7万もするが、去年は11万くらいで、セールでは9万にまで落ちていて、買いだった。まぁあとからは何とでも言えるし、そもそも9万でも安くないわけで、言ったところで仕方がない。

現実案としては厚紙にボードを固定して外枠をペンで引き、ネジ穴については基板のネジ穴スレスレの何かを差し込んでマーキングすればそれなりに正確なものが取れるだろうから、一度手書きで図面を書き、それを基にアクリル板を加工し、簡単なケースを作るのが一段階目としてはよさそうな気がする。

ただCPUクーラーをどうするかという問題が根深く、ここが難点になると思う…。これはCPUクーラーを作るにはCPUのヒートスプレッダに乗ってくれるヒートシンクを持ったファンと、そのファンと基板のネジ穴を繋ぐ足が必要になるからだ。ヒートシンクと基板のネジ穴がマッチしないとならないので、恐らくこれが一番の難関だろう…。

たぶん厚紙→アクリル板がいければ図面を起こせるので、カスタムアルミケース業者に発注すれば、きちんとしたものも作れると思う。そこまでやるかどうかは未定だが…w


  1. 宅内に10GbE環境を導入してみたの写真のタイムスタンプから推定。

2026/07/09(木)日本語に由来するプロダクト名や製品名、企業名の一覧

更新日:
投稿日:

最近日本語に由来しているプロダクト名や製品名、企業名を見かける頻度が増えたのでまとめてみた。クールジャパンの影響か何かは不明だが、意外と日本語由来の名称は多い。

探しても意外と見つからないので、日々の生活の中で見つける中でメモってきたものをまとめている。最後の方は根拠が薄い。しかしこの記事を書こうと思い二ヶ月ほど集めていたが、そこそこ集まったと思う。

Matomo

Matomo

恐らく世界で最も使われているセルフホストのアクセス解析。

日本語の「まとも」に由来している。「まともなアクセス解析」ということである。

Matomo means honesty in Japanese. We believe this reflects the culture of our community, contributors and staff, who are dedicated to delivering the most valuable and user-centric digital analytics platform.

Matomo Analytics - privacy-friendly analytics, CRO, SEO and Tag Manager

Umami

Umami

セルフホストのアクセス解析。

特に明言されていないがアイコンがご飯を盛った茶碗なので、日本語の旨味に由来していることが分かる。

Bulma

Bulma

有名なCSSフレームワーク。

ドラゴンボールの登場人物の一人、ブルマに由来している。

Did Dragon Ball have anything to do with naming it?

Absolutely.

Initially, the project was supposed to be a theme generator named Trunks but trunks.io was unavailable.

I imagined dividing the generator into "capsules" that you would choose a selection from to generate the theme you want. That's where the name Bulma came into mind, as her father founded Capsule Corp.

what is the motivation for this project? · Issue #17 · jgthms/bulma

Onsen UI

Onsen UI

Web UIフレームワーク。

特に明言されていないがアイコンが温泉マークなので、日本語の温泉に由来していることが分かる。

Jinja

Jinja

Python製テンプレートエンジンのデファクトスタンダードともいえる存在。

特に明言されていないがアイコンが鳥居なので、日本語の神社に由来していることが分かる。恐らくTempleとTemplateを掛け合わせた洒落だろう。

HCL

HCL

AWSなどのクラウドインフラを管理する上ではデファクトといっても過言ではないIaaS。

作者の橋本さんの名字から取られているので一応日本語由来と言える。ちょっとこれは無理があるかもしれない。

HCL and HIL originate in HashiCorp Terraform, with the original parsers for each written by Mitchell Hashimoto.

MeCab

MeCab

日本語の形態素解析エンジンでは最も有名なものだと思う。

由来はわかめの根っこの部分、ぬるぬるコリコリしたあのめかぶ。

Mozc

Mozc

Google日本語入力の元になったと言われるIMEシステム。かつてはLinux系のデスクトップ環境のIMEの定番だったが最近は揺らぎつつあるという話も…?

由来は沖縄で主に生産されている海藻のもずくだと思われるが、特に明言されていない。

Anthy

Anthy

かつて日本語Linux環境でデファクトスタンダードだったIME。

Wikipediaによると由来は少女革命ウテナの登場人物、姫宮アンシーからとのこと。

Oniguruma

Oniguruma

恐らくPCREに次ぐ知名度を誇る正規表現エンジンだったもの。かつてはPHPの正規表現エンジンだったこともあった。2025年で開発が終了している。開発者は日本人。

由来は鬼車。意味がある言葉なのかは謎。

Namazu

Namazu

昔よく使われていた日本語全文検索エンジン。かつて規模が大きめのPerl CGIに搭載されていた。

由来は魚のナマズ。

Noto

Noto - Google Fonts

Googleのフォントシリーズ、Noto <書体> <言語名>というフォントが存在し、ほとんど大抵の言語でゴシック体(Sans-serif)と明朝体(Serif)のフォントをカバーしている。

由来としては豆腐文字をなくすところにあるとされており、ノー豆腐から来ている。

The name is also short for "no tofu", as the project aims to eliminate 'tofu': blank rectangles shown when no font is available for your text.

Bento.me

Bento.me

リンクアグリゲーター。弁当箱の中身のようにコンテンツを配置してレイアウトできるのが特徴だった。

特に明言されていないがアイコンが弁当箱なので、日本語の弁当に由来していることが分かる。

Linktreeに買収されたはずなのに復活していた。

Raku

Raku

プログラミング言語。本来Perl 6となるはずだったが、大人の事情でRakuに改名されたもの。恐らく改名の理由としてはPerlという名前が世界的に非常に悪い印象を持っていたせい。

Rakuの名前に関する議論では、日本語での読み方が提唱されていることから、Rakuは日本語に由来しているとみてよいと思う。

I'm pretty sure that Raku is pronounced らく. I hope you're all up for pronouncing [ɾ].

また後述するがRaku言語の実装であるRakudoは確実に日本語に由来しており、RakudoのRakuを切り取ったのがRaku言語だと思われるので、日本語に由来といっても過言ではないと考える。

参考までにPerl6のIRCログでは「Raku」が完全に日本語と紐づけられた文脈で語られており、YAPC-JPの話さえ登場している。

Rakudo

Rakudo

プログラミング言語Rakuのコンパイラ。RakuはJavaScriptやC言語のように仕様だけが存在する言語なので、実装としてRakudoが存在する。昔はPerl v6と呼ばれていたが、Perlと決別して別の道を歩み始めたらしい。

明確な一次ソースが見当たらないがuse Perlの記事によると次のようにある。

Some years ago, Con Wei Sensei introduced a new martial art: "The Way
Of The Camel". Or, in Japanese: "Rakuda-do". This name quickly became
abbreviated to "Rakudo", which happens to mean "paradise" in Japanese.

要約すると「Perlのマスコットはラクダだが、Perlをラクダの道と表現する場合、日本語では駱駝道になる。そしてラクダドウを省略して呼ぶと楽土となり、これは天国を意味する。」ということだ。

Raku言語の公式サイトにも次の記述がある。

Rakudo is the name of a Raku implementation that runs on MoarVM and the JVM. It is an abbreviation of Rakuda-do, which, when translated from Japanese, means "The Way of the Camel". Also, in Japanese, "Rakudo" means "Paradise."

Hanko

Hanko

認証基盤。

特に明言されていないがアイコンが判子なので、日本語の判子に由来してことが分かる。

Itamae

Itamae

日本製と思われる構成管理ツール。

特に明言されていないが日本人が作っていることや、組織名がitamae-kitchenであるため、日本語の板前に由来していることが分かる。

MEGANE

MEGANE

ルノーの自動車製品。

Wikipediaによると日本語の眼鏡を意識して命名されたらしい。日本語読みは「メガーヌ」。

SharkNinja Operating, LLC

SharkNinja Operating, LLC

アメリカにある家電メーカーの会社名。掃除機で有名なSharkの社名のフルバージョン。

Ninjaという単語が日本語以外由来である可能性が考えづらいので、恐らく日本語と思われる。

Ninjaというクッカーも出しているので、一応これは製品名と言える。ヤマダ電機やエディオンの店頭では見なかったが、ケーズデンキには置いてあった。

Atari

ゲーム開発の会社。アタリショックという社会現象を引き起こしたことで知られる。

公式情報ではないがWikipediaの記事には次のようにあり、日本語が由来であると考えられる。

社名は囲碁の日本棋院初段を持つブッシュネルが囲碁用語「アタリ」から取った

Zen

AMDのRyzen CPUに採用されているマイクロアーキテクチャ。

一般論として「禅」であるとされているが公式資料が見つからなかった。

PCWorldの記事には次の一文があり、日本語の書かれた円相の写真もあることから、日本語由来である可能性がある。

The font adheres to Zen principles

Ryzenのパッケージに円相が書いてあるのも恐らくその関係。

あとがき

はてなとか、日産サクラとか、あからさまなものは除外しているが、その割にNamazuが入ってるし選定基準は我ながら恣意的だなと思った。

2026/07/08(水)SDカードを買い替えたらRW速度が改善した話

更新日:
投稿日:

Xperia 1 VIからXperia 1 VIIIに買い替えてからファイルマネージャー+でのSDカードの読み込みが露骨に遅くなった。今までならSDカードの中身が瞬時に表示されていたところ、数秒かかるようになったのだ。

そこでSDカードを買い替えてみたらよくなったので、その記録。

買い替えようと思った切っ掛け

ふとカメラアプリを眺めていたら高速書き込み可能なSDカードという表記があり、もしや使っているSDカードの規格が古すぎて最新のスマホだと相性で遅くなるのかもしれないと思い、SDカードを買い替えることにした。

今回買ったSDカード

SDカードといってもスマホ用なのでmicroSDカードだが、一般的にSDカードと呼ばれていると思うので、本記事ではSDカードで統一する。

Biwin microSDカード MS210 128GBというのを買った。 210MB/s読出・170MB/s書込らしい。

聞いたことのないメーカーだったがググると企業サイトが存在し、実在の企業でありそうなこと、価格コムに掲載のあるメーカーであることから問題ないと判断した。それに仮に問題があったとしても安いし、地雷踏みと思って買えばいいレベルの値段なので気にならない。

他のメーカーだと6,000円から1万円強ほどするグレードの製品だと思うが、Biwinのは私が買った時点では3,781円と安価だった。というか他が高すぎるだけな気もするが…。

これまで使ってたSDカードとの比較

左が今回新しく買ったBiwin、右がこれまで使ってたSanDisk。

スピードクラス10のマークが消え、ビデオスピードクラス30が増え、UHSスピードクラスが1だったのが3になり、アプリケーションパフォーマンスクラスも1から2に増えている。かなりのスペックアップだ。

SanDiskの方は購入当時1,880円で、買ったときは余りの安さにAmazonから偽物が送られてくるという噂があったほどの人気モデルだった。購入履歴を見ると、SanDiskのやつを買ったのは6年前だったようだ。

高くなってしまったSDカード

AmazonでSDカードを見てみるととんでもない価格になっている。メモリ高騰の影響をしみじみと感じる価格だ…。

以前使っていた1,880円で買ったSDカードも今見たら6,801円にもなっていて、中々えげつない。

今回の購入品はビデオスピードクラス30・UHSスピードクラス3・アプリケーションパフォーマンスクラス2の128GBで3,781円なので大変お買い得と言える。レキサーメディアのなんか5,880円もする。

余談だがSONYストアでは、かつて今回買ったものと同一グレードの品が2,680円で売られていたようなので、今回の3,781円でも高い方なのかもしれない。

増えた謎のメーカー

今回見ているとBiwinを始め、GIGASTONEやNextorageといった聞いたことがないメーカーが目立った。Biwinについては先述したが、どれもしっかりしたメーカーのようだ。

例えばGIGASTONEは日本法人を持っていて、オフィスがあるようだし、NextorageはSONYのメモリストレージ部門が独立してできた会社らしい。

しかしかつてSamsungやTranscendが辿ったように、SanDiskもすっかり激安メーカーから普通のメーカーになってしまった。今はかつてのSanDiskの地位にBiwinがいる感じだろう。時代の変遷を感じざるを得ない。

あとがき

ひとまず様々な記憶媒体が高騰する中、そこそこお安い価格でSDカードを買うことができ、読み込みの遅さも解決したので良かった。ついでに今時のストレージメーカー事情も知れて一石二鳥だ。

そういえば小学生の頃に、いつしか小指の先程の大きさで1TBのストレージが出るというのを吹聴していたが、いつの間にかmicroSDに1TBが出ていたので現実になっていることに気がついた。SDXCの規格上は2TBが上限なので、存在すること自体に不思議はないが、あくまで大きい方のSDカードの話だと思ってただけに意外だった。

調べたら今はSDUCと言って32TBまでの規格があるらしい。NANDは基本的に本来の容量より過剰にセルを積むことで書き込み回数を増やしてるので、32TBなんてすぐ壊れそうだが、大丈夫なんだろうか…。

あと全然関係ないけど既に今年の記事数が156記事に達し、2024年の153記事を超え、2025年の165記事に迫っていることに軽く戦慄している。まだ今年の半分が過ぎ去ったばかりだというのに、何とも恐ろしいペースだ…。主に先月が凄まじいが、今月も既に1日1記事ペースを超えてるので、恐ろしいペースである…。

書きたいネタが無尽蔵にあるので減速するかどうかは謎だが、幸い今週末は土日とも遠征予定があり、来月にも遠征予定があるので減速するかもしれないし、しないかもしれない…。

Mastodonの方にはちょろっと書いたけど、サイト設立から25周年経過したというネタも記事に出来てないんだよなぁ…。

2026/07/08(水)ASUS RT-BE92Uなど一式を買ったのでセットアップログとか

折角LAN内10GbEにしたし、WiFi7が出てずいぶん経つし無線LAN環境も充実させたいよなぁ…と思い、WiFi7対応のWANポート10GbE対応ルーターとしてASUS RT-BE92Uを買ったので、その関連のログ。

今回買ったもの

開封の儀

ASUS RT-BE92U

箱を開けるとこんな感じ。紙の繊維を圧縮したようなケースや紙箱に入った、最近ではよくある梱包。

付属品は壁掛けフック、ACアダプタ、壁掛けフックを固定するネジ、CAT6 LANケーブル。

LANケーブルは同梱品にありがちな極太で硬そうなやつ。

ASF-10G-T80

トランシーバーは金属製の缶に入っており、やたら凝っていた。

手持ちのCAT6Aケーブルを挿すとこんな感じ。

設置後の風景

Before After

びふぉーの写真が去年のものなので完全に前後の写真という訳ではないが、大体こんな感じということで…。

例えばBeforeとAfterでは右側から伸びているコンセントの本数が違うが、これは今回の施工とは関係なく、もっと前に配線変更で減らしたものである。

セットアップの儀

地味にハマるポイントがあり、苦労した。

  1. まずL2スイッチにWANポートを接続しセットアップを始めた
  2. 192.168.50.1が初期IPで、このIPがあることを確認して、http://192.168.50.1に接続するものの何故か繋がらない
  3. http://www.asusrouter.comに繋げとマニュアルにあったので繋ぐが繋がらない
  4. http://192.168.50.1:8443/に繋ぐといい情報を得たが繋がらない
  5. http://www.asusrouter.com:8443/にも繋がらない
  6. https://192.168.50.1:8443/にもhttps://www.asusrouter.com:8443/にも繋がらない
  7. 有線だから悪いのかと思い、WiFi経由で接続を頃見るが繋がらない
  8. WANポートの線を抜きスタンドアロンにして、WiFi経由で同じことをやり直したがやはり繋がらない
  9. しかしWiFiのデフォルトゲートウェイは192.168.50.1を挿していた
  10. ブラウザ経由で操作できないのはなんとも承服しがたいがASUS Routerアプリを試すことにした
  11. アプリを起動しルーターに接続すると「モデルをルーターのWANポートに接続したことを確認してください。」というメッセージが表示され、プログレスバーが100%になるとエラーで死んだ
  12. リトライすると通ったので無視することにした。WANに直接刺さってないと上手く動かないのかもしれない
  13. ISPがどうのこうのなどWAN前提のメッセージが何度か出たが全部無視した
  14. WANの種類を選べと言われたがAPにWANもクソもないのでDHCPのまま進めた
  15. 「ネットワークを再アクティブ化」というのが出たので数分見守った。再起動してるだけだと思う
  16. 動作モードをタップ
  17. アクセスポイントモードを選択し適用
  18. ここまで行うとブラウザからhttp://192.168.50.1への接続に成功したが、あんまり納得できなかった
  19. 管理画面に入ったら詳細設定→LAN→スイッチ制御に遷移しジャンボフレーム有効をON
  20. 管理→システム→サービス→SSHを有効にする、で「LAN only」
  21. SSHのポートを適当に指定し、パスワードログインを許可「いいえ」、認証済みキーに公開鍵を貼り付けて設定
  22. ここから先はSSHに入れた
  23. OSはBusyBox v1.24.1で、何故かIPv6がなく、iperf3が最初から入っていた。どうやらこのルーターにはIPv4でアクセスするしかなさそうだ
  24. ホームディレクトリは/tmp/home/rootで、再起動したら消えそうな勢い
  25. ルートディレクトリは以下の構成で、ルートにはASUS関連のファイルが直置きで散らばっていた
    /.diag
    /.sdn
    /asusdebuglog
    /asusfbsvcs
    /avahi
    /bwdpi
    /cfg_mnt
    /confmtd
    /dm
    /etc
    /home
    /mnt
    /nc
    /netool
    /notify
    /share
    /var
    

速度計測

AP・サーバー間の通信測定

APからサーバーに飛ばしたiperf3の測定結果。構成は以下の通り、速度はその口がサポートしている最大を記載。

なお、このケースではAPのCPU使用率が100%に張り付いていた。

  1. [AP] RT-BE92U (OUT RJ-45 10GbE)
  2. [LANケーブル] CAT 6A RJ45 LAN (CAT6A 10GbE)
  3. [トランシーバー] ASF-10G-T80 (10GbE)
  4. [L2SW] MikroTik CRS305-1G-4S+IN (SFP+ 10GbE)
  5. [DAC] 10Gtek CAB-10GSFP-P0.5M-30 (SFP+ DAC 10GbE)
  6. [NIC] Mellanox ConnectX-4 Lx (SFP+ 10GbE)
  7. [サーバー] Ubuntu 24.04.4 LTS
[物理線経由] AP → サーバー
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 448 MBytes 3.76 Gbits/sec 0 467 KBytes
[ 4] 1.00-2.00 sec 455 MBytes 3.81 Gbits/sec 0 467 KBytes
[ 4] 2.00-3.00 sec 449 MBytes 3.77 Gbits/sec 0 3.61 MBytes
[ 4] 3.00-4.00 sec 428 MBytes 3.58 Gbits/sec 0 3.79 MBytes
[ 4] 4.00-5.00 sec 450 MBytes 3.78 Gbits/sec 0 3.79 MBytes
[ 4] 5.00-6.00 sec 461 MBytes 3.86 Gbits/sec 0 3.79 MBytes
[ 4] 6.00-7.00 sec 465 MBytes 3.91 Gbits/sec 0 3.79 MBytes
[ 4] 7.00-8.00 sec 456 MBytes 3.83 Gbits/sec 0 3.79 MBytes
[ 4] 8.00-9.00 sec 462 MBytes 3.88 Gbits/sec 0 3.79 MBytes
[ 4] 9.00-10.00 sec 448 MBytes 3.75 Gbits/sec 0 3.79 MBytes
[ ID] Interval Transfer Bitrate Retr
[ 4] 0.00-10.00 sec 4.42 GBytes 3.79 Gbits/sec 0 sender
[ 4] 0.00-10.00 sec 4.42 GBytes 3.79 Gbits/sec receiver
[物理線経由] サーバー → AP
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 5] 0.00-1.00 sec 280 MBytes 2.35 Gbits/sec 11 406 KBytes
[ 5] 1.00-2.00 sec 292 MBytes 2.45 Gbits/sec 7 400 KBytes
[ 5] 2.00-3.00 sec 324 MBytes 2.72 Gbits/sec 17 354 KBytes
[ 5] 3.00-4.00 sec 318 MBytes 2.67 Gbits/sec 19 387 KBytes
[ 5] 4.00-5.00 sec 309 MBytes 2.60 Gbits/sec 17 320 KBytes
[ 5] 5.00-6.00 sec 302 MBytes 2.53 Gbits/sec 13 293 KBytes
[ 5] 6.00-7.00 sec 312 MBytes 2.61 Gbits/sec 21 413 KBytes
[ 5] 7.00-8.00 sec 312 MBytes 2.62 Gbits/sec 15 414 KBytes
[ 5] 8.00-9.00 sec 322 MBytes 2.70 Gbits/sec 7 400 KBytes
[ 5] 9.00-10.00 sec 287 MBytes 2.41 Gbits/sec 8 370 KBytes
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.99 GBytes 2.56 Gbits/sec 135 sender
[ 5] 0.00-10.00 sec 2.98 GBytes 2.56 Gbits/sec receiver

ノートPC

ノートPCとサーバーをAPを挟んで繋いだ時のiperf3の測定結果。

[WiFi経由] ノートPC → サーバー(旧AP)

従前のAPを利用し、ノートPCからサーバーに飛ばしたiperf3の測定結果。構成は以下の通り、速度はその口がサポートしている最大を記載。

  1. [ノートPC] Windows 11 Home (WiFi 6E)
    • NEC Lavie PC-GN20D72DYEDYH2YAA
  2. [旧AP] WSR-1800AX4P (IN Wi-Fi 6→OUT 1GbE LAN)
  3. [LANケーブル] CAT 6A RJ45 LAN (CAT6A)
  4. [L3SW] R86S U1 (IN RJ45 2.5GbE→OUT SFP+ 10GbE)
    • ここでRJ45とSFP+をソフトウェアでブリッジしている(こいつにはNICが2枚刺さってる
  5. [L2SW] MikroTik CRS305-1G-4S+IN (SFP+ 10GbE)
  6. [DAC] 10Gtek CAB-10GSFP-P0.5M-30 (SFP+ DAC 10GbE)
  7. [NIC] Mellanox ConnectX-4 Lx (SFP+ 10GbE)
  8. [サーバー] Ubuntu 24.04.4 LTS
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 15.2 MBytes 128 Mbits/sec
[ 5] 1.00-2.00 sec 16.6 MBytes 139 Mbits/sec
[ 5] 2.00-3.02 sec 16.1 MBytes 134 Mbits/sec
[ 5] 3.02-4.01 sec 15.9 MBytes 133 Mbits/sec
[ 5] 4.01-5.01 sec 15.9 MBytes 133 Mbits/sec
[ 5] 5.01-6.02 sec 13.6 MBytes 114 Mbits/sec
[ 5] 6.02-7.01 sec 14.4 MBytes 121 Mbits/sec
[ 5] 7.01-8.01 sec 14.8 MBytes 124 Mbits/sec
[ 5] 8.01-9.01 sec 13.0 MBytes 109 Mbits/sec
[ 5] 9.01-10.01 sec 12.9 MBytes 108 Mbits/sec
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec   148 MBytes   124 Mbits/sec                  sender
[  5]   0.00-10.03  sec   147 MBytes   123 Mbits/sec                  receiver
[WiFi経由] ノートPC → サーバー(新AP)

今回購入したAPを利用し、ノートPCからサーバーに飛ばしたiperf3の測定結果。構成は以下の通り、速度はその口がサポートしている最大を記載。

  1. [ノートPC] Windows 11 Home (WiFi 6E)
    • NEC Lavie PC-GN20D72DYEDYH2YAA
  2. [新AP] RT-BE92U (OUT RJ-45 10GbE)
  3. [LANケーブル] CAT 6A RJ45 LAN (CAT6A 10GbE)
  4. [トランシーバー] ASF-10G-T80 (10GbE)
  5. [L2SW] MikroTik CRS305-1G-4S+IN (SFP+ 10GbE)
  6. [DAC] 10Gtek CAB-10GSFP-P0.5M-30 (SFP+ DAC 10GbE)
  7. [NIC] Mellanox ConnectX-4 Lx (SFP+ 10GbE)
  8. [サーバー] Ubuntu 24.04.4 LTS
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 128 MBytes 1.07 Gbits/sec
[ 5] 1.00-2.00 sec 126 MBytes 1.06 Gbits/sec
[ 5] 2.00-3.01 sec 127 MBytes 1.05 Gbits/sec
[ 5] 3.01-4.01 sec 123 MBytes 1.03 Gbits/sec
[ 5] 4.01-5.01 sec 130 MBytes 1.09 Gbits/sec
[ 5] 5.01-6.01 sec 127 MBytes 1.06 Gbits/sec
[ 5] 6.01-7.01 sec 146 MBytes 1.23 Gbits/sec
[ 5] 7.01-8.01 sec 139 MBytes 1.16 Gbits/sec
[ 5] 8.01-9.01 sec 137 MBytes 1.15 Gbits/sec
[ 5] 9.01-10.01 sec 124 MBytes 1.04 Gbits/sec
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec  1.28 GBytes  1.09 Gbits/sec                  sender
[  5]   0.00-10.03  sec  1.27 GBytes  1.09 Gbits/sec                  receiver

スマホ

スマホとサーバーをAPを挟んで繋いだ時のiperf3の測定結果。

[WiFi経由] スマホ → サーバー(旧AP)

従前のAPを利用し、スマホからサーバーに飛ばしたiperf3の測定結果。構成は以下の通り、速度はその口がサポートしている最大を記載。

  1. [スマホ] Xperia 1 VIII (WiFi 7)
  2. [旧AP] WSR-1800AX4P (IN Wi-Fi 6→OUT 1GbE LAN)
  3. [LANケーブル] CAT 6A RJ45 LAN (CAT6A)
  4. [L3SW] R86S U1 (IN RJ45 2.5GbE→OUT SFP+ 10GbE)
    • ここでRJ45とSFP+をソフトウェアでブリッジしている(こいつにはNICが2枚刺さってる
  5. [L2SW] MikroTik CRS305-1G-4S+IN (SFP+ 10GbE)
  6. [DAC] 10Gtek CAB-10GSFP-P0.5M-30 (SFP+ DAC 10GbE)
  7. [NIC] Mellanox ConnectX-4 Lx (SFP+ 10GbE)
  8. [サーバー] Ubuntu 24.04.4 LTS
[ ID] Interval Transfer Bitrate Retr Cwnd
[433] 0.00-1.00 sec 42.1 MBytes 353 Mbits/sec 2 980 KBytes
[433] 1.00-2.00 sec 39.6 MBytes 332 Mbits/sec 2 526 KBytes
[433] 2.00-3.00 sec 40.0 MBytes 336 Mbits/sec 0 581 KBytes
[433] 3.00-4.00 sec 30.0 MBytes 251 Mbits/sec 5 188 KBytes
[433] 4.00-5.00 sec 30.4 MBytes 255 Mbits/sec 1 199 KBytes
[433] 5.00-6.00 sec 22.9 MBytes 192 Mbits/sec 2 184 KBytes
[433] 6.00-7.00 sec 28.9 MBytes 242 Mbits/sec 1 209 KBytes
[433] 7.00-8.00 sec 27.1 MBytes 228 Mbits/sec 2 146 KBytes
[433] 8.00-9.00 sec 22.5 MBytes 189 Mbits/sec 1 205 KBytes
[433] 9.00-10.00 sec 28.0 MBytes 235 Mbits/sec 2 164 KBytes
[ ID] Interval           Transfer     Bitrate         Retr
[433]   0.00-10.00  sec   312 MBytes   261 Mbits/sec   18            sender
[433]   0.00-10.01  sec   311 MBytes   260 Mbits/sec                  receiver
[WiFi経由] スマホ → サーバー(新AP)

今回購入したAPを利用し、スマホからサーバーに飛ばしたiperf3の測定結果。構成は以下の通り、速度はその口がサポートしている最大を記載。

  1. [スマホ] Xperia 1 VIII (WiFi 7)
  2. [新AP] RT-BE92U (OUT RJ-45 10GbE)
  3. [LANケーブル] CAT 6A RJ45 LAN (CAT6A 10GbE)
  4. [トランシーバー] ASF-10G-T80 (10GbE)
  5. [L2SW] MikroTik CRS305-1G-4S+IN (SFP+ 10GbE)
  6. [DAC] 10Gtek CAB-10GSFP-P0.5M-30 (SFP+ DAC 10GbE)
  7. [NIC] Mellanox ConnectX-4 Lx (SFP+ 10GbE)
  8. [サーバー] Ubuntu 24.04.4 LTS
[ ID] Interval Transfer Bitrate Retr Cwnd
[512] 0.00-1.00 sec 145 MBytes 1.21 Gbits/sec 0 1.93 MBytes
[512] 1.00-2.00 sec 135 MBytes 1.13 Gbits/sec 1 1.93 MBytes
[512] 2.00-3.00 sec 133 MBytes 1.12 Gbits/sec 0 1.93 MBytes
[512] 3.00-4.00 sec 156 MBytes 1.31 Gbits/sec 0 1.93 MBytes
[512] 4.00-5.00 sec 161 MBytes 1.35 Gbits/sec 0 1.93 MBytes
[512] 5.00-6.00 sec 143 MBytes 1.20 Gbits/sec 0 1.93 MBytes
[512] 6.00-7.00 sec 141 MBytes 1.18 Gbits/sec 0 1.93 MBytes
[512] 7.00-8.00 sec 150 MBytes 1.26 Gbits/sec 0 1.93 MBytes
[512] 8.00-9.00 sec 149 MBytes 1.25 Gbits/sec 0 1.93 MBytes
[512] 9.00-10.00 sec 122 MBytes 1.02 Gbits/sec 0 1.93 MBytes
[ ID] Interval           Transfer     Bitrate         Retr
[512]   0.00-10.00  sec  1.40 GBytes  1.20 Gbits/sec    1            sender
[512]   0.00-10.01  sec  1.40 GBytes  1.20 Gbits/sec                  receiver

まとめ

環境 送信 受信 備考
新AP→サーバー 3.79Gbps 3.79Gbps CPU使用率が100%に張り付いていた
サーバー→新AP 2.56Gbps 2.56Gbps
ノートPC→旧AP→サーバー 124Mbps 123Mbps
ノートPC→新AP→サーバー 1.09Gbps 1.09Gbps 旧環境の約8倍
スマホ→旧AP→サーバー 261Mbps 260Mbps
スマホ→新AP→サーバー 1.20Gbps 1.20Gbps 旧環境の約4倍

公式商品ページには「最大9700Mbpsの超高速トライバンドWiFi 7」とあり、10GbEのWANポートがあることから10Gbpsを期待したものの、10Gbps出ることはなかった。所詮無線は無線ということか…。

とはいえ、以前のAPと比べたときの速度は4~8倍と格段に上がっており、WiFi経由での写真の転送もかなり早くなっており、全体的な満足度は高い。

今までルーターと言えば数千円のものを常用してきており、これは3万円強したが、よい買い物だったと思う。

あとがき

ルーターの置き方やアンテナの方向に無理があるので、ラックにぶら下げておけるような紐か何かがあると便利かもなぁと思ったので、そのうち整備したいところだ。

或いは壁美人を使って壁に付けるのもなくはないかもしれないが、ケーブルを伸ばすとケーブルに埃が溜まって嫌なので、それはしないかもしれない…。

旧AP (1GbE, WiFi6) 新AP (10GbE, WiFi7)

ひとまず10GbEネットワークが広がったので満足度は高まった。

上図ではWiFi APの部分以外も微妙に変わっているが、これはConoHa VPSを前段に置く対応を取りやめたことでPPPoEが復活したことを反映しているためだ。要するに別件の変更がごっちゃになっている()

あとは無線は破線の方が分かりやすいというのでWiFiを破線化している。というか、これは元来破線だったのがいつの間にか消失していたのを戻している感じである。