| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
石原 純: 物理学はいかに創られたか―初期の観念から相対性理論及び量子論への思想の発展 (下巻) (岩波新書 赤版 (51))
石原 純: 物理学はいかに創られたか―初期の観念から相対性理論及び量子論への思想の発展 (上巻) (岩波新書 赤版 (50))
typepad がとっても使いにくいし、なんとかしようという気もなさそうなので、これ以上使い続ける意味はないような気はずっとしていた。hatena を使ってみたら、やっぱりそっちの方がいいので、しばらくは使ってみることにしようと思う。
とりあえず、今までの記事も引っ越してみた。コメントは消えたようだが、コメントした人も知らないうちに引っ越されているのは心外かもしれないから、これはこれでいいような気がする。画像は元のサイトへのリンクなので見えているが、元がなくなれば当然見えなくなるので、どうしたものか。全部手で直すのは面倒だし。
ということで、http://d.hatena.ne.jp/uta46/ なのです。
最近のエントリ：
リンク: log.utashiro.com: 今度は kernel_task だよ (3).
アップルが「仕様」というのは kernel_task のロードを増やすというのが本来狙った動作だといことでしょう（バグなんかでなく）。想像ですが、kernel_task があのようになるのは、通常のプロセスの動作を減らしてCPUの発熱を減らす手段なんだと思います。 その根拠ですが、あまりシステム熱くないときに負荷の高いプロセス（たとえば、シェルスクリプトで while true ループ）を二つも動かしてやると、瞬間的に CPU の温度は 80 度以上になります。ところが、しばらくして kernel_task が 50% も動くようになると CPU 温度は 65度くらいに下がるんですね。これは、kernel_task が実はダミータスクで、ハードウェア的にはスリープしている証左ではないかと。
設計段階からの仕様で、それが日常的に発生することを想定しているのなら「仕様」と言ってくれてもいいけど、他に言いようがあるよねえ。「苦肉の策ではありますが想定された動作です」くらいにしとけばいいのに。
実は、挙動が微妙に僕のマシンと違います。CPU だけ使うアプリを走らせればもちろん CPU の利用率は 100% (200%) になるのですが、それだけでは kernel_task は出しゃばってきません。CPU の温度も一時期90度近くまで上がり、ヒートシンクやパワーサプライも60度を超えますが、徐々に落ち着いて70度ちょいくらいで安定します。これはべったりした机の上に置いて、吹き出し口も塞ぎがちにした、あまりいいとは言えない条件で実験してみた結果です。
あ、でも続けたら再現することもできた。何かのきっかけでスイッチが入っちゃうんだなあ。
これに本当に必要な kernel_task の処理が重なると、利用率が 160% を超えるようになってしまうのでしょう。
あとやっぱり USB デバイスとの関係はあるような気がしています。でも、間接的な要因は何であれ、直接的には熱が上がりすぎることが kernel_task の暴走 (事情がわかってみると「暴走」は正しくないような気もするが) の原因になっているのは間違いなさそうです。
森山さんからのコメント：
うちの MBA の場合 kernel_task が出てくるのもシングルコア化問題と同じく単に温度の問題のようです。
シェルスクリプトで無限ループ回すプロセスを二つばかり上げて、そこで YouTube などの動画を流せばあっという間に kernel_task が 80％くらいになっちゃいますね。扇風機で冷やすとすぐに直りますけど。
今使っているのは二台目の MBA です。一台目のも同じ症状でしたが、アップルに聞いても修理法は確立していないとのことなので、初期不良ということで交換してもらいました。二台目も同じ症状ですので、結局、熱設計があまり良くないということなのではないかと思っています。
そうだよなあ、そうですよねー。やっぱりそれを疑わなくちゃいけないよねえ。でもまさかそんなことはと思ってたんだけどなあ…
今ちょっと不自由な環境にいるもんでそれを試せずにいたのですが、うちからクーラーパッド を持って来てもらって半日程実験していました。結果としては、森山さんの仰る通りオーバーヒートを防げば kernel_task の暴走もなくなりました。前の記事で、こんなことになんで気づかないのかと書いたのがお恥ずかしい。
実際には、ファンを回さなくても、クーラーパッドに乗せるだけで、かなり状況は改善します。
kernel_task の問題についてアップルのテクニカルサポートから回答がありました。「発熱すると kernel_task が CPU タイムを食いつぶすのは『仕様』」。だそうです。 え～！？ 発熱がひどくなるとダミータスク(kernel_task)をスケジュールして、実際には CPU を休ませておくことによって擬似的にパワーセーブしているんじゃないかと思っていましたが、それにしても「仕様」と言い切られるとは。
それは、ひどいなあ…
どこかで「kernel_task って殺しちゃいけませんか?」と訊いてる人がいて微笑ましく見ていたんだが、僕も殺したくなってきたぞ。
kill -9 0
kernel_task 問題はまだ解決していないが、どうやらやはり USB の関係があるような気はしてきた。事情があって、現在常時イーモバイルを使った接続なので、ネットにつながっているときには常に USB が使われている状況なのだ。
USB でバイスとマルチメディア関連の処理が重なると特にまずいような気がする。だから、ネットで YouTube の動画を再生なんてのが最悪の組み合わせで、必ずはまる。この場合、kernel_task が CPU を 160% 以上使う。
この状態でモデムの接続を切っても状態は変わらない。ただし、接続を切って一度再生を中止すると kernel_task の暴走は止まる (こともある)。そして、もう一度再生を開始しても暴走は発生しないのだ。
なんか、割り込み処理に問題があるような気がするなあ。
MacBook Air の片肺問題は、shigeya さんの言う通り、一応 8/22 に出たアップデートで対応されたようだ。このアップデートを当てて以来、多分一度も目にしていない。
MacBook Air のシングルコア化については、いろいろなところで話題になっているが、多くのところで原因がよくわからないという結論になっているのが不思議である。直接的な原因は明らかに熱だからだ。中には冷蔵庫に入れて熱が原因だと結論づけているところもあるが、そんなことしなくてももっと簡単にわかるだろうに。とにかく、だから、単純に過熱しないようにしてやれば片肺化は防ぐことができる。
僕は SANWA SUPPLY の TK-CLN7USV ノート用クーラーパッド シルバー TK-CLN7USV というのを導入したが、これを使っていれば問題はなかった。ちなみに、まつもとさんと違ってメーカーが勝手に送って来てくれたりはしないので、自分で買った。
さて、片肺問題は解決したかに見えるが、どうもアップデート以来 kernel_task がすぐに CPU を 130-140% も食いつぶすという状態になってしまった。以前から kernel_task が暴走気味になることはあって、それが片肺化の原因だと取り沙汰されてもいたのだが、140% というのはいかにも異常である。
しかも、きっかけがわからない。一説によれば USB デバイスが原因だとかも言われているが、そうとも限らないような気がする (あ、でも今試しにイーモバイルのモデムを抜いてみたら下がったなあ…)。まったくの印象だが、何らかのリソースが競合していて、複数の事象の複合的な組み合わせによって発生するような気がするのだ。
しかし、これははっきり言って片肺よりも質が悪い。片肺の直接的な原因はわかっているので、とにかく冷やしてさえやれば解決するし、少なくとも一度スリープしてファンが止まるまで待てば回復するのだ。kernel_task の暴走は原因がわからないし、解消したかに見えてもすぐに再発してしまう。前途多難なのだ。
だってさ…
http://www.nhk.or.jp/digitalnative/
Macbook Air の CPU が1つしか動いていない。
そんあことがあると噂には聞いていた。今までは大丈夫だったのだが…
Time Capsule を起動した直後は普通に使えるのだが、しばらくすると無線LANセグメントから見えなくなって、Time Machine が使えなくなってしまう。
基地局としては動いているし、もちろん IP 的にも使える。有線セグメントであれば Time Machine も使えるし、管理ユーティリティからも見える。
どうも、無線LANセグメントでは Bonjour 的に見えなくなってしまうみたいなのだ。なんでかなー
G4 cube がさすがに限界になってきたので、iMac を導入した。1G Ether でつないで Time Capsule を使ってみると、ピークで大体 10MB/sec 程度の転送量だ。
Macbook Air を 100M でつなぐと 8MB/sec だったが、この違いはネットワークの限界なのか、CPU やディスクの性能によるものか判断できない。
TIme Capsule (1T) を買ったので、Time Machine で MacBook Air のバックアップをとってみている。
11n でやっていたらどうも時間がかかるので、途中でやめて 100M Ether に変更してみた。
それまで、ピークで 2MB/s だった転送速度が 8MB/s 程度になったので、実効速度は約4倍程違うということか。やはり、100M でも有線の方がだいぶ速いようだ。
11n は、100Mbps 超の通信速度が出るらしいので、基本的な性能は 100BASE-TX に匹敵するのだろう。実環境での通信速度の違いは全二重と半二重の違いによるものではないかと推測する。
5000個パケットを送る間に、3000個も帰ってくるんだからさもあらん。もすこし、プロトコルを工夫することはできないものか。
総務省を辞めて倉敷市長に立候補していた伊東香織さんが見事当選した。これを接戦というのかどうかよくわからないけど、圧勝ではなかったことは確かだ。総務省時代に縁もあった伊東さんは応援していたし当選して嬉しいし是非頑張ってもらいたいが、半数以上の投票者は別の候補者に投票していたということを忘れちゃいけないんだろうなと思う。
リンク: 永井孝尚のMM21 > MacBook Airの「演繹法的発想」開発手法は、ビジネス分野でも参考とすべき : ITmedia オルタナティブ・ブログ.
難しいことはわからんけど、修正して帰納法と演繹法を逆にしたことで、記事の内容が台無しになっている気がするのは僕だけだろうか？
元の文章には細かい部分は抜きにしてノリとしては共感できるのに…
リンク: log.utashiro.com: emobile D02HW は使えるのか、使えないのか? (反撃に遭う)
散々苦労させられたが、なんのことはない、専用ユーティリティは起動する必要がないことがわかった。普通にモデムの接続コマンドでつながるじゃないか。
リンク: log.utashiro.com: emobile D02HW は使えるのか、使えないのか?
相変わらず CPU を40%使い続けるので、頭にきて kill -STOP してやった。
ザマミロ!
今日から emobile の D02HW を使い始めた。環境は PowerBook G4 15" (1.67GHz) で、OS は Mac OS 10.4.11。
一応は使えているのだが、いろいろと問題があるようだ。
まず、インストールした時に使っていたネットワークを指定しないと使えない。違うネットワークでユーティリティを起動すると、すぐに落ちてしまう。バグですね。後で変更できればいいのだが、今のところうまくいっていない。マニュアルに記載されている設定を手動で入れても動作しない。もう少し試してみる必要あり。
より重大な問題だと思われるのは、接続ユーティリティが CPU を使いまくること。何もしてなくても、常に CPU の 30% から 40% を使い続ける。アプリを終了すると接続は切れる。今はAC電源がつながっているからいいが、バッテリー駆動だったら一体どうするというのか。試しに電源ケーブルを抜いても変わりはない。
なんで、こんなひどいソフトを作れるのか理解に苦しむ。
マニュアル上のサポートバージョンは 10.4.10 までだが、多分関係ないと思う。
国産の子供用自転車と違って、プジョーの自転車には鍵がついていない。
簡単なのはチェーンロックだが、小学生には扱いにくそうな気がして固定式の鍵がないかと探してみると、crops というメーカーの「ブースターロック」がなかなかイカシテルので通販で購入。もう20年以上も前になるが、1986年に初めてアメリカに行った時、バークレーで見かけた KRYPTONITE の鍵が気に入って、出張中に自転車屋を探しまわって手に入れたのを思い出す。
これは、ロックしたところ。
我が家に3台目のプジョーがやってきた。
1台目は息子1号の自転車。2台目は 307cc。3台目は息子2号用。前の自転車は普通に自転車屋で買ったのだが、プジョーは何年か前に普通の自転車販売から撤退して今はプジョー販売店のみで扱っている。いろいろあった末、結局車と同じ目白店で購入。当然のことながら在庫はないので、しばらく待たされる。入荷したというので 307cc で引き取りに行くといったら、絶対乗らないからと言って、営業さんが 307sw で配達してくれた。
BLACK & SILVER for Kids: 選択肢は1つしかないので悩む必要はないのだ。国産だと2万5000円くらいで買えるので4万円とちょい高めだが、まあ許容範囲か。
3台並べるとこうなる。
ユニマガクラシックの発売を記念して 11/3 に Real UNIX MAGAZINE day というシンポジウムが開催されます。
案内と申し込みはこちらからどうぞ。
基調講演には、おそらく日本最古かつ現役ハッカーの和田先生と、本職は画家だと言いながらも国内での UNIX の普及に大きく貢献した岸田孝一さんにお願いしてます。
それ以外は、ライトニングトーク形式で多くの方々にいろんな話をしてもらうことになっています。俺にも話させろというのも多分ありなので、そういう人は事務局にねじ込んでください。
また、ビンテージコーナーと称して、参加者が懐かしいアイテムを持ち寄って展示する企画もあるので、これぞと思うものをお持ちの方は是非持って来て自慢しましょう。
僕は、James Gosling のサイン入りの X10R3 のマニュアルを持って行こうかなあと思っています。これは、1986年に Sun Microsystems に行った際に、Gosling のところに押し掛けて X Window について教えてもらった時にもらったもの。その時は何も知らなかったのだけど、当時、彼は CMU での Andrew Window Manager の成果を基に Sun で新しいウィンドウシステムを開発するために引き抜かれていたんですね。結局成功しなかったけど後の NeWS ね。で、NeWS の最大のライバルはもちろん X だったわけだ。だから、彼のところに行って X Window について質問するというのは、今から考えるととても失礼なことだったような気がするのです。でも、親切に教えてくれてサイン入りのマニュアルをくれた Gosling は心優しい人だったのだ。という背景を知って眺めると、なかなかに感慨深いアイテムなのです。
6月に端末を P904i に換えたらメールに「ゴミ箱」ができたので、スパムはまめにそこに移動している。
9月末からスパムが増えたような気がするので、ゴミ箱に溜まっているメールを数えてみると確かに増えてますね。中身は出会い系が中心。
機種を換えた直後にも増えたような気がしたので、絶対ショップから漏れたと思っていたのだが、これは一ヶ月程で沈静化ている。しかし、これまではインターネットからのメールをすべて許可していたのを、指定したドメインのみ受け取るように変更したような気がする。
1日に30通以上送られちゃかなわんと思っていたのだが、その後少し落ち着いているようだ。他にも、結構フィルタをかけているので (たとえば ezweb からのメールは受け取らない)、何もしないと大変かもしれない。
ユニマガクラシックが 9/18 についに発売されますよっ！
内容と制作の苦労を考えると18000円は安い。
これでバックナンバーを処分できるか。
キャリアと同時にラゲッジマットも導入。
タイヤをスタッドレスに交換。走行距離 5700km。ディーラーお勧めのブリジストン Blizzak REVO1 205/55R16。サイズは標準のものと同じ。少し狭い方がいいかとも思ったけど、大差ないというので同じにした。ホイールは標準のものに装着。ノーマルタイヤを17インチにしようかとも思っているが、春になってから考えよう。チェーンも買おうとしたら、ショップの店員はクリアランスが小さくて厳しいという。持ってても使ったことはないので、なくてもおそらく困りはしないのだが、どうしようか思案中。
9月に会社のウイルスフィルタの設定が変わって、ウイルスを除去したメールが配送されなくなった。そのため統計データがとれなくなったので、今までのデータを処理してみた。グラフは「個人宛」に届いた一日あたりのメールの数。一番下の水色の部分がフィルタでウイルスと判定されなかったメールで、それ以外はすべてウイルス。
見れば明らかなようにウイルスの数は順調に減っている。2004年には、定常的に一日あたり15000通近くのメールが届いていたが、今年は3000通程度まで落ちた。
ウイルスの活動が活発な時期には、フィルタされないメールの数も増えているが、これは僕が送ったウイルスメールによって発生した送信エラーが返ってくるため。もちろん実際に送るはずはなく、差出人として詐称されているのである。
2004年に突出した部分があるのは、毎週月曜日になると NETSKY.Q (青) が４万通送りつけてきたため。ただし、これには時限があったのでその後ぴたりと止まった。
NETSKY がはじまる前の山は MYDOOM。フィルタがまにあわず、最初の数日間はそのまま配送されている。この時は随分ひどいウイルスだと思ったが、その後の NETSKY に比べれば可愛いものだった。ちゃんと時期が来たら終わったし。
結局、届いているウイルスのほとんどは NETSKY。HTML_Netksy.P (赤) と WORM_NETSKY.P (緑) は、フィルタの出力がちょっと違うだけで、多分同じものではないかと思う。今年の5〜6月あたりにフィルタの仕様が変わったらしく、一時期両者を同じにとりあつかっている。全体を通じて半分以上は NETSKY.P なのだ。残りの大半は D (黄) と Q (青)。
リンク: Yahoo!ニュース - ランキング
残念ながら11位とベストテン圏外。来週は難しいかな。「まるごとPerl」が、なぜかランクインしている。そういや、自分で書いた記事もまだ読んでなかった。
リンク: Yahoo!ニュース - ランキング
「C/C++ セキュアコーディング」今週も2位でした。残念。1位は Binary Hacks。僕も買いました :-)。
ちなみに、アマゾンでは2531位。おー、セットでお勧めされている。下はアマゾンの画像をコピペしただけなので、クリックしても購入はしません。
最近のコメント