ただのにっき。

さくらのクラウドのCPUガチャ

2023年2月27日 / 管理人 / 0件のコメント

さくらインターネットのさくらのクラウドで動いているインスタンスについて、さくらインターネットからメンテナンスを実施する旨の連絡が届いた。とある日までに、当該インスタンスを停止→起動(再起動ではなく)すれば、さくらインターネットが実施する強制的な停止→起動を回避できるとのこと。まぁ、どうせやらなきゃいけないのであれば、ある日、突然、停止→起動されるよりは、調整した上でタイミングを見計らって実施したいところ、ってことで停止→起動を実施してみたら、インスタンスのCPUが変わっていた。

もしかすると、メンテナンスに伴う停止→起動を実施すると詫びか何かで比較的新しい基盤で起動したりするんだろうか。今回はこんな感じで新しいCPUで起動してきた(また、収容ホスト名に含まれている数字もぐーっと大きくなったので新しい基盤で起動したんだろう)

旧インスタンスでの「cat /proc/cpuinfo」からの抜粋：
Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz

新インスタンスでの「cat /proc/cpuinfo」からの抜粋：：
Intel(R) Xeon(R) Gold 6212U CPU @ 2.40GHz

Xeon E5-2650 v3はHaswell世代で、発売日が2014年になっていたが、Xeon Gold 6212UはCascade Lake世代で2019年発売。ぐっと新しくなったと言えそうだ。AWSはインスタンスタイプである程度のCPUのスペックが分かるけれど、さくらインターネットは特にCPUのスペックを指定していない。課金の要素が単にインスタンスで使えるコアの数だけとなると…CPUの性能差による部分は課金対象には含まれていないってことだろうか。うーむ。まぁ、ガチャまわして新しいCPUを引き当てるのが合理的(とりあえず、誤差)ってことになるのかな。

WF-1000XM4をSONYに修理に出してみた

2022年12月17日 / 管理人 / 0件のコメント

SONYの完全ワイヤレスイヤホンのWF-1000XM4を使っていたのだが、購入してから1年くらい経ったあたりから不自然に右イヤホンのバッテリーのバッテリーの減り方が激しくなったような気がした。言い換えると、バッテリー残量が著しく減ってるような、そんな印象だった。

WF-1000XM4をBluetoothで接続しているのはiPhone14。両ヘッドホンとも100%まで充電した状態で、両方のイヤホンを使ってApple Musicで音楽を聴きながら、バッテリー残量を確認できるHeadphones Connectのキャプチャを撮ってみた。最初のキャプチャの時点で、右イヤホンのバッテリー残量と左イヤホンのバッテリー残量が著しくアンバランスになっていることがわかる。左イヤホンのバッテリー残量が69%であるのに対して、右イヤホンのバッテリー残量は19%まで減っている。

11時53分の右イヤホンのバッテリー残量は19%

その3分後、さらに右イヤホンのバッテリー残量は減っていて、わずか3分の間で6%もバッテリー残量が減っている。

11時56分の右イヤホンのバッテリー残量は13%

さらに、その1分後には、右側のイヤホンのバッテリー残量は5%も減ってしまった。その後、自動的にシャットダウン…と。

11時57分の右イヤホンのバッテリー残量は8%

上記の様に、右イヤホンのバッテリー残量が著しく減る状況だとWF-1000XM4が使いものにならないので、SONYに修理に出すことにした。Webから申し込んでみると、SONYが手配した配送業者が引き取りに来るとのこと。指定した時刻に待っていると、日通の担当者がIT機器を運ぶための梱包材を持ってきてくれた。

その後、しばらく経って、再び、IT機器を運ぶための梱包材に入ったWF-1000XM4が入っていた。ただし、イヤホンを入れたケースを送ったはずだが、WF-1000XM4を購入した時のパッケージが入っていた。一緒に入っていた紙によれば、申告した症状(充電不良)を確認したので、新品のWF-1000XM4に交換したとのこと。修理費は無料とのこと。1年間の保証期間を過ぎているにもかかわらず、無料で修理してもらえてラッキーという印象ではあるけれど、もしかすると、製品自体に問題があったってことなのかもしれない。

一応、SONYはWF-1000XM4のバッテリーについて

