日記帳だ! with Tux on Libserver

とあるチケットを買おうとして、初めて使うプラットフォームで登録がいろいろあり、

その中で電話番号認証が必要と言われ、こんなのにわざわざ電話番号認証を要求するか、

と思いつつ進むと、SMSを送信させるか電話をかけさせるかという。

通話料がかかるというので、じゃあSMSの方がいいかと思ったのだが、

なんと国際SMS、警告は出たが、スルーしてしまい100円もかかった。

高々100円だしとは思ったのだけど、電話を選んだ方が多分安かったよねと。

さすがに国際電話ではないはず。

なんで国際SMSなのかというのは謎である。

国内通話という前提で言えば電話をかけさせる方法を呈示すればいいはず。

通話料がかかるのもどうかと思うが、それならあり得ないとも言えない仕組みだ。

Tポイントでは電話を掛けさせる方法の電話番号認証をつかっていて、

かつては通話料がかかっていたが、現在は電話を取らずに切る方法になり、

通話料無しで電話番号認証が完結するようになっている。

これもこれでどうかと思うところはあるが、わからなくもない仕組みである。

ただ、全般的な問題として、認証される側から送信・発話するという仕組みは認証方式として弱いというのがある。

というのも送信元・発信元の番号は偽装できなくもないからである。

特に国際SMSというのは偽装しやすい仕組みである。

送信元を偽装するSMS――注意すべき点とキャリアの対策は？ (ケータイWatch)

こういう話は発信者番号の偽装でもありうる話ではある。

もちろん、国際電話なのに国内の番号に偽装するとか、明らかにおかしいものは対策できる。

でも、SMSの送信元、電話の発信者番号が真の送信元・発信元かは疑わしい部分は残る

なので、こういう認証は認証される側にSMSを送信したり、電話をかける方がよっぽどよい。

その電話番号が使えることと、受信・受話できることが確認できるからである。

その方法が国際SMSでも国際電話でも問題ないだろう。

というわけで、そもそもダメなアプローチだねという話だった。

ちなみにこれはLivePocketというプラットフォームの話である。

エイベックスグループが開発・運営している。まさかの大企業である。

この事業をKDDIが今年取得するそうである。

エイベックス・グループの電子チケット販売プラットフォーム事業「LivePocket」を承継 (KDDI)

KDDIがこの事業をどのように活用していくのかはよくわからないのだが、

他のエンタメサービスともつながるようau IDに統合するのはあるかも。

そうなればわざわざこのシステムのために電話番号認証することはなくなるのでは?

あと、KDDIが株式の50%を取得するローソンの傘下にローチケもあるよね。

LivePocketは比較的小規模なイベントなどで活用されているので、

ローチケとは用途が違うところはあるが、共用できる部分はあるかもしれない。

まぁ何も変わらず放置という可能性もありますがね。

割り込み処理で立てたフラグを読んで消すという処理をするのに、

アトミック処理のスワップ命令を使って書いたら便利そうだなと思ったが、

いや、素直に割り込みマスクしてフラグ操作するべきか? となった。

普通にフラグ変数を読んで、消すという操作は複数の命令で構成される。

ロード・分岐・ストアみたいに命令が並ぶんじゃないかな。

で、この処理をしている間に割り込み処理が入る可能性は否定できなくて、

そうすると意図したフラグ操作にならないという懸念がある。

それを回避するためには読んで消すという操作を1命令でできればよい。

これを実現する方法としてアトミック操作があって、

アトミック操作では読んで書き換えるという操作の途中状態を見せずに一息で処理できる。

フラグを読んで消すのにはスワップ命令が適していて、

読んで消すというのは、メモリの値を読んで0に入れ換えるということだからである。

シングルコアのシステムならば読んで書くが1命令というだけだけど、

マルチコアのシステムだと他のコアのアクセスに割り込まれないようにするという意味もある。

予約してメモリを書き換える

Load-Link/Store-Conditional(LL/SC)方式の話を以前紹介している。

