DFWikiからN Wikiへの移行

moodleは早くもまもなく1.8 releaseが出そうな勢いであるが、とりあえず現在の1.6.2から1.7系に移行する準備として、非標準のDFWikiのデータ移行を調べていた。そうすると、どうやら、DFWikiから派生したMoodle N Wiki（NWiki）というのが1.9から採用されることになるようで、まずはこれにデータを移行させてしまう方が安全そうである。

というわけで、DFWikiのサイトにあるHOWTO - Install N-Wiki in Moodle 1.6 ?を参考に入れようとしてはまった。

書いてあるとおりに、wiki_rev2007011901.zipをダウンロードして展開し、moodleのディレクトリにコピーしてmoodleに接続すると、テーブル等の更新が行われて…、まではよかったが、モジュール管理に行くと、dfwikiの活動数が0になっておりWikiモジュールが見あたらない。つまり、データ移行まで自動的に行われてしまったのにモジュールが使えない状態になった。さらに悪いことに、元々の設定では、DFWikiがあるからと思い、Wikiを非表示に設定していた。このために、どのコースからも実体が見えなくなってしまった。

で、何度も運用版のmoodleとデータをコピーしなおしては試していて、ふと、ブロック名の一部が???とかになっているのに気付く。日本語っぽい雰囲気からja_utf8/wiki.phpを見ると、すべて文字化けしていた。zipで配布されている元のファイルが壊れていた。で、日本語のモジュール名になっているせいで表示できない可能性もあると思い、とりあえずこのファイルを消したところ、Wikiモジュールが復活し、元からあったDFWikiの活動が移行されていることが確認できた。

次は1.7。Wikiモジュールをちゃんと更新してから接続しないといけないので、ちょっと二の足ぎみ。

moodleでloginhttpsを選択可能にする自分用メモ

SSLの鍵と証明書を/usr/local/etc/apache2の下に（でもどこでも）置いてssl.confを設定し、/etc/rc.confでapache2ssl_enable="YES"とすればhttpsでのアクセスもできるようになる。

しかし、moodleでログイン時のみhttpsにするloginhttpsの設定ができるようにするには、phpからhttpsがfopenできなければならず、それにはsecurity/php5-opensslをインストールしておく必要がある。php.iniは特にいじる必要なし。

それにしても、最近のサーバ証明書は、5年有効再発行付き法人後払い可で2万円で手に入るのか。OとかOUとかまともにつかないけど、moodle用途なら十分。

Yahoo! Site Explorerがmetaタグ認証に対応

ずいぶん前にYahoo! Site Explorer（Google Webmaster Toolsのyahoo.com版）にこのサイトを登録したが、これまで認証はファイルベースであったため、blogspotのブログは認証できていなかった。

で、今日見てみたところ、いつのまにやら(どうやら1月末ごろから)metaタグでAuthentication（GoogleでいうVerification）ができるように改良されていたようで、早速やってみた。

Core 2 Duoマシンのcpufreqによるクロック周波数制御

このCore 2 Duo E6600のPCはわりとつけっぱなしにするので、（FreeBSD）そのパソコン、無意味に熱くなってませんか？ ――― CPUの消費電力を減らす方法を参考にいじって電力を調べることにした。

もともと、sysctlでは、

dev.cpu.0.freq: 2400
dev.cpu.0.freq_levels: 2400/88000 1600/56000
dev.acpi_perf.0.freq_settings: 2400/88000 1600/56000

となっていたが、書いてあるとおりにkldload cpufreqをすると、

dev.cpu.0.freq: 2400
dev.cpu.0.freq_levels: 2400/88000 2100/77000 1800/66000 1600/56000 1400/49000 1200/42000 1000/35000 800/28000 600/21000 400/14000 200/7000
dev.acpi_perf.0.freq_settings: 2400/88000 1600/56000

となり、非常にキメ細かくコントロールできそうに見える。

そこで実際に、dev.cpu.0.freqをいろいろいじって、本当に速度が変化しているか実測してみた。ベンチマークはmake -j4 buildkernel。まずは、cpufreqをロードする前の状態。

周波数設定	ユーザCPU時間	システムCPU時間
2400	462	51
1600	461	53

次に、cpufreqをロードした後の状態。

周波数設定	ユーザCPU時間	システムCPU時間
2400	462	51
2100	540	60
1800	645	72
1600	Invalid argument
1400	Invalid argument
1200	808	88
1000	Invalid argument
800	Invalid argument
600	1637	170
400	Invalid argument
200	Invalid argument

つまり、cpufreqをロードしていない場合は周波数を設定しても無意味であり、ロードした後でもすべての周波数が設定できるとは限らない（Invalid argumentが出ても実はdev.cpu.0.freqの値は設定されてしまうが、設定するたびにバラバラの性能になる）。きちんと設定できていれば、性能はほぼ比例している。

続いてワットチェッカーで電力を調べた。

周波数設定	アイドル時電力	ピーク電力
2400	102	148
2100	102	143
1800	102	140
1200	102	135
600	102	126

つまり、アイドル時電力は周波数とはまったく無関係であった。ピーク電力はそれなりに周波数に依存するが、全体に比べて大した差が出るわけでもない。

PCをほったらかしにしているようなアイドリング時に自動的に周波数を下げて消費電力を抑えてやろうと思っていたが、これではほとんど何の役にも立たないことになる。別の見方をすれば、最近のCPUの技術では、アイドリング時はあちこちのクロック(あるいは電源？)供給をカットして、止まっているのとほとんど同じにできるんだろうなと想像される。

とりあえずグラフ化してみた。


追記（2/26）

上のグラフを出すのにgnuplotに食わせたソース(自分用メモ):

set terminal png large
set output "cpufreq.png"

set xrange [0:2500]
set xlabel "Frequency (MHz)"

set yrange [0:1.1]
set ytics nomirror
set ylabel "Performance (normalized at 2400MHz)"

set y2range [0:150]
set y2tics 20
set y2label "Power consumption (W)"

set label "Performance (make -j4 buildkernel)" at 600,0.25
set label "Power (idling)" at 600,0.72
set label "Power (peak for make -j4 buildkernel)" at 600,0.9

plot "-" using 1:(513/($2+$3)) notitle with lp, \
"-" using 1:2 notitle axes x1y2 with l, \
"-" using 1:2 notitle axes x1y2 with lp

#  f   u  s
2400 462 51
2100 540 60
1800 645 72
1200 808 88
600 1637 170
e
#  f   W
2400 102
600  102
e
#  f   W
2400 148
2100 143
1800 140
1200 135
600  126
e

RTL8110SCは7-currentでも動作せず

RTL8110SCによるre0: watchdog timeout問題は、6.2-STABLE, 7-CURRENT （2/22時点）ともに解消していなかった。というわけで、心置きなく、6.2-RELEASE + Realtek謹製ドライバを使い続けることにする。

FreeBSDのRealtek RTL8110SC用イーサネットドライバ

マザーボード内蔵のRTL8110SCでre0: watchdog timeoutが出るおかげでacpiを切ってしまった新マシンであるが、ダメもとでRealtekのサイトに行ってみたところ、ダウンロードページで8110で検索して出てきたRTL8110SC(L) (Software)のページに、FreeBSD用があっさりと置いてあった。Readme.txtによれば、4.x/5.x/6.0でテストしたとのことである。

Readme.txtにはいろいろと細かい手順が書いてあるが、ようは、

1. reのない（適当にnodevice reとかした）configファイルを用意する。
2. /usr/src/sys/modules/Makefileからreを消す。
3. 付属のif_rl.cとif_rlreg.hを/usr/src/sys/pci内の同名ファイルに上書きコピーする。
4. カーネルを普通にコンパイルしてインストールする。
5. いじったファイルを元に戻しておく（でないと、忘れてcsupとかしてどうなるか予測不能）。
   

だけである。ただし、3.で、if_rlreg.hをそのまま使ってしまうと、/usr/src/sys/dev/mii/rgephy.cが参照しているRL_GMEDIASTAT*のマクロが消えてしまうので、もとのif_rlreg.hから該当する定義をそのままコピーしておけばよい（たぶん）。

そして、/etc/rc.confのifconfig_re0をifconfig_rl0に書き換え、/boot/device.hintsのhint.acpi.0.disabled="1"を消し、再起動した。そうすると、見事に、

rl0: <Realtek RTL8169SC Gigabit Ethernet Adapter> port 0xce00-0xceff mem 0xfdeff000-0xfdeff0ff irq 21 at device 6.0 on pci3

と認識され（8110SCは8169SC扱いになるようだ）、rl0による接続が可能になった。

ネットワークの負荷を上げてみても、re0のようにwatchdog timeoutとlinkのDOWN/UPを起こしたりしないし、acpiを切った状態でもtcpdumpを開始したり終了したりする際に、

re0: promiscuous mode disabled
re0: link state changed to DOWN
re0: link state changed to UP

となっていた問題も解消した。

最近もif_re.cとかはよく更新されているようであるが、早くこの手間をかけずに済むようになることを期待。