3時間以上使用できる場合は、問題ありません。
3時間以下しか使用できない場合は、下記へお問い合わせください。

と記したページを公開している。

https://knowledge.support.sony.jp/electronics/support/articles/00283656

さくらインターネットのNTPサーバ「ntp1.sakura.ad.jp」ってleap smearしてたのか。

2022年8月26日 / 管理人 / 0件のコメント

うるう秒は避けられないとしても、それをいかにしておおごとにしないかはなかなか重要なことな気がする。まぁ、そういう観点ではleap smearすることによってなんとかするのも1つではあるけれど、やっかいなことにleap smearしないNTPサーバとleap smearするサーバを混ぜて参照するのは止めた方がよさそうだ(まぁ、普通に混乱するだろうな)

…だがしかし、publicなNTPサーバのうち、leap smearしてるかどうかを明記してるNTPサーバってそんなに数多くない気がする。まぁ、書いてなきゃleap smearしてないんだなくらいの理解でもいいんだろうけれど。

たまたま、さくらインターネットのなかのひとが書いた記事(うるう秒がやってくる)を眺めていたら、こんな記事が書いてあった。

さくらインターネットのお客様向けに提供している ntp1.sakura.ad.jpでは、leap smearを採用し、時間をかけてゆるやかに時刻補正する仕組みを採用しています。

お、そうなのか。さくらインターネットのntp1.sakura.ad.jpはleap smearしてたのか。なるほど。国内のパブリックNTPサーバでleap smearしているサーバってそんなに多くない(まぁ、有名どころのnictやインターネットマルチフィードあたりのNTPサーバは対応してなさそうな雰囲気だし)ような気がするので貴重かも。あ、でも、さくらインターネットのネットワーク外からの参照ができないんだっけ(うろ覚え)

むむむ。

ThinkCentre M720q(Coffee Lake)にRocky Linux8.6をインストールしたら時計がズレまくった。

2022年8月25日 / 管理人 / 0件のコメント

中古で買ってきたThinkCentre M720q TinyにRocky Linux8.6をインストールした。搭載しているCPUはCore i5-8500Tなので、第8世代のCore i5であり、開発時のコードネームはCoffee Lake。

インストール自体はすんなり終わったけど、よく見てると、まぁ、時計がズレまくっている。timedatectlコマンドの結果を確認してみると、NTPで調整してみても、結果的にRTC time(リアルタイムクロック)の時刻がすさまじい勢いで進んでしまうので、chronydが同期をあきらめてしまうようなレベルでズレていた。

時計がズレるという事象で思いついたのが、マザーボード上のCMOS電池、CR2032の電力が無くなっているのかなと思いついて、CR2032電池を交換してみたがなにも解消しない。まぁ、なんとなくハマった実感はあったのでいろいろと調べてみるとこの記事を見つけた。

Linux Kernel Disables Coffee Lakes HPET On The Grounds That It Is “Unreliable”

この記事によると、Linuxが利用できるClocksource(時間を計測するための情報源?例えば、1秒の経過を正確に把握するための情報源ってところだおるか)にはいくつかあって、CPUを情報源とするTSC(Time Stamp Counter)や、マザーボード上のチップを情報源とするHPET(High Precision Event Timer)、ACPIを情報源とするACPI-PM(ACPI Power Management Timer)などがあるみたいんだけど、Coffee LakeとIce Lakeの世代のHPETはぶっ壊れているらしく、PCが低電力状態に状態になった時にLinuxカーネルのClocksourceの監視機構で問題が起きるらしい。

こんなエラーメッセージが出るとして紹介されているメッセージ(確かに似たようなのが、ウチのThinkCentre M720q Tinyでも出てた)はこんな感じで、壊れているのはHEPTなのにTSCが壊れているようなメッセージになっていてややこしい。

clocksource: timekeeping watchdog on CPU7: Marking clocksource ‘tsc’ as unstable because the skew is too large:
clocksource: ‘hpet’ wd_now: 54b0f25 wd_last: 4e9fe44 mask: ffffffff
clocksource: ‘tsc’ cs_now: 3e0e2debe0 cs_last: 3daab92440 mask: ffffffffffffffff
tsc: Marking TSC unstable due to clocksource watchdog
TSC found unstable after boot, most likely due to broken BIOS. Use ‘tsc=unstable’.
sched_clock: Marking unstable (4024083039, -219)<-(4075977403, -51894628) clocksource: Switched to clocksource hpet

この問題、2019年11月にLinusさんがコミットしたパッチで回避されているらしいけど、Rocky Linux8.6のカーネルには未反映なんだろうか。

とりあえず、ワークアラウンドとして、/etc/default/grubに書かれている起動時のカーネルオプションにHEPTを無効化するnoheptを追加して、それを反映させて再起動することが挙げられていた。うちのThinkCentre M720qでも同じことをやってみたら時計のズレが収まった…とりあえず、めでたしめでたし。

参考：

Amazon Linux 2022がなかなかGAにならないと思ったら、Amazon Linux2のEOLが延長された。

2022年7月7日 / 管理人 / 0件のコメント

Amazon Linux2022のことが発表されて、しばらくプレビュー版のまま。なかなかGAにならないなぁと思ってはいたけれど、もう7月。2022年の半分が終わってしまったことになる。いっそ、Amazon Linux2023くらいにしておいた方がよかったんじゃないかなぁーと無邪気に思ってたら、Amazon Linux2のEOLが延期されてた。延長されたEOLは2024年6月30日。

そっと、Amazon Linux2のFAQページが更新されてるのが興味深い。

AmazonLinux2のEOLが2024年6月30日に1年間延長

PHP8.0を動かすインスタンスを構築しようと思っていて、Amazon Linux2022を待っていたけれど、結局、PHP8.0のEOLが2023年11月26日なのでPHP8.0のEOLの方がAmazon Linux2よりも早くEOLを迎えることになるので、まぁ、なかなかGAにならないAmazon Linux2022を待つよりもAmazon Linux2で構築しちゃおうか。

さくらのクラウドのディスクのクローンで「待機中」

2022年6月27日 / 管理人 / 0件のコメント

さくらのクラウドで、サーバーをクローンするためにディスクをクローンしようとしているけど、「待機中」のステータスになって、いっこうにディスクのコピーが進捗するする気配がない。ディスクのコピーは常にインスタンスからアクセスされているストレージ(SANだったっけ)のリソース(帯域幅やCPU)をがっつり使うことになるので、コピーの優先度を上げるわけにはいかないだろう。例えば、複数のユーザーからのディスクコピーのリクエストがパラレルに走らないような制御がなされているんだろうけど…。

例えば、ヤバい！って事態に陥って、急遽、サーバをクローンしようとしてこの状況に直面すると切ないだろうな…と思いながら、まったく進まないプログレスバーを眺めてみたりして。

しかし、AWSだとこういう待ち時間がなかったような気がするんだけどなぁ。インスタンスを起動するときにはAMIの裏側のS3からEBSにがっつりデータをコピーしているはずだし、サーバのクローンをする時にもEBSとS3の間でゴリゴリとデータをコピーしているはずだけど、特にちょっと待ってってステータスになっているのは見たことがない気がする。まぁ、さくらのクラウドがショボいというか、むしろ、AWSのEBS周りのネットワークの帯域幅はどれだけ太いんだって話かもしれないけど。

UQ mobileのデータ高速プランを解約してみた。

2022年3月13日 / 管理人 / 0件のコメント

以前に契約して中途半端にしか使っていなかったUQ mobileのデータ高速プランを解約することにした。

まぁ、データ高速プランはUQ mobileがMVNOっぽいSIMの売り方をしていた時の料金プランで、UQ mobileがKDDIにおけるY!モバイルっぽい立ち位置に移行してからは新規申込みを止めたプラン。今は音声契約が必須になっているので、まぁ、MNOの契約であるにも関わらず、データ専用で(SMSは付いてるけど)3GBで990円というプランは今となっては珍しいと言えるかもしれない。

いざ解約するべく調べてみたら、UQ mobileの解約はコールセンターへの電話のみという…まぁ、今時、なんだかなぁという印象。例えば、Webサイト屋auショップでも解約を受けてくれればいいのに、解約の窓口が電話しか用意しないことで解約のハードルを上げるっていうのはなかなかイケてない気がするけどな。

そして、UQ mobileのWebサイトには「必ず、契約者ご本人さまが、解約をするスマートフォン/携帯電話本体から、電話番号の前に186を付けるなどの方法で携帯電話番号を通知してお電話ください。」と書かれていたが、データ専用プランなので音声の発信ができない。データ通信専用のデータ高速プランなんて忘れられているんだろうな…。いやはや、音声通話できるドコモのSIMが入ったスマホから電話した。

というわけで、UQ mobileのコールセンターに電話したのは日曜日の13時ちょっと前。自動音声応答システムでメニューを選択する方式だった。そして、解約する電話番号と暗証番号を電話機のダイヤルパッドから入力。その後が長かった。オペレーターさんに電話がつながるまでに保留された時間がざっと30分。途中で、このまま待つか、かけ直すような案内もなされるが、休日なんてずっと混み合ってるんだろうし、コールセンターへの電話しか解約窓口を用意してぐったりするくらい保留されて解約を断念してしまったら、解約のハードルを上げてなんとかしようとするKDDIの思うつぼだし。

30分くらい保留音を聞き続けてオペレーターさんにつながった後は早かった。解約にあたっての注意事項が告げられて、それを確認して終了。MVNOなんかはWebで解約を受けてるわけだし、Webでも実現できるとしか思えないやりとりであった。総務省や公正取引委員会はこういうあたりもチェックすべきだと思うんだけどなぁ…。

MySQL5.7をyumでアップデートしようとしたらコケた

2022年1月19日 / 管理人 / 0件のコメント

CentOS7が動いているサーバにMySQL5.7をOracleのレポジトリからyumでrpmを取得する形でインストールしてあったのだが、そのサーバでyum updateをかけたら、yumがエラーで止まった。

The GPG keys listed for the “MySQL 5.7 Community Server” repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.

…GPGが何やらおかしいとのこと。で、調べてみると、以前よりOracleのレポジトリで使っていたPGPキー、CentOS7だと/etc/pki/rpm-gpg/RPM-GPG-KEY-mysqlに置かれることになる、この鍵は有効期限が2022年2月16日までだったそうで、新しい鍵に切り替えられたらしい。

そんなわけで、古い鍵ではアップデートが出来なくなったようだ。だったら、新しい鍵をインポートしちゃえばいいってことで。

sudo rpm –import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

を実行すれば、今のレポジトリで使われている鍵がインポートされるので、yumのアップデートが普通に実行されるとのこと。

ただまぁ、前から2022年2月までの有効期限だったはずだけど、極めて最近になって発覚して、急遽、GPG鍵が新しいものになったようで…。

参考：
The MySQL GPG key seems to be incorrect
https://bugs.mysql.com/bug.php?id=106188

Changes in MySQL 8.0.28 (2022-01-18, General Availability)
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html#mysqld-8-0-28-packaging

Kindle Paperwhite(第11世代)がフリーズ。。。

2022年1月4日 / 管理人 / 0件のコメント

Kindle Paperwhite(第11世代)を購入して使っている。いまのところ、Kindle本は大丈夫そうではあるるが、夜間飛行のメルマガをKindleで読もうとするとページめくりができなくなってフリーズしてしまい、後は強制的にリセットするしかないようだ。うーむ。

一応、Kindle Paperwhite(第11世代)をフリーズさせるメルマガを、かつて使っていたKindle Paperwhite(第6世代)で開いてみても、やっぱりフリーズするので、まぁ、特定のメルマガのデータがKindleのファームウェアをフリーズさせてるんだろうなぁ。いやはや。

Sony「WF-1000XM4」とHUAWEI「freebuds 4i」

2021年10月21日 / 管理人 / 0件のコメント

どちらもANC対応のワイヤレスヘッドホンではあるけれど、やはり、値段の差というか、同じApple Musicの音源を再生したとき(Androidだけど)の解像度がまるで違っていて驚いた。ある意味で、こんな音がなっていたんだって気づかされるくらいには違うかもしれない。

一応、Android機はPixel5なので、WF-1000XM4相手にはLDACをしゃべることができるけれど、コーデックの差とも言い切れない気がするんだけどなぁ。WF-1000XM4と同じくらいの価格のAppleのAirPods Proがどんな感じか気になるけれど、iPhoneでどんな感じかを確認しなきゃならず…なかなかだるいかもしれない。