この方式は読み出して予約(Load-Link)して、予約後に書換がない場合のみ書き込む(Store-Conditional)というもので、

これにより他のコアに割り込まれていないことが確認出来るわけである。

ARMのAArch32では複数コアで操作する変数を読んで書き換える方法はこれしかないはず。

一方でAArch64では、SWPAL命令を使えばこれが1命令で書ける。

AArch64といってもv8.1以降に限られる新しい命令らしいが。

今回の場合、心配しているのは同じコアの割り込み処理だけで、

その場合にわざわざアトミック命令を使うと他のコアにも影響してしまう?

それでパフォーマンス低下が発生してしまうのは好ましくない気がする。

実際の影響度はよくわからなくて、影響がない可能性もある。

割り込みマスク→ロード→分岐→ストア→割り込み許可というのは、

なかなかまどろっこしい気がするが、他のコアの処理には影響しない。

よくよく考えてみれば、割り込みマスク自体は避けられない気がして、

wfi命令で割り込みを待つ意味

ここで書いたのだけどWFI命令でスリープ状態で割り込みを待つ場合、

割り込みマスク→フラグ確認→フラグがない場合はWFI命令→割り込み許可

という順番でやらないとフラグ確認→WFI命令の間に割り込みが入ってしまう可能性がある。

それなら、この割り込みマスクしている間にフラグのクリアもやってしまえば、

わざわざアトミック処理を使わなくても済みますねと。

アトミック処理を使うためにインラインアセンブラを使う必要もないし。

フラグを読んで書き換えるという操作を複数のコアで行う場合はけっこう重要で、

こういう処理はスピンロックで使われることがあるという。

フラグ変数に0が入っている状態で、複数コアで同時にフラグ変数の値と1をスワップするアトミック処理を行う。

するとその中で一番乗りのコアは 0を読んで1に書き換えることができ、

2番目以降のコアは1を読んで1に書き換えるという結果になる。

このとき0が読めたコアがリソースを獲得できるという仕組みである。

マルチコアになる以前は単純に1命令で書ければいいという話だったが、

マルチコアになってからはそれでは不十分ということで、

他のコアにも途中状態を見せないアトミック処理に発展したという経緯があるようだ。

昨日、SPIフラッシュからのプログラムロードが遅いかも。

という話で圧縮というのも考えるのかもしれないと書いたが、

簡単な圧縮方法はないものかと調べたら、Deflateに条件を付ければ簡単そう。

その条件とは固定ハフマンである。

Deflateと言えばZIPやらGZIPやらの圧縮アルゴリズムとして使われている。

圧縮性能はそれなりによいので、面倒そうだなと思う。

実際、けっこう面倒そうなのだが、意外とそうでもない部分もある。

7shi/Deflate (Slideshare)

Deflateはハフマン符号化とLZの2つのアルゴリズムを組み合わせている。

LZというのは繰り返しを表現するもので、

1～32768byte前に3～258byteの一致があることを0x101～0x11Dの符号で表す。

そういう都合のよい一致がない場合は0x00～0xFFで1byteのデータ、

そして最後は0x100の符号で終わるという仕組みである。

で、これ見てもわかるのだけど、0x00～0x11Dの285種類の符号を使う。

中途半端な気がするが、それで問題ないのはその後にハフマン符号化があるからで、

発生頻度の高い物は短い符号長、低いものは長い符号長を割りあてる。

これにより効果的な圧縮ができるわけである。

ただ、短いデータの圧縮だと、符号の定義でサイズが大きくなってしまう。

そこで固定ハフマン符号ということで既定の符号が存在している。

0x00～0x11Dを7～9bitの可変長の符号で表すというもの。

ある程度発生頻度は考慮されているらしい。

これを使う前提ならばハフマン符号の解析はある程度決め打ちでできる。

固定ハフマンを使って圧縮するというのはPythonでこんな風にかける。

import zlib
zc=zlib.compressobj(strategy=zlib.Z_FIXED)
ifile=open('c:/work/input.bin','rb')
idata=ifile.read()
ifile.close()
ofile=open('c:/work/deflated.bin','wb')
ofile.write(zc.compress(idata))
ofile.write(zc.flush())
ofile.close()

コンソールで殴り書きしたのをコピペしただけなのでご勘弁を。

ポイントはstrategy=zlib.Z_FIXEDってところで、これで固定ハフマンを使うことを表している。

1079kBのCSVを圧縮して254kB、本気で圧縮して206kBだから、

確かに劣るけど、これはこれで悪くない数字ではないかと思う。

固定ハフマンに限れば解析は容易になりそうだが、

ちょっと面倒なのは可変長符号の都合、下位ビットがMSBになっていること。

愚直に1bitずつコピーしてシフトして処理しては展開に時間がかかりそうだし

あらかじめ固定ハフマンを解析する用のテーブルでも作っておくのがよいのだろうか?

ただ、あらかじめ用意したテーブルを使えるのは固定ハフマンのメリットではないか。

圧縮に既存のツールが使えるなら少し助かった気がする。

展開側は書かないといけないのかもしれないけど、

まぁ実現性はありそうだなと思った。

やりたくはないけど、結構厳しそう。

新しいシステムでプログラムを格納するのにSPIフラッシュを使う想定で話が進んでいて、

もしかすると思っているより遅いかもという話になって、

適当に書いたテストプログラムだと、従来のシステムより1桁ぐらい遅そうと。

SPIフラッシュの読み出しを早くするにはクロックを早くすればよい。

ただ、評価ボードから線でビローンと伸ばしたりしては、どうも難しいようだ。

実際にプリント板を作るときにはこのあたり打開されていると見てよいものか。

ただ、最速設定で回せれば2倍速とか4倍速にはなる計算である。

さらに高速化する手法としてはQSPIを使う方法がある。

QSPIってQuad SPIの略で、信号線4本をパラレルに使うSPIって、それはシリアルではないような?

ただ、それでも純然たるパラレルバスに比べれば信号線の数は少なく抑えられる。

ちなみに信号線2本パラレルにして使うDual SPIというのもあって、

この場合はもともとSPIは送受信1本ずつの信号線を使うところ、双方向に2本束ねて使うということで、

必要な信号線の数は変わらないというメリットがある。導入はしやすいか。

QSPIの使い方もいろいろあるのだが、今回は都合によりQPIモードを使った。

起動時は通常のSPIのコマンドを受け付けるが、QPIモードに入るコマンドを送ると、

以後はQSPIのコマンドを受け付けるようになり、単純には4倍速でやりとりできると。

リセット信号を入れるか、QPIモードを出るコマンドをQSPIで送れば、

通常のSPIのコマンドを受け付けるようになるが、その必要があるかはなんとも。

実際にはいろいろオーバーヘッドがあるので4倍速とは行かないところはあるが、

それでも3倍速ぐらいにはなったような気がする。

最初1桁ぐらい所要時間が増えそうだという話をしていたが、

クロックを最速にして4倍速、QSPIにして3倍速だと、12倍速という計算、

実際にはこの通りにはいかないかもしれないが、従来のシステムと同程度にはできるかもしれない。

あとは当初使っていたサンプルプログラムの出来がよくなくて、

1バイト送受信するごとに少し休んでという波形が見えていたので、

それはおかしいなということでプログラムを刷新したら、隙間はなくなった。

わりと無駄な処理がいろいろ挟まっていてたようだ。

ただ、クロック周波数を上げていくとこの隙間が復活するかもしれない。

結局のところ、最後の切り札は圧縮なんじゃないかなという気がする。

データサイズ自体が小さくなれば、転送に要する時間は短縮できる。

短縮命令とかあるけど、そうはいっても機械語は圧縮の余地がかなりある。

その代わりデータの展開にかかる時間は増えるけど、

ある程度ハイパワーなマイコンだし、総じて見れば短縮できるのでは?

そこまでするのかはよくわかりませんけど。

どれぐらい起動時間が伸びても許容できるのかってところかなぁ。