▼

カテゴリー: コンピュータ・インターネット

追加ディスクをくっつけて容量拡張

朝起きるとPostfixでエラー発生の通知が多数届いていて、

“Insufficient system storage”ってなんだ? と思ったらディスク容量が足りないらしい。

調べてみると確かに / の容量を100%まで食い潰していた。

取り急ぎなんとかする必要があるとフォルダ容量を調べて下記3つの対策をした。

  1. 個人用のデータ保管庫のうちほぼ使っていなくて復元可能なデータを削除
  2. メールボックスの迷惑メールフォルダの中身を削除
  3. MySQLのログファイルの容量を削減 (innodb_log_file_sizeの設定変更)

2.はあんまり効かなかったね。でも、これで10%以上の余裕は確保できた。

おそらくトドメを刺したのはメールかMySQLだと思うのだが、

容量を圧迫する要因が個人用のデータ保管庫ですね。

今回、ほぼ使っていないデータは消したのだが、今後追加の予定もあった。

でも、このVPSで使える容量に対してはだいぶ余裕があったような。

調べてみると、VPSで使えるストレージ容量は100GBなのだが、

実際にシステムで使える容量は17GBほどとだいぶ少ない。

この原因はお名前.com VPSのストレージが「基本ディスク」と「追加ディスク」に分かれていることだった。

あらかじめ設定しておけば契約容量を自由に割り振ることができるのだが、

初期設定では基本ディスクが20GB、残り(本契約では80GB)が追加ディスクという扱いになる。

これをあらかじめ基本ディスク100GBにしておけばこんな問題はなかったのだが。

サイズ変更はできるのだが、サイズを縮小する方のディスクが吹き飛ぶなど、

操作ミスに対するリスクが高いのでやりたくないなぁと。

確認したところ、基本ディスクは /dev/vda 、追加ディスクは /dev/vdb で、

ディスクは分かれているが、現在のままでもちゃんと100GB使えるようだ。

追加ディスクに新しくパーティションを切ってマウントすれば……

とも思ったが、LVMでは複数ディスクを合算して使うことができたよねと。

調べたらちゃんとできそうなのでやってみることにした。

まずLVMの用語を確認する。

物理的なディスクにパーティションを切ったものをPhysical Volume(PV)と呼ぶ。

次にPVを1個以上組み合わせたVolume Group(VG)を作る。

現在は1つのPVから構成されるVGがある状態になっている。

VGを適宜分けてLogical Volume(LV)を作成する。

このLVには物理ディスクに切られたパーティションのようにファイルシステムを作ることができる。

現状は2つのLVがあって、1つがスワップ領域、もう1つがXFSのファイルシステムで、ルートディレクトリに割りあてられている。

というわけで、まずは追加ディスクにPVを作成する。

そして、このPVを既存のVGに追加して、VGを拡張する。

VGを拡張した分、LVを拡張して、ファイルシステムを拡張すると、

基本ディスク・追加ディスクの構成を変えずにメインで使っているファイルシステムを拡張できるというわけである。

まず、追加ディスクにパーティションを作成する。

# fdisk /dev/vdb

Hex codeで”8e”とするとLVMになる。全領域をLVMにしてしまう。

次にこのパーティションをPVにする。

# pvcreate /dev/vdb1

pvdisplayコマンドでPVの状況を確認出来る。

基本ディスクのPVがあって、追加ディスクのPVが”NEW Physical volume”と表示されている。

VGの状況はvgdisplayコマンドで確認出来る。

これを見ると基本ディスクのPVで構成される”cs_gmo2”というVGがあるので、

# vgextend cs_gmo2 /dev/vdb1

で、新しく作成したPVを既存のVGに加える。

LVの状況もlvdisplayコマンドで確認出来る。

ファイルシステムの方は /dev/cs_gmo2/root という名前で、これを拡張したいので、

# lvextend -l +100%FREE /dev/cs_gmo2/root

で、当該VGの未使用領域全部をこのLVの領域拡張に充てる。

最後にファイルシステムの容量も拡張する。

# xfs_growfs /

マウント先が/のXFSを拡張する場合はこう書くらしい。

これでVPSのストレージ容量がフルに使えるようになった。

最初から基本ディスクに割りあてておけばこんなことにはならなかったが、

後から気づいてもほぼ同じ状態にすることができたのでよいということで。

これらの作業は動作中にすることもできるので安心である。

それにしてもなんでこんな仕様なんだろうね?

なにか歴史的な経緯でもあるんだろうか?

他社を見ると、ストレージを追加購入できるような場合はともかく、

標準装備のストレージを基本・追加と分ける構成は独特に見える。

新規申込みの人は基本ディスクに100%からスタートにしておけばいいのにとか思いますけどね。

急速充電の効果はどんなもの?

Redmi Padの高速充電はQuickCharge 3.0相当という話を書いたが、

家ではUSB PDの充電器とは別に付属品の充電器を設置したからよいとして。

出先での急速充電を1台で行うためにUSB PD・QuickCharge 3.0両対応の充電器を購入した。

大手のメーカーも出してないわけではないのだが……

Anker PowerPort Atom III (Two Ports)

USB PD対応 AC充電器(USB PD45W・QC + 12W/C×1+A×1) (ELECOM)

出力が大きいということもあり携帯用には大きいなと。

いろいろ探したところ一方のみ使用時18W出力でコンパクトなものがあった。

メーカー名は判然としないが(輸入業者の名前でPSEマークが付けられていた)、

これでスマートフォン・タブレットともども最高速度で充電ができるからいいねと。

Type-CとType-A両方接続すると双方とも5V出力になるらしいが、そういう使い方をする予定はない。

USB PDやQuickChargeによる急速充電は確かに速いのだが、

実際の使い方にとってその差を実感出来るかというと案外難しい。

というので、AQUOS sense6とRedmi Padでそれぞれ50%から満充電にしたときのデータから検討してみた。

従来方式のUSB BC(5V×1.5A)相当と急速充電で充電が5%進むのにかかる時間を拾ってグラフを描く。

そしてグラフを観察するとこんな感じだった。

  • AQUOSのUSB PDでは75%あたりまで直線的でそこから充電ペースが落ちる
  • AQUOSのUSB BCでは80%あたりまで直線的でそこから充電ペースが落ちる
  • Redmi PadのQuickChargeは80%まで直線的で、そこから充電ペースが落ちる
  • Redmi PadのUSB BCは100%まで直線的に充電が進む

AQUOSはパッテリー温度も見ながら充電しているなどそう単純ではないが、

ある程度までは直線的に充電が進む前提でシミュレーションしてみる。

充電開始時の電池残量と充電時間により効果は違う。

AQUOS sense6で電池残量10%から95%までの充電時間を見ると、

USB BCで150分に対して、USB PDで102分で48分短縮と効果が大きい。

ただ、そこまで電池残量を減らして充電器に付けるのは稀だと思う。

20%からは42分短縮、30%から34分短縮、40%から27分短縮、50%から21分短縮、60%から14分短縮、70%から8分短縮、80%から3分短縮。

普段は60～70%ぐらいで充電器に付けることが多いから、10分程度の短縮効果しかない。

AQUOSが電池の長寿命化のために充電ペースを落としてしまうからだけど。

ただ、旅行のときなど40%程度まで減らして付けることはあるから、そしたら30分ほど短縮で効果はありそうな気がする。

もう1つの観点が充電器に取り付ける時間だよね。

50%からスタートして20分後にPD73%・BC63%、30分後にPD80%・BC69%、

PDだとこれぐらいの時間であらかた充電できるので効果が見えやすい。

ただ、45分後にPD88%・BC79%、60分後にPD93%・BC86%というと大した差はない。

開始時の電池残量にもよるのだが、30分以内の充電だと効果が見えやすい。

在宅時はスマートフォンは定位置で充電している時間が長く、

ということは充電時間は30分よりはるかに長く、効果は見えにくそうだ。

一方のタブレットPCは在宅時に充電器から外して使う時間が長い。

さらに電池容量が大きいので、こちらは急速充電の効果が見えやすい。

残量10%から95%までの充電時間はUSB BC340分に対して、QC138分と202分短縮、

さすがにそこまで電池を使い尽くして充電開始にすることは稀としても、

残量30%から152分短縮、50%から119分短縮、60%から77分短縮、70%から52分短縮、80%から27分短縮と。

60～70%まで減らせば1時間も充電時間が変わるのだから大きい。

充電時間ごとの効果も60%から充電を開始して、

30分後にBC67%・QC80%、60分後にBC75%・QC94%といずれも効果大。

30分程度の充電で他用途で使うこともけっこうありますからね。

じゃあ、自宅にUSB PDの充電器いらんのではという話もありますが。

ただ、充電忘れてた時に30分程度の充電をすることも時々あるからね。

そもそも元はHUAWEIのタブレットがUSB PD対応していたのだから、

タブレットでの恩恵が大きかったわけですからね。

一方で旅行ということになれば急速充電の効果はおしなべて大きい。

  • スマートフォンを電池残量40%以下から充電開始
  • スマートフォンを30分程度充電してから外出
  • タブレットを1時間程度充電して、スマートフォンの充電に切り替え

なんていう使い方は普通に発生しますからね。

こういうニーズに1台で対応できるコンパクトな充電器はメリットが大きい。

このあたりは人によってもいろいろだと思うけどね。

世間的に見れば、在宅時でもスマートフォンを多用する人は多い。

そういう場合、30分程度の充電の効果が大きいことはメリットになる。

その逆に充電する機器数が多すぎる場合、口数が多い充電器を使いたいということで、

こうすると個別に電圧制御が必要な急速充電対応のものは選びにくいかもしれない。

Anker PowerPort 6

出力電圧5V固定だから口数を増やしやすい。

多くの機器を同時充電できるなら1つ1つは遅くてもよいという考えもあるかもしれない。

世の中、まだまだUSB BCでの充電が普通に行われているのだと思うし、

案外それでもなんとかなるのかもしれない。

今はだいぶ改善したけど、USB PDの充電に使うケーブルは割高である。

両側Type-CならばUSB 2.0でよいが、これが案外高くて入手性が悪いと。

ただ、大容量バッテリーを積んでいるタブレットだときついですね。

これはやっぱりQuickCharge対応の充電器が出先でも必要ですね。

Redmi PadがQuick Charge 3.0なわけ

昨日、Redmi PadがUSB PDに対応していないという話を書いたが、

XiaomiにもUSB PDに対応している製品はあるらしいのに、なぜこれは対応していないのだろう?

と気になって調べていたが、全体的にXiaomiの高速充電方式は特殊らしい。

このあたり調査している人がいた。

Samsung・Xiaomi・OPPO・vivo・Huaweiの急速充電規格メモ (HanpenBlog)

独自の充電方式を持っているメーカーとしてSamsung, Xiaomi, OPPO(と傘下各社), HUWAEIを挙げている。

このうち、Samsungについては過去は独自方式(Samsung AFC)を使っていたが、

現在はUSB PDに整合した方式に移行しているので、今は昔。

残る3グループはいずれも中国メーカーである。

というので総じて言えば中国メーカーの充電方式は要注意という話になる。

調べてみるとXiaomiは独自の高速充電にこだわりのある会社でもある。

120W Xiaomi ハイパーチャージ (Xiaomi)

現在の最新機種ではスマートフォンに120Wでの充電ができるという。

Xiaomi 12T Proでは19分で100%充電というすさまじい数字が書いてある。

USB PDでも以前は100W(20V×5A)給電が最大で、そこまで使うのは一部のノートPCに限られた。

現在はUSB PD EPRで240W(48V×5A)まで拡張されたが、まだ活用されていないのでは?

そこを越える高速充電がXiaomiには存在していることらしい。

ただ、一方でXiaomiは高速充電の切り替え技術は既存のものを活用しているよう。

この方式が27W以下はQuick Charge 3.0、30W以上がUSB PDらしいと。

今回、Redmi Padに付属していたACアダプタには下記の表示があった。

Output/出力: 5.0V 3.0A/9.0V 2.23A/12.0V 1.67A/10.0V 2.25A Max

なんか若干怪しい表記があるけど……

タブレットの仕様には「18 W 高速充電」の記載があるし、18W相当なのかね。

これについて言えばQuick Charge 3+の刻印がある通りですね。

一方の30W以上についてはUSB PD準拠の方法で切り替えを行っている。

ただ、それでもACアダプタの出力はType-Aなんですよね。

おかしくね? と思うわけだが、実は専用ケーブルに第5の端子が付いていると。

第5の端子こそがUSB Type-CのCC端子のことであろうということ。

POCO F3 充電仕様調査 & 付属ACアダプター・ケーブル仕様調査　(HanpenBlog)

さらに充電器と端末のネゴシーエションも対応機器同士でないと制限があるらしい。

とはいえ、30W以上の高速充電に対応したものであれば、USB PDを認識する仕組み自体は存在するということで、

このため充電器の能力をフル活用できる保証はないが、USB PDでの高速充電自体は可能なようだ。

USB PDの方式を使いながらUSB PDに完全に準拠しているとは言えないのはXiaomiだけでもないけど。

よく知られた話としてはNintendo Switchの充電器があるけど。

USB PDでは定格出力に応じて対応するべき出力電圧・電流が規定されているが、Switch付属の充電器はこれを逸脱している。

ただ、Xiaomiの場合、ケーブルの形状からしておかしいし一体何が何なのかと。

昨日も書いたんだけどUSB Type-Cの規格ではUSB PD以外での昇圧は認められていない。

移行期にはQuick Charge 3.0でType-C接続というものはあったそう。

しかし、GoogleがAndroidならUSB PDを使えという指示を出したのもあり、

多くのメーカーではUSB PDへの一本化が進んでいったという。

QualcommとしてもQuick Charge 4というUSB PDと互換性のある方式を提案している。

しかし、あえてQuick Charge 4対応と銘打っているものは少ない。

もし、追加で充電器が欲しければ正攻法としてはXiaomiの充電器を買うべきで67Wと120Wのものが販売されている。

いずれも付属のケーブルと組み合わせて使うべきである。

Quick Charge 3.0とUSB PDの両対応ということなると思うが、

充電先がXiaomi以外の場合はその出力をフルに生かせないと見るべきだろう。

そもそもRedmi Padの場合は18W高速充電というスペックなので、67Wでも明らかにオーバースペックである。

よくわかんないことが多いんですけどね。

まず1つが他のスマートフォンが30W以上の高速充電に対応する中で、

Redmi Padが18W対応であるということ。

18Wが不足とは思わないけど、バッテリー容量は他より大きいのにと。

Xiaomi Pad 5については33W対応らしいが付属する充電器は18W仕様とのこと。

ちなみに中国版(小米平板5)のスペックは下記の記載だから、Xiaomiの33W充電器対応でUSB PDも何らか受け付けそう。

OUTBOX 33W 充电器，支持PD QC充电协议
(OUTBOX 33W充電器、PD・QC充電プロトコルに対応)

いずれにせよXiaomiにしては高速充電に期待していないことは読み取れる。

もう1つがやはり未だにQuick Charge 3.0を使っていると言うことだよね。

確かに18WならQuick Charge 3.0対応の充電器はまだ数が多いし、

これをType-Cに形状変換してつなぐのは規格不適合としても実害は少ない。

Xiaomiは昔からこの規格を使ってきたから、充電器側は互換性のため継続せざるを得ないのかもしれないが、

機器側までUSB PD全盛になっても未だに使い続けてるのはどうなのと。

HUAWEIは日本で新規に購入する人は少ないだろうからおいておいて……

OPPOはY!mobileでも取扱があるので確認してみたのだが、

Y!mobileとしては汎用のUSB PD充電器を使うことを推奨しているよう。

OPPOにはVOOCという独自の急速充電技術があるのだが、

日本では18Wまでは汎用的なUSB PDでよいと考えているようだ。

OPPO Find X3 Proのスペックを見るとこういう記載がある。

65W SuperVOOCフラッシュチャージ／PD(9V/2A)/QC(9V/2A)/PPS(最大30W)

独自方式のVOOCとUSB PDの併用で、USB PDだと18Wまでに制限される。

(この機種はUSB PDでもPPS対応なら30Wまでいけるらしいが)

日本ではVOOC対応の充電器を積極的に販売していないようなので、

それならUSB PDで18W給電でいいんじゃないということだと思う。

Xiaomiもそういう考えでやってくれればよかったんだがなぁ。

Xiaomiのタブレットを買う

もう4年前の話になるのだが、HUAWEI MediaPad M5というタブレットを購入した。

かつてはAndroid搭載のタブレットPCもいろんなメーカーがやっていて、

7～8inch程度のものを Nexus 7→ASUS MeMOPad→LG-V480 と渡り歩いてきたが、

この当時、AndroidタブレットというとHUAWEIぐらいしか選択肢がなかった。

とはいえHUAWEIはコストパフォーマンスに優れる製品を多く揃えていたから、これはこれでよかった。

ただ、この後HUAWEIはGoogleに締め出しを食らうことになる。

以後、HUAWEIが新規に発売する端末ではGoogleサービスが使えなくなった。

既存の端末については問題ないものの、HUAWEIで買い換えるという選択肢はなくなった。

Google締め出し後のHUAWEIはHarmonyOSという独自OSを搭載するようになり、

これはAndroidアプリが一部動作するので元々Google Playが使えない中国大陸ではあまり困らないという実情もある。

ただ、日本でGoogle Playが使えないのはやっぱり困るんですよね。

すぐに代替策は決まらないと、できるだけ使い続ける方向でやっていたが、

さすがにバッテリーの劣化や、ストレージ容量の逼迫などの課題も多くなり、

Android 9から更新されないというのも将来的な心配がある。

なので、今年に入ってとうとう代替方法に検討に入ったわけである。

HUAWEIが締め出されたのと入れ替わるようにAndroidタブレットに新規参入するところが出てきた。

Lenovoが代表格ですか。ただ、Lenovoは決め手に欠けるなとも思っていた。

Androidにこだわらなければ、iPadシリーズも選択肢に入る。

サイズ的にはiPad miniがよいが、AndroidからiOSへの乗換は考えるべきことが多い。

アプリはiOSでもほぼ提供されていると思うが、確認が必要である。

あとAndroidだとmicroSDが付くものが多く、データ移行やストレージ容量の柔軟性が高いが、iPadでは内蔵ストレージのみ。

iPadはよいタブレットPCだと思うが、解決するべき課題は多い。

そんなわけでAndroidでの移行が本線だなということで、

大型のスマートフォンも場合によっては選択肢になるかもしれないと、

いろいろなメーカーを調べたのだが、そこで行き着いたのがXiaomiのRedmi Padである。

Xiaomiは中国を中心に世界展開しているが、日本参入は2019年と後発。

XiaomiはもともとタブレットPCを作っていたが、2018年発売のMi Pad 4から長らく止まっていた。

2021年にXiaomi Pad 5として久々にタブレットPCを発売した。

そして、この廉価版として昨年Redmi Padを発売している。

このRedmi Padが僕が求めていたものにかなり合っていることに気づいて購入した。

Redmi Padは画面サイズ10.6inch、なので従来のMediaPad M5より大きい。

サイズは大きくなったが重さはそこまで変わらない印象。

片手持ちのサイズではないと思うが、片手持ちでもそこそこ使える。

読書用途では横向きで見開き表示がよくフィットする。

2タイプあるが、RAM 4GB+ストレージ128GBの上位タイプを選んでいる。

これでお値段4万円、Yahoo!ショッピングで5のつく日合わせで買って7000円ぐらい還元されるけど。

箱に”with easy access to the Google apps you user most”って書かれていて、

これはHUAWEIを意識してるんだろうなというのはさておき。

従来あったのに付いていない機能というのはどうしても気になるもので、

まず指紋認証がないと。顔認証あるいは暗証番号入力が代替手段。

家の中なら顔認証で十分スムーズだからいいか。

(Xiaomiもスマートフォンでは指紋認証を付けているので念のため)

それよりなにより気になったのがUSB Type-CでUSB PD対応のACアダプタと接続しても「高速充電」にならなかったということ。

付属のACアダプタはType-Aの端子が出ていて、これをType-Cに変換して接続すると高速充電になる。

HUAWEIもType-A出力の専用ACアダプタを添付していたので同じなのだが、

MediaPad M5はUSB PDで接続しても同等の急速充電ができた。

しかし、Redmi PadはUSB PDでは明らかに充電スピードが遅い。

付属ACアダプタとPD対応ACアダプタで75%からの充電時間を比較したが、

付属ACアダプタの2.4倍ほどの時間を要する有様である。

付属ACアダプタの出力(20Wmax)から推定するに、USB BC(5V×1.5A)相当での充電になっている可能性が高い。

PDどころかType-C標準の5V×3A出力ですらないという。そりゃ遅いわ。

ACアダプタの銘板を見ると、Quick Charge 3+のマークが付いていることに気づいた。

Quick ChargeはQualcomm独自の急速充電規格である。

スマートフォンの充電手段がUSB Type-A～microBであった時代から使われている規格である。

Quick Charge 4からはType-C接続を前提としてUSB PDと互換性を持つようになった。

Type-C接続になった時点で急速充電はUSB PDを基本とするべきだが、

一部にはType-C接続ながらQuick Charge 3対応というものが存在するそう。

(USB Type-Cの規格ではUSB PD以外での昇圧は認められていないのだが)

そういえばUSB PD対応で買ったモバイルバッテリー、Type-Aの端子にQuick Chargeのマーク付いてたよなぁと思いだした。

モバイルバッテリーのType-A端子にRedmi Padを接続すると「高速充電」の表示になった。

というわけでRedmi Padの高速充電はQuick Charge 3相当らしい。

なので条件を満たせば汎用品でも高速充電に対応できそうだ。

今どきUSB PD非対応というのがびっくりだけど、そういうのもあると。

確かにPD対応とは一言も書いてないからな。(HUAWEIもそうだったけど)

8000mAhという大容量バッテリーを備えていることも選んだ理由であって、

そうすると高速充電が使えないのはかなり痛い。

家では付属の充電器をなんとか設置して使えるようにしようと思うが、

出先では古典的なUSB BCで耐えるのか、何か別のものを用意するか考えないといけない。

Quick Charge 3対応なら探せば買えますけどね。

というわけで充電のことは大きな落とし穴だったが、基本的によいと思う。

昔はこのサイズのタブレットは重くて持てないという感じだったが、

これぐらい軽くなればこのサイズの方が目的にはマッチしていると思う。

スマートフォンの大型化もあってか、タブレットPCの人気が無くなって長いが、

僕にとってはどうしても手放せない存在である。

読書に限れば安価なものもあるけど、多目的に使いたいのもありますから。

なんでもUSB Type-Cで

職場でノートPCに他の人がログインできないのだけどと聞かれて、

それは有線で社内ネットワークにつないでログインすればよいのだというと、

このPC、Ethernetポートないのだけどと。そういえばそうだった。

うちの職場で新しく導入されている業務用ノートPCにはないんだった。

有線接続が必要なのは、無線LANへの接続には社内アカウントへのログインが必要だから。

初回ログイン時にはユーザープロファイルの取得が必要だが、

そのためにはログインなしで接続できるネットワークが必要で、

それは有線ネットワークでなければならないということである。

USB接続のEthernetアダプタが部署にあるので、これを使えばよい。

1つ前の世代の業務用ノートPC、現在、僕が使っているものだが、

有線で直接接続できるようになっている。

新しいノートPCが有線で直接接続できなくなったのは薄型化の影響だと思う。

RJ45のコネクタはそれなりに高さがあるから。

世間的にも無線接続が一般化していることもあるのだろう。

一方で有線接続のニーズは引き続きあるということか、オプションでUSB Type-C接続の有線LANアダプタも付けられる。

薄型化が進んでいく中でUSB Type-Cというのはとても便利なのだと思う。

充電コネクタとしても従来の丸型のコネクタなどに比べて薄い。

画面接続用にしてもType-CのDisplayPort Alternate Modeが使えて、HDMIやmini DisplayPortより薄い。

(ただし、このノートPCにはHDMIポートも付けられている)

Ethernet接続を考えてもRJ45のコネクタよりType-Cの方ははるかにコンパクト。

PCではそうそうないと思うが、スマートフォン・タブレットではイヤホン接続をType-Cに集約していることもある。

この場合はType-Cでアナログ接続もできるようになっているのが通常。

あと、USBとしてもType-AよりType-Cの方が当然コンパクトである。

さすがにType-Cに一本化は時期尚早だが、将来的にはそういう考えもあるかも。

USB Type-C万能説とも言えるような状況だが、コネクタの強度には疑問もあり、

コンパクトで高機能だが、実際に使って便利かというと疑問もある。

ただ、この流れは止まらないんだろうなという気はする。

特にDisplayPort AlternateもPC側はかなり対応しているわけで、

表示機器側はあまりだがDisplayPortに対応してれば形状変換だけの問題。

勤務先でどうなるかはわからないけど、一気に来るかもね。

Cで書くのも大変だが

最近、FPGAに作り込んだロジックの評価のために、

テスト用プログラムを使って、レジスタを叩いて動作確認をしている。

この順番でレジスタを叩けば、こういう動作になる。

というのをプログラムで書くのだが、なかなか期待通りに行かずに困った。

原因はいろいろあるんだけど……

まず、初歩的なところではコンパイラの最適化で書いた通りのアクセスが起きないというもの。

unsigned long *ptr;
unsigned long dummy;
ptr = REG1_PTR;
*ptr = REG1_VAL;
ptr = REG2_PTR;
*ptr = REG2_VAL;

レジスタに書き込んで、別のレジスタに書くという操作だが、

こういう書き方をすると順番が変わって想定通りの動きにならないことがある。

ptrポインタの宣言時にvolatileを付けておけば、書いた通りに読み書きしてくれる。

こういうのは組み込みソフトウェアでは一般的なことですね。

さらに今回面倒だったのが、異なるブロックへのレジスタ操作があったこと。

Aブロックへのレジスタライトが反映後にBブロックのレジスタライトをしたいが、

アクセススピードが違うため、単に順番に書いても思った動作にならないと。

確実にするためにはレジスタライト後に同レジスタをリードすればよい。

こういうのもしばしばあることだけど。

このようにレジスタへのライトを保証するための操作がいろいろ必要になる。

あと、これも面倒だったのがスタックへのアクセスである。

RAMへの意図しないアクセスを止めたいテストがあって、

スタックへのアクセスが発生しないコードが生成されているか、

コンパイル結果のアセンブラ表記を見て確認したり……というのもあった。

それでも、意外な形でスタックへのアクセスに妨害されて大変だった。

冒頭にCのコードを書いたように、テストプログラムはCで書いている。

ただ、あまりに思ったようなコードが生成できないもんだから、

この部分のテストプログラムはアセンブラで書いた方がよいのでは?

なんて思いながらも、アセンブラも面倒だしと思いとどまったのである。

正しく書けばCでも回避出来る問題が大半だったので。

アセンブラで書けば思った通りの順番で命令を並べられるので、

その点では苦労は少ないが、実際書くとなると大変なんだよな。

条件分岐やループを書くのが面倒で、注意を要するというのはあるが、

今回問題の部分は一本道で書けるので、そこの問題はないが。

どちらかというと定数の取扱が面倒なのを嫌ったと。

命令に直接書ける定数はいいけど、そういうのは限定的なので。

アセンブラで書いたところでパイプライン処理を意識する必要はあるし……

出来上がったテストコードを見てみると、

本質的に必要な操作の2～3倍ぐらいのコードに膨れあがってしまった。

ただ、Cなので何を意図してこういう書き方をしているというのはわかりやすいかな。

苦労はあったけど、やっぱりこれでよかったと思いますね。

他にもこれはアセンブラじゃないと書けないのでは?

と思うものはあったけど、ほとんどはCで書きましたね。

ここがアセンブラじゃないと書けないと思ったのはスタックとの関係だが、

コンパイラへの指示とプログラム構造の工夫でなんとか回避出来た。

これはデバッグに手を焼きそうだなと思っていたけど、予想以上にきつかった。

想定外の制約事項もあって、想定外のスタックアクセスとの競合と苦しめられた。

ただ、プログラムは1回書けば、何度でも動かせますからね。

このタイミングで正しく作り込めたのはよかったんじゃないかね。

SMSはダメだけどTOTPは使えるよ

僕は使っていないのだけど、Twitterには2要素認証の機能がある。

2要素認証を使えばいいってもんでもないが

一時、Twitterのアカウント乗っ取り問題が話題になったこともあって、

けっこう使ってる人はいるのかなと思ったが、このたび変更があったそう。

それはSMSを使った認証は3月20日からTwitter Blue契約者限定になるというもの。

すなわち無料で利用している人は2要素認証の手段としてSMSが使えなくなると。

ただ、これはTwitterの2要素認証が無料で使えなくなるという意味ではない。

Google Authenticatorなどを使ったTOTP、あるいはFIDO準拠のセキュリティキーは引き続き使える。

SMSとTOTPあるいはセキュリティキーの違い、それはSMSの送信料金がかかるか否か。

というわけで赤字にあえぐTwitterが費用節減のために行ったものだと考えられる。

Twitter Blueへの契約を促す内容とは考えにくいが、どうだろうか。

(そりゃTwitter Blueを契約してくれるに越したことはないだろうけど)

多くにおいて移行先はTOTPになると思いますがね。

ニンテンドーアカウントのためにTOTP使ってるでしょというコメントもあったが。

(オプションで2段階認証を使うことができるらしい)

TOTPはデバイスの紛失だけ怖いですけどね。

バックアップコードを書き控えてあって、それが残っていればいいけど、

TOTPを登録したデバイスを紛失するときにはそれもないケースが多いだろう。

そういうときのワークアラウンドは結局SMSになるんじゃないのって。

でも、SMS認証廃止でその手も使えなくなる(はず)。

乗っ取り対策の結果、デバイス紛失をきっかけにアカウントを喪失する危険が高まるのが実情ではないか。

それが2要素認証だし、という話ではあるんですけどね。

SMS認証も地域によっては傍受リスクがけっこうあるという話はある。

(日本ではSMSが傍受されることはまずないと思うが)

その点でデバイスはオフラインでもよいTOTPやセキュリティキーはいいんですけどね。

TOTPはこのサーバーのログイン手段にも一部採用している。

簡単な仕組みで、お互いのデバイスがオフラインで使えるのもよい。

全ての攻撃に対して強固とまでは言えないけど、利便性とのバランスは優れていると思う。

紛失時のワークアラウンドはしっかり考えておかないとというぐらいで、

それも職場のアカウントなら社内の窓口に連絡すればなんとでもなるし、

GMOクリック証券(出金指示時の認証手段にTOTPが使える)ならコールセンターに連絡すればよさそうだし……

でも、Twitterって正規ログインできなくなったときに対応してくれそうな気がしない。

そこだけ怖いですよね。

7z形式のよいところ

職場でテキストデータをZIPに圧縮していて思ったより減らないなと。

圧縮後のサイズに特に意味は無いのだが……

それで何を思ったのか7zで圧縮したら、ケタ違いに小さなサイズになってびっくり。

職場ではファイル圧縮・展開ツールとして7-Zipを標準ソフトとして採用している。

世間的にも7-Zipが使われることが多くなってるみたいね。

プライベートでも以前使っていたLhazの陳腐化から7-Zipに乗り換えている。

7-Zipというと独自の高圧縮形式「7z」の印象が強かったのだが、

実はZIP形式でもメリットが大きいソフトだと言われている。

というのも7-ZipはZIPで一般に使われているDeflateの圧縮率でも優秀なのだ。

普段は専らZIPのために使う7-Zipだが、当然7z形式も使うことができる。

なので意味も無く7z形式で圧縮してみたら小さくなったと。

7z形式が高圧縮である理由としてよく言われるのがアルゴリズムの違いである。

7zで一般に使われるLZMAは、ZIPで一般的に使われるDeflateより高圧縮だから。

展開の性能ばかりよいLZMA、Linuxに来る

これはLinuxのソースコードをtarballで圧縮した場合の話で、

gzip(=Deflate)で73Mbyteだったものが、LZMAだと48Mbyteになると。

しかし、7z形式でケタ違いに小さくなった主因はそこではない。

調べてみると7z形式の特徴として書かれている「ソリッド圧縮」が効いてるらしい

ここで初めて知ったのだが、ZIPというのはファイル単位で圧縮して結合しているに過ぎないらしい。

なので類似するファイルを複数圧縮しても、1個あたりのサイズは減らない。

一方、Linuxなどでよく使われるtarballというのはファイルをtarで固めて、

その後に何らかの圧縮アルゴリズムを適用するという方法を取っている。

この方法では類似する複数のファイルをtarに固めて圧縮すると、1個あたりのサイズは小さくなる。

ただし、ファイル一覧の確認のためにtarball全体の圧縮を解除しなければならないなどの欠点はある。

7z形式はこれの良いところ取りができるようになっている。

標準設定ではソリッド圧縮が4GBとかで有効になっていて、

4GBを上限に複数ファイルを結合してから圧縮アルゴリズムにかける。

このサイズを小さくすれば部分展開時に余分に展開するサイズを小さく出来る。

あと7z形式ではヘッダを圧縮して格納する機能があり、ファイル一覧などもその部分だけで圧縮を行う。

ZIPではこの部分は無圧縮、tarballでは本体といっしょくたに圧縮されるが、

7z形式ではヘッダへのアクセス容易性とサイズ削減が両立できるわけである。

というわけでいくつか実験してみた。

7z形式というと標準の圧縮アルゴリズムはLZMAだが、Deflateも選択可能である。

ただし、7-ZipのGUI上では選択できず、コマンドラインでないと使えない。

>7z a -mm=Deflate:fb=32:pass=1 def.7z datas\
>7z a -mm=LZMA2:d=16m:fb=32:mf=bt4 –ms- lzma_nonsolid.7z datas\

7zってのは7-Zipのインストール先にある7z.exeのこと。

-mm=でアルゴリズムの指定ができて、Deflateも選べると。

-ms- ってのがソリッド圧縮の無効化ですね。-ms=offとも書ける。

この結果、こんな感じになった。

  • Deflate・ソリッド圧縮無効: 349kB
  • Deflate・ソリッド圧縮有効: 200kB
  • LZMA2・ソリッド圧縮無効: 325kB
  • LZMA2・ソリッド圧縮有効: 61kB

ソリッド圧縮を使わない場合、DeflateとLZMA2の差はそこまで大きくない。

これをソリッド圧縮有効にすると、同じDeflateでも6割ほどに減る。

DeflateとLZMAのアルゴリズムの差よりソリッド圧縮の効果の方が大きい。

しかし驚くべきところはLZMAでソリッド圧縮有効にすると2割にも圧縮できた。

この結果、ケタ違いに軽くなったということである。

仕組みが同じならば同じようなサイズになると言える。

Deflateの設定を合わせてZIPで圧縮すれば365kBである。

7z形式でDeflate・ソリッド圧縮無効より若干大きい程度である。

LZMAで圧縮されたtarball(.tar.xz)で、LZMAの設定をさっきと似たようなところにすると61kBとなった。

7z形式でLZMA2・ソリッド圧縮有効にしたときの数字とほぼ同じだった。

社内では7-Zipが標準なんだし、7z形式をもっと活用してもよいのでは?

と思わなくもないけど、なかなかそういう機運は乏しい気がする。

1つは容量に対してそこまでシビアでないこと。

もう1つはWindowsの圧縮フォルダ機能で展開する人がけっこういるということである。

標準だと関連付けが圧縮フォルダになっているので。

関連付けを変更したり、あえて7-Zipで開く動作をすればよいのだが、全員がやっているわけでもない。

ということに気づいた理由がZIPの暗号化アルゴリズムなのだが。

パスワード付きのZIPファイルは社内での文書配布に使われることがある。

配布する文書が「社外秘」より厳しい「関係者外秘」にあたるということで、

都合によりそれより広いアクセス範囲のファイル置場に置く場合は、

パスワード付きのZIPにして、対象者にE-mailでパスワードを送るということがある。

なぜアクセス範囲の広い置場を使うのかというと、部署外の関係者にも配布するから。

(部署内での情報共有は厳密にアクセス権が管理された置場を使っている)

元々、部署外に配布する文書なのだから、社内であれば大した話でもないと思われ、

なので、パスワード保護というのは気休めみたいなもんですよね。

で、このパスワード付きのZIPを作るときに7-Zipでは「ZipCrypto」と「AES-256」が選択できる。

ZipCryptoが標準とされているが、暗号強度が弱いことも知られている。

AES-256を使えば多少強固かと、こちらを選んでパスワードをかけた。

そしたら、展開できないのだがという問い合わせが数件来た。

7-Zip使えばいけると思うけどと返したのだが……

これは7-Zipを使っていない人が社内にもけっこういることを表している。

社内ですらこれだから、社外となればなおさらでしょう。

伝統的なZIPでないとなかなか使えないのが実情ではないか。

7z形式も7-Zip独自形式というわけではないが、他の対応ソフトは限られる。

しかし、7z形式の長所というのはここまで書いた通りで、LZMA以外の点でもよいところはある。

そこまでする必要は特にないという話でもあるかも知れないが。

NTP時計ってのもあるけどね

電波時計の受信がうまくいかず時計がどんどんズレていくと嘆いている人がいて、

そういえばうちも引っ越してからは電波時計の受信が安定しないようで、

全く受信できないわけではなさそうだが、最近の受信に失敗した表示を見ることが多い。

時々受信できれば精度上は問題はないが、それも維持できるかどうか。

標準電波の受信環境というのはなかなか厳しいものである。

都市化や家庭内の電子機器の影響もあり、窓に近くても不安定というのはある。

まして建物内の奥まったところではなおさらである。

そこで思いつくのがインターネットで時計合わせをすればよいということ。

調べたらそういうのあるんですよね。

NTPクロック (SEIKO)

ただ、用途は大規模オフィス用ということでかなり高価である。

しかし、Ethernetケーブルで電源供給も兼ねるPoE対応であったり、

業務用においてはそれなりに魅力的な仕様もある。

家庭用でそういうのがないのかと調べたが、使いやすそうなものは見あたらない。

何が問題かと考えて見たけど、電源かもなと思った。

すなわちインターネットに接続するというので消費電力が下げにくいと。

この結果、電池で長時間駆動が難しいという考えである。

先のSEIKOのNTPクロックには無線LAN仕様もあるのだが、

単2電池6本で約5年と、それは大きな時計じゃないとできないなと。

単3電池2本だと果たしてどんなもんなのか。

実はデジタルフォトフレームがインターネット同期の置き時計として使えるのでは、

とか考えるところもあるけど、時計のために作られたもんではないしなと。

果たして家庭用では何が答えなのか、難題である。

ニーズはあると思うんだけど、使いやすい物が作れないというのはあるのかも。

インターネット・携帯電話回線に接続されて正確な時計の付いた機器が増え、

そういう機器が増えた現在となっては、そこに投資する価値は減ってるのかも。

ただ、なんやかんや言っても時計は時計としてのニーズがあるわけで、

そんな中で不便だなと思っている人はけっこういそう。どうしたものか。

全部ARCでいいし

引越を機にTV周りの接続を見直した。

といっても大した話ではないのだが。

変更したのは Blu-rayプレイヤー と サラウンドヘッドホンシステム である。

主にBlu-rayの5.1ch音声を楽しむことを目的に購入したシステムなので、

Blu-rayをサラウンドヘッドホンシステムのHDMI入力に接続して、

そのサラウンドヘッドホンシステムをTVに接続するということをやっていた。

ただ、ファミリンク(HDMI CECのシャープでの呼び名)との関係か不可解な挙動が多かった。

見直し後はサラウンドヘッドホンシステムをHDMI2に、Blu-rayプレイヤーをHDMI4に単独で接続することにした。

これはARC(Audio Return Channel)機能を使うことを前提としている。

サラウンドヘッドホンシステムの使い方は3つある。

  1. HDMI入力から入力される音声を分離して聴く、映像はHDMIでテレビへ送る
  2. アナログ入力・光デジタル入力の音声を聴く
  3. HDMIで接続されたテレビからARCで送られる音声を聴く

1.が基本の使い方なのでこの構成にしていたのだが、

現在のテレビはHDMI2に接続すれば3.の使い方もできるようになっている。

ARCの典型的な使い方としてテレビ放送の音声をオーディオ機器に送るというのがあるが、

PC→テレビ→サラウンドヘッドホンという使い方ができるのを知っていたので、

それならBlu-rayプレイヤー→テレビ→サラウンドヘッドホンもいけるよねと。

実際に試してみたが特に問題はなさそうだったので、この構成に切り替えた。

Blu-rayプレイヤーの動作も安定するようになり、ARC有無によらず使いやすくなった。

テレビのHDMI接続数の問題もあるが、4ポートもあるので問題はなかった。

このため現在は入力2は実質的に選ばれることがない入力となっている。

欠点としては従来はBlu-rayからの映像にオーバーラップしてサラウンドヘッドホンシステムの状態表示・操作ができたが、できなくなったこと。

さっき入力2は実質的に選ばれることがないというのはそういう意味もある。

状態表示はともかく、操作は実際に本体のボタンを操作すれば済む話ではあるが。

嘘でも入力を用意してやればいいんだけど、なかなかそんなものもなく。

それで使えるのはBlu-rayプレイヤーしかないわけだし。

(サラウンドヘッドホンシステムは4K非対応なので、2Kしか流れない信号しか使えない)

今回の記事を書く前に調べていて知ったんだけど、

ARC機能を使うにはEthernet対応のHDMIケーブルじゃないといけないんだね。

AV機器のネットワーク接続を容易化するためにHDMIケーブルにEthernetを通すことができる機能がある。

実際、どれぐらい活用されているのかは疑わしいものだが。

このEthernet信号を通すための信号は映像・音声信号とは別にある。

これをARC機能でも活用しているそうである。EthernetよりARCの方が使われてそうな気もするけど。

これは当初のHDMIにはなかった信号なので結線されていないケーブルも存在する。

現在販売されているHDMIケーブルの多くはEthernet対応なので、

そこまで気にしなくてよさそうだが、理屈上は存在しうる点は要注意である。

もしUltra HD Blu-rayに対応したプレイヤーを使うなら、

従来の構成だとサラウンドヘッドホンシステムが4Kの邪魔になるので、

そのときにはこの構成への移行は不可避だったとも言える。

まぁそんな予定はないんですがね。