玄箱でポータブルサーバー
Kuro box with front USB
このところ客先での作業が多くなってきたので、 出先用にポータブルサーバーが欲しくなってきた。
そこで思い出したのが信頼性の面でちょっと不安で買ってからしばらく放置していた 玄人指向の玄箱という名前の USB ポート付き(*Note2)の NAS(Network attached storage)。 中身は PowerPC の Linux マシンで基本的には Baffalo の LinkStation と同じ。ちょっといじればそこそこましになるかも。 [Mar.11, 2005]

まずは、Buffalo の LinkStation で液洩れ報告のあった電源のコンデンサ(Ltec LZG)の交換から。 玄箱は特にメインボードの出来が結構良いだけに電源のちゃちさが気になる。 見たところ、25 W クラスの電源に見受けられるが、 オリジナルのままだとの電源の出力コンデンサがリプル電流の為か相当熱くなっている。 これなら早々に液洩れしても不思議あるまい。

5V 出力のコンデンサ C203 とC204? を ニチコンの HN 3300uF/6.3V (UHN0J332MHM6) と 松下の FK 1500uF/6.3V (EEUFK0J152L) に交換。 各コンデンサに並列に 太陽誘電の積層セラミックコンデンサ 22uF/6.3V (JDK316BJ226ML) を追加。

12V 出力のコンデンサ C201 と C202? を ルビコンの ZLH 1500u/16V (16ZLH1500M) と 三洋の MV-WG 1000u/16V (16MV1000WGL) に交換。 各コンデンサに並列に 京セラの積層セラミックコンデンサ 10u/25V (KC70E1E106M) を追加。

結果、連続稼働でもコンデンサはほの暖かい程度になった。

[fig.1 電源の出力コンデンサ]
 Vo capacitors

小容量ケミコンも信用できないので、 U3 (TLC431CLP 相当品) の帰還コンデンサ C206 を三菱マテリアルの積層セラミックコンデンサ 1u/50V (KC30E1H105M) に交換。

(注:部品は全部、手元にある奴を使ったので必ずしも最適なものとは言えない。 特に C201 は UHV1C272MHD か KZE16VB2700MK30 か 16MV2700WX あたりにしたいところ。)
(コンデンサ・ア・ラ・カルト。でもニチケミとか TDK も抜けてるな〜)

[fig.2 電源に追加したセラミックコンデンサ]
 Vo capacitors

念の為、メインボードのコネクタ部の電源電圧をオシロスコープで見てみた。 負荷変動はややあるものの 5V は特に問題無し。

[fig.3 5V 電源電圧波形 CN3-11 (AC, 50mV/div, 1s/div, EBW=35MHz, コンパイル作業中)]
 5V load regulation
(うーん見にくいなー。オシロ別のにするか〜。)

電源の 12 V は TR3 (NEC uPA1770) (fig.12 右端) でスイッチされてオンボードスイッチング電源の入力と ファンの電源とハードディスクの 12V 電源に接続されているが、ここのコンデンサ C5 (fig.12 中央 オリジナルでは Sanyo MV-WX 220u/25V) 他の ESR ではまだリプル電圧が約 80mV と大きくスパイクノイズ を含むと peak-to-peak で約 200mV のノイズがあった。 今回使用するハードディスク(後述) HGST D7K250 シリーズの 12V 電源入力の許容ノイズは 150mVp-p なのでもう少し下げたい。 そこで fig.4 のように京セラの積層セラミックコンデンサ 10u/25V (KC70E1E106M) を 3 個追加したところ fig.5 のようにリプルは約 30mV に低減された。 また負荷時においても fig.6 のように約 170mVp-p に低減された。 HDD の電源コネクタ端子で測定した場合には約 120mVp-p となり、どうにか要求仕様を満たせるようになった。 それにしてもオンボードスイッチングレギュレータ部分が最大の輻射雑音源ではないだろうか。 EMI 対策上もう少しどうにかしたい気がする。

[fig.4 12V スイッチ周辺に追加したコンデンサ (右上に見えるのは測定用 GND 端子)]
 Capacitors at V12 switch

[fig.5 12V スイッチ出力電圧波形 CN3-1 (AC, 50mV/div, 2us/div, BW>100MHz, アイドル時)]
 5V load regulation

後日 C5 を 日ケミの固体アルミコンデンサ 16PS330MJ12 に交換してみたところ、 数 MHz あたりのリプルは若干少なくなったがスパイクノイズのレベルは変わらなかった。 試しに転流ダイオード D1 に並列に 56Ω + 270pF のスナバを入れてもみたが、そもそも D1 部分にリンギングは観測されてなかったので無意味だし事態を悪くする。 どうも、TR4 (NEC uPA1717) がオンするときの TR4 の出力の浮遊容量等を充電するパルス電流に よる C5 側の電圧降下に起因するようだ。TR4 のゲートと IC3 の間に付いている ダンピング抵抗 を 22Ωから 33〜47Ωあたりに若干大きくしてやると TR4 が オンになる時間が増大してスパイクノイズのピーク電圧も 2〜3 割ほど 低下した。今は 33Ωにしてあるが当然スイッチング損失は増大するし、 温度特性の問題もあるので積極的に変更する意味はあまり無いだろう。

[fig.6 12V スイッチ出力電圧波形 CN3-1 (AC, 50mV/div, 1s/div, BW>100MHz, ハードディスクアクセス中)]
 12V load regulation
(注: AC カップリングで測定しているので波形にはサグがある)

次は、プロセッサ周り。
MPU 用クロックモジュール X4 のデカップリング強化とジッタ対策のために ジャンパ抵抗 R83 を ACB2012M040 に、 C85:100nF を Murata の 1uF/16V (GRM188F11C105ZA01D) に、 シリーズ終端というかダンピング用にジャンパ抵抗 R84:0Ω を 22Ωに交換した(fig.7)。

プロセッサには PowerPC 200MHz を使っているわりに放熱が甘いので ピンフィンヒートシンクを接着(fig.7)。ハードディスクマウンタのリブとの干渉に注意が必要。

[fig.7 プロセッサ周り]
 Processor and heat sink

対策前には X4 の電源端子にはちょっと大きめ(約 200mVpp)の雑音が乗っていたが、 スイッチング電源部分を含め対策後は約 50mVpp (fig.8)になったので必要十分か。

[fig.8 発振モジュールの電源電圧波形 X4-4 (AC, 50mV/div, 40us/div, BW>100MHz)]
 Vdd at X4

他に気になるのは、玄箱のリアルタイムクロック IC7 には RICHO の RS5C372A が 使われているが、 RS5C372A には発振安定容量も時計誤差補正回路も 内蔵されているのに外付けで C57, C58 が付けられているところ(fig.9)。 水晶振動子 X2 の特性との兼ね合いなのか (ESD 対策かとも思ったが他の部分に比べてバランスが悪いし) 理由が不明。

[fig.9 RTC 周り]
 Processor and heat sink

ついでにワッチドッグタイマの動作も確認。
PowerPC のクロックを停止させてみたところ、ちゃんとワッチドッグタイマがファイアして 電源がシャットダウン、DIAG LED が点滅する状態になった。ちゃんと働くのでOK。

次はハードディスクだが、そもそも玄箱に入れるのは 5400rpm の低発熱ハードディスクを想定してると思うが、 うちに余ってて今回使おうとしているハードディスクは HGST の HDS722512VLAT20(120GB, 7200rpm) なのでちょっと対策が必要だろう。 ハードディスクの寿命はスピンドル部の温度に大きく依存している。 ハードディスクの故障はメディアとヘッドのメカニカルな故障を除けば、 スピンドル部の摩耗故障とコントローラ部の偶発故障が多い。 様々な試験データからスピンドル部の温度上昇を押えてやれば故障率を低減できる ことが分かっている。

玄箱の場合、ハードディスクマウンターで蓋がされてしまうような構造の ため強制空冷の効果が低いのに加えてスピンドル部の反対側にはプロセッサがある。 このままだとスピンドル部がプロセッサの熱であぶられることになる。

そこで、スピンドル周りにセラミック系サーマルインターフェースマテリアルを 張り付け(fig.10)、 マウンタ側には スピンドル部とコントローラ部のヒートスプレッダとして 120 x 60 x t0.5 の銅版を接着した(fig.11)。 マウンタの鉄板のままだと鉄は熱伝導率がアルミの 約 1/10 と低いためヒートスプレッダとしては期待できない。 コントローラ部の主要チップには熱伝導ゲルを張り付けマウンタへの伝熱をはかることにする。(fig.10)

[fig.10 ハードディスクとサーマルインターフェースマテリアル]
 HDD thermal interface

ハードディスクの動作モードは Hitachi Feature Tool を使ってアコースティックマネジメントもパワーマネジメントも 0x80 に設定して消費電力を下げておく。どうせイーサネットも 100BASE/TX だし、 プロセッサも非力なので性能に変わりはない。

[fig.11 ハードディスクマウンタ]
 HDD mounter

玄箱の冷却は排気ファンに大きく依存しているのでもう少しましなファンに交換 した方が良い。 最初からついていたやつは ADDA AD0412LX-G76 (12V-70mA, 4,800rpm) で流体軸受っぽいが 国産品以外の小口径(4cm)の流体軸受けファンはいまいち信用できない。 信頼と実績なら Sanyo Denki か Nidec か 松下あたりだが、 たまたま手元に多少はましなボールベアリングの GLOBEFAN B0401012H (12V-100mA, 6,000rpm, 5.91CFM, 50,000h) があったのでこれに交換した。

ファンの交換の前後で hddtemp を使ってハードディスクの温度をモニターして みたが定常状態で Ta=22℃ の時で 42℃ から 40℃ へと流量の増加から期待して いたほどは温度が下がっていない(fig.13 赤色と緑色)。 あれ?カバーを外してもう一度みてみる。 ファンの駆動電圧を見てみると約 7V で約 4500rpm で動いている。 どうも ATMEL のマイクロコントローラ AVR が制御してるようで、起動時(と多分高温時)に TR1 (NEC uPA1717) がオンになってフルスピード、それ以外は R7+R5 でファンに直列に 112Ω が 入ってる状態になっている。そこで R7:56Ω を外してジャンパの代りに手元にあった TDK のチップフェライトビーズ (ACB2012M040) に(サイズは違うが)交換した。 これで通常時は 9.3V / 5500 rpm 、フルスピード時には 11.7V / 6800rpm になった。 通常時でも少し喧しくなったけれどフルスピード時に比べればそれ程でもない。

(注:いつでもフルスピードにしたければ、TR2 のコレクタを GND (TR2 のエミッタとか)に落せば O.K.)

ファンスピード(TR1)はソフトウェアからも制御出来て AVR にコマンド ]]]] を送ると TR1 が ON、\\\\ を送ると OFF になるようだ。

#TR1=ON (High speed)
/bin/echo -n ']]]]' > /dev/ttyS1 

#TR1=OFF (Low speed)
/bin/echo -n '\\\\' > /dev/ttyS1 


[fig.12 オンボードレギュレータとファンドライバ部]
 series resistor for fan

これで筐体内の消費電力を約 15 W と想定して、 風量から見込んだ筐体内温度上昇 (Note3) を 10℃ 弱、 ハードディスクの温度センサとハードディスク表面温度差を約 4℃とすると、 吸気温度+14℃弱になればおよそあっている。

対策後システムを起動した直後から hddtemp で温度を測り始めた結果をプロットして みた(fig.13 空色)。吸気温度 25 ℃で定常状態で約 37 ℃なのでおよそ目論見通りのようだ。 測定値のカーブフィッティング(fig.13 紫色)から求めた値は、Ta=25.8 ℃、ΔT=11.5℃、tc=1100 となった。

[fig.13 起動時のハードディスク温度]
 HDD temperature

話は前後するが、OS はここ(玄箱うぉううぉう♪) とか ここ(LinkStation/玄箱 をハックしよう) とか ここ(玄箱 Debianサーバ構築メモ) とかを参考にして Linux-Debian に入れ換えた。 ssh を入れて telnet を停止、rsync や bind と ntpd も使えるように(*Note1)して普段は slave サーバ に なってもらっている。 samba や apache, gnuplot, calc, fe, fftw, X, fvwm95 や kde(はちょっと非現実的だが), rdesktop も使えるようになった。 SPICE2g6 が動いたのに気を良くしてどうにか SPICE3f4 もポーティング出来た。 SPICE2g6 で同じ回路ファイルで

Linux + PowerPC@200MHz (Kurobox): total job time 5.38
FreeBSD + Pentium4@3.5GHz (Tyan S5101ANNRF): total job time .25
20倍くらい遅いが使えないよりまし。

[fig.14 玄箱で SPICE3]
X on kurobox

その他、仕事用の内作プログラムやツール類もほとんどコンパイル出来て大分便利になった。 もっとも RAID1 がない(電源容量が足りるのであれば 2.5 インチ HDD*2 とかにして 出来なくは無い)とか、本体ごと全部簡単に持って行かれるっていう最大のセキュリティーホール が残ってはいるが、ソフトのポーティングも含めて延べ 11 日程もいじった 玄箱のおかげで、おでかけ作業が大分楽になりそうである。


*Note1: 玄箱のクロックずれ対策

カーネルの周波数計算の問題なのか ntp がなかなか収束しないのでこの辺り(Kernel/タイマーの精度)を参考にして 以下のスクリプト list.1 を /etc/init.d/ntp から呼び出すようにしたらとりあえず収束するようになった。

[list.1 adjtick スクリプト]
#!/bin/sh
# name:adjtick.sh (for KUROBOX)
adjtimex=/sbin/adjtimex
awk=/usr/bin/awk
grep=/bin/grep
cat=/bin/cat
test -x $adjtimex || exit 0
test -x $awk || exit 0
test -x $grep || exit 0
freq_base=24.576000
tick_base=10076
freq=`$grep "decrementer frequency" /var/log/dmesg | $awk '{print $4}'`
tick=`$awk < /dev/null 'END {t=int(((y/x)*z)+0.5);printf("%d\n",t);}' \
x=$freq_base y=$freq z=$tick_base`
echo "freq.base="$freq_base", tick.base="$tick_base", freq.="$freq", tick="$tick
$adjtimex "--tick" $tick
exit 0

後日 kernel のソース(arch/ppc/kernel/melco_rtc.c) を眺めてたら 周波数キャリブレーションがろくでもないことが判明。 1秒間を求めるのに (とっても遅い) I2C バスの先に繋がってる RTC の時刻を読んで変化を見てるのがあほらしい。 そもそも RTC RS5C372A は設定で 5pin に PPS(Pulse per second) 信号が 出せるので PowerPC のハードウェア割り込みなり入力ポートなりに入れて やれば良いのに活用していない。 というか、RS5C372A で個別キャリブレーションをしたとしても RTC のクロック確度と、 PowerPC のクロックに使われているような水晶発振モジュール の 100ppm 程度の確度だと確度に有意な差が無いので、 水晶発振モジュールの周波数から計算した値をそのまま使った方がましである。

クロックずれの顛末。
list.1 で補正パラメータ 'tick_base' が 10076 ってことは X4 の周波数が 約 32.52 MHz ってことで実際に測ってみてもそんな周波数である。 最初はシリアルポートのボーレート 57600 に都合が良いようになってるのかなと 思っていたが、 X4 のマーキングは 32.768 なので (fig.9 右) いくらなんでもおかしいと思って 外してみた。
えっ 6 端子?もしかして、これ VCXO じゃないのか? (fig.15 左上)
もしこれが VCXO で制御電圧がかかっていないのならマーキングに比べて 異常に低くなっている周波数にも頷けるし、だとしたら発振停止したりしないのか不安である。 なんかエプソン電子デバイスの VCXO のようにも見えるが手元のカタログに載っていないようだし 気持悪いのでトヨコムの 水晶発振モジュール(TCO-787RH3 32.768M)に交換してみた。(fig.15) これだと list.1 の 'tick_base' も当然の如く 10000 で最も時刻のずれが少なく ntp の収束も早くなった。

[fig.15 水晶発振モジュール]
Crystal oscillator

取り外した 6 端子の発振モジュールを実験基板を作って調べてみた。 玄箱の基板で N.C. になっている 2 番パッドに約 Vdd / 2 以上の電圧を印加すると ほぼ正しい 32.768MHz が出力されるようになる。 2 番パッドがハイレベルで通常動作、ローレベルでは省電力になるようだ。 同じく Vdd に接続されている 1 番パッドは制御電圧入力のようで、ここの電圧 を調整すると約 3.08V で 32.768MHz に合わせることができた。 電源投入時に1番パッドの電圧が低いと (例えば Vdd / 2 だと) 発振開始しないことがあった。 この場合1番パッドの電圧を一瞬 Vdd 程度にしてやると発振開始した。 正常動作時はジッタも (内部が水晶 + PLL/VCO の) TCO-787RH3 より少なく 短期安定度も良好だった。ということで やはり VCXO が間違って使われているんじゃないか?もったいないなぁ。 (どうせなら 1ppm クラスの TCXO にでもロックさせてやれば良いのに。)
# 元のやつのままでも 2 番パッドを Vdd にプルアップしてやるだけで大分まし (100ppm 確度程度)になるかもしれない。

# 後日 Link Station/玄箱 Hack BBS にこの件をポストしたところ【No.2393】に Junker さんから玄箱HGでの報告がありました。
# 参考のため以下抜粋して引用。
黒箱HG
 6端子用ランドに6端子モジュール
 1・2番ピン間に抵抗用空きランドあり
玄箱HGの空きランドをハンダでショートし、カーネルを変更。
freq を 32.768MHz 固定 tick 補正無しで1時間のズレを計測してみました。

結果は2回計測で(外部タイムサーバー)
-0.002565 秒
-0.062572 秒
となり、十分実用となりそうです。

ついでに簡易 OCXO 化。
取り外した水晶発振モジュールが結構まともだったのと、 随分と前に基準発振器に使っていたクリスタルオーブン が手元にあってその容積が 7 x 8φ とモジュールごと入れられたので、 もう少しまともな ntp サーバーになれるように 空きスペースに簡易 OCXO を作って (fig.16) クロックの安定化をはかってみた。 ntp を使うので中期安定度があれば良く絶対精度は不要なので電源と制御電圧は ローカルレギュレータで安定化した 3.3V を電圧固定で供給している。また、 排気ファンが近いのでオーブンは 10mm 厚の発泡ウレタンで断熱してある。

[fig.16 簡易 OCXO モジュール]
Oven controlled crystal oscillator

水晶発振モジュールを簡易 OCXO 化した玄箱をウォームアップした後 ntpd を起動し、 その後 6 時間の ntpd の過渡応答の例を fig.17 に示す。 ntpd のログファイル loopstats から周波数と安定度をプロットした。 参照する ntp server には実験のためネットワーク的に近い (10ms < delay < 20ms) 外部の公開 Stratum 1 ntp server を 5 つ指定した。 4 時間程で 0.001 ppm 以下の安定度まで素直に変化して行くのが見て取れるので 簡易 OCXO 化の効果はあったようだ。

[fig.17 ntpd 起動時の過渡応答]
ntpd transient response

ntpd に問題の予感。
余談だが、 ntp.conf に

tinker huffpuff 7200
オプションを指定してやらないと不安定な挙動を示すことがあった。 定常オフセットがずっと残っていてそれを補正するように周波数がどんどんずれていく感じ。 自宅のインターネット接続環境では上りと下りでバンド幅が違うからではないかとも 思う(が ntpd のループフィルタも怪しい気がする)。 ADSL や CATV 接続の場合は注意が必要だろう。

簡易 OCXO にしてから ntpd のループゲインとかが気になったので ntp-4.2.0 の ntpd/ntp_loopfilter.c を見てみたらループゲインのデフォルト値などが 変更されていた。 それで ntp-4.1.0 から ntp-4.2.0 に変更したのだが ntp-4.2.0 では tinker huffpuff には上記のように引数が必要になっていた。 tinker huffpuff を指定してもどうも PLL の応答としてはまだ何かおかしいので継続調査中。 [Apr. 9, 2005]

ntp-4.2.0 の ntpd のループフィルタを暫定的に修正、 簡易オフセットキャンセラを実装してみたところ 周波数の追従が良くなりオフセット変動が少なくなったようだ(fig.18)。 もう少しちゃんと考えてみようと思う。[Apr. 12, 2005]

[fig.18 ntpd-4.2 修正版(beta1) 起動後の周波数追従特性とオフセット変動 (maxpoll=8, burst mode)]
frequency drift and offset

それにしてもクリスタルオーブンの効きはあまり良くなかったみたいで残念。 というか悪すぎ。断熱不足っぽい気がするが対策は後回しに。

もはや玄箱には関係ないが、 ntpd の大きな問題を見付けたので現在改良して確認と試験中。[Apr.16.2005]

ntp-4.2.0/ntpd の PLL(ntp_loopfilter.c) には いわゆるループフィルタは入っていないのと、 非対称遅延による定常遅延に対処されていない (上りと下りの遅延時間差の平均は 0 を仮定している) ので、 1 次予測遅延誤差 3 次平滑型定常遅延キャンセラと、ループフィルタとして 2 次 lag-leed-lag 型のアクティブフィルタをエミュレートして入れたところ もう少しまし(fig.19)になったようだ。[Apr.21.2005]

[fig.19 ntpd-4.2 修正版(beta4) 起動後の周波数追従特性とオフセット変動 (maxpoll=8, burst mode)]
frequency drift and offset

クリスタルオーブンの底の断熱が破れてたので補修したけれど、 AT カットの水晶と違いオーブンの温度では相当温度特性の悪い温度域 に入っているようで周波数安定度の改善はほとんどみられなかった。残念。 ntpd にもう少し誤差の補正の計算を入れてみたところ、わずかだがオフセット変動に 改善がみられた。良く見ると周波数変動もまだ何か ntpd に起因する部分があるような 気がする。もうちょっとましにしたいので遅延補正関係を見直して検証中。 [Apr.27.2005]

[fig.20 ntpd-4.2 修正版(beta5) 起動後の周波数追従特性とオフセット変動 (maxpoll=8, burst mode)]
frequency drift and offset

定常遅延フィルタを 4 次に変更したのと多少の設計パラメータ変更でちょっとだけましになった。変動補償関係は継続検討中。 [May.12.2005]

[fig.21 ntpd-4.2 修正版(beta29) 起動後の周波数追従特性とオフセット変動 (maxpoll=8, burst mode)]
frequency drift and offset

自宅に hp Z3816A を設置したのに伴い LAN 上に stratum1 ntp サーバーが稼働するよう になった。その後、どうにもあまり良くなさそうな簡易 OCXO を 16.384MHz x 2 逓倍 の TCXO に交換した。ntpd はループフィルタの構成を多少変更したが基本的なところは 大きく変わっていない。下図 0 hour を境に簡易 OCXO から TCXO に交換している。

[fig.22 ntpd-4.2 修正版(beta56) 周波数追従特性とオフセット変動 (local stratum1, maxpoll=6, burst mode, 簡易 OCXO→TCXO)]
frequency drift and offset

さすがに参照しているサーバーが LAN 上の stratum1 (2 台)だとオフセット変動は1桁近く減少して いる。さらに TCXO に交換後はオフセット変動は数 10μs 以内に収まっている。 (やっぱり簡易 OCXO は良くなかった。) 図中 TCXO に交換後の部分で 50μs 程に変動が大きくなっているところがあるが、 これはコンパイル等の作業を行っていた時で、通常の変動は少ないものとなっている。 [Jun.22, 2005]

他にもまだ問題点があるし ntpd をもっとまともにするにはもう一つ上のレベルで ntpd の挙動も修正 する必要があるので、誰か ntp 関係の人と ntpd に詳しいプログラマにも手伝ってもらいたいなぁ。 ntp.org に投げるか?


*Note2

玄箱はリアパネルに USB ポートが付いているが、 実は他の部品は全て実装済みな USB ポートがフロント側にも出ていて コネクタを付ければ使えるようになっていた。

[fig.23 フロント USB]
front USB connector

*Note3

強制空冷における吸排気の温度差 ΔT [K] は
ΔT [K] = 筐体内の消費電力 [W] / (風量 [m3/s] * 空気密度 [kg/m] * 空気の比熱 [J/kg⋅K])
で表される。 常温1気圧付近の 空気の密度 * 空気の比熱 を約 1.1e3 [J/K/m3] 、 ファンの風量を規格値の半分程の 1.4e-3 [m3/s] 、 消費電力を 15W とすると 温度差 ΔT は
ΔT = 15 / (1.4e-3 * 1.1e3 )
から、約 10 [K] となる。
www.finetune.co.jp [Mail] Copyright (c) HOSODA Takayuki. All rights reserved.