|
■槻ノ木隆のPC実験室■
玄人志向「玄箱PRO」を使う【改造編2】
|
■■ 注意 ■■
・分解/改造を行なった場合、メーカーの保証は受けられなくなります。 ・この記事を読んで行なった行為(分解など)によって、生じた損害はPC
Watch編集部および、メーカー、購入したショップもその責を負いません。 ・内部構造などに関する記述は編集部が使用した個体に関してのものであり、すべての製品について共通であるとは限りません ・PC
Watch編集部では、この記事についての個別のご質問・お問い合わせにお答えすることはできません。
|
●MTUを変更してみる
|
KURO-BOX/PRO |
前回の工作でシリアルポートが使えるようになったので、早速遊んでみたいと思う。まずいじりたいのはMTU周りである。玄箱PROはデフォルト状態でMTUが1,518Bytesで固定されており、これがボトルネックになっている。そこで、これをもう少し大きくしてみたい。
玄箱Proのデフォルトでは、ネットワーク周りの設定は /etc/networking.sh で行なっている。名前の通りのシェルスクリプトであるが、実はこの中に、既にMTUの設定が含まれている。start()の中に該当部分があり、リスト1のようになっている。JumboFrameに関しては、4,102/7,422/9,694Bytesの3種類をサポートしており、これ以外のFrameSizeだと1,518Bytesになるという仕組みだ。
ここでパラメータとして渡される$mtuは、/etc/netinfoの中で設定される。networking.shの先頭で
if [ -f /etc/netinfo ]; then . /etc/netinfo fi という形で設定が取り込まれる仕組みだ。ただその/etc/netinfoの中身はデフォルトで
my_ipaddress=dhcp my_subnetmask= my_dgw=
しか設定されておらず、mtuに関しては未設定である。そこで、たとえば
my_ipaddress=dhcp my_subnetmask= my_dgw= mtu=4102
という具合にmtuの設定を追加することで、JumboFrameへの対応ができることになる。実際にやってみると、これだけでMTUが変更できた(写真1、2)。
ではこれで性能が上がるか? というのが次の問題である。第1回と同じ環境で、今度はJumboFrameの設定を行なって、転送速度を比較してみた。ただ問題は、「どの程度のサイズとするか」である。今回比較に使ったASUSTeK M2N32-SLIの場合、オンボードで2ポートのGigabit Ethernetを搭載している。今回もこれを利用したのだが、デバイスのプロパティを見てみると(写真3)、MTUには1,500/2,500/4,500/9,000Bytesの4種類のみしか設定できない。玄箱PROの1,500/4,102/7,422/9,694Bytesと微妙にマッチしていないのが気になるところ。とりあえず近めの値として
玄箱PRO | M2N32-SLI |
1,518 | 1,500 |
4,102 | 4,500 |
9,694 | 9,000 |
の3つのパターンを試してみた。結果は表1から表3に示す通りで、非常に「微妙」な感じを受ける。MTU=4,102Bytesでは性能向上の兆しが見えているというのに、MTU=9,694Bytesではむしろ性能が下がっているからで、パケットサイズのミスマッチが起きて再送が発生し、これに伴い性能が低下しているという感じを受ける。特にこれを感じるのは表3のファイル転送である。ローカル→玄箱PROより玄箱PRO→ローカルの転送が一般に高速なはずなのに、この結果のみ玄箱PRO→ローカルで性能ががくんと下がっている。状況的には、玄箱が9.6KBytesのパケットを送り出すものの、これをNVIDIAのGigabit Ethernetが受け取れず、再送がかかっているというあたりがありそうなシナリオである。
表1 |
FDBench 1.01 |
総合スコア |
転送速度詳細 |
コピー回数詳細 |
転送速度 |
コピー回数 |
Read |
Write |
Random Read |
Random Write |
2K |
32K |
256K |
Variable |
(KB/sec) |
(回/分) |
(KB/sec) |
(回/分) |
MTU=1518 |
12180 |
8420 |
16113 |
8984 |
14770 |
8854 |
17112 |
12144 |
3428 |
998 |
MTU=4102 |
17992 |
9208 |
26959 |
11604 |
22910 |
10496 |
17490 |
13428 |
4590 |
1324 |
MTU=9694 |
12933 |
8450 |
15730 |
11572 |
13992 |
10440 |
16158 |
12564 |
3970 |
1108 |
表2 |
SiSoftware Sandra XI SP1a |
MTU=1518 |
MTU=4102 |
MTU=9694 |
ドライブ インデックス |
(MB/s) |
12 |
18 |
13 |
アクセスタイムの平均 |
(ms) |
11 |
11 |
9 |
バッファの読み込み |
(MB/s) |
16 |
25 |
15 |
順次読み込み |
(MB/s) |
13 |
20 |
13 |
ランダム読み込み |
(MB/s) |
12 |
17 |
12 |
バッファの書き込み |
(MB/s) |
12 |
17 |
18 |
順次書き込み |
(MB/s) |
10 |
14 |
14 |
ランダム書き込み |
(MB/s) |
11 |
14 |
15 |
アクセスタイムの平均 |
(ms) |
11 |
11 |
9 |
表3
|
ファイル転送 |
所要時間(秒) |
転送速度(MB/s) |
MTU=1518 |
ローカル→玄箱PRO |
190.7 |
12.4 |
玄箱PRO→ローカル |
178.4 |
13.3 |
MTU=4102 |
ローカル→玄箱PRO |
146.3 |
16.2 |
玄箱PRO→ローカル |
122.5 |
19.3 |
MTU=9694 |
ローカル→玄箱PRO |
140.9 |
16.8 |
玄箱PRO→ローカル |
183.1 |
12.9 |
|
|
|
写真1:MTU=4,084Bytesの場合。eth0の3行目で"MTU:4084"となっているのがわかる |
写真2:こちらは9,676Bytes |
写真3:NVIDIAのチップセット内蔵Gigabit Ethernetの場合、MTUとして選択できるのはこの4種類 |
では、NVIDIA以外のGigabit Ethernetカードならどうか? ということで、玄人志向のGBE-PCIe(写真4)と、IntelのPRO/1000 PT Adapter Card(写真5)の2枚を使って、やはりMTU=9694とした場合にどうなるかを次に確認してみた。
各々のドライバを入れてみると、やはりMTUの値はきっちりは一致しない(写真6、7)。この状態でテストしてみた結果が表4~6である。なぜか知らないが、玄人志向のGBE-PCIeを使った時だけ、異様に性能が良い事がわかる。あるいは同じMarvellのGigabit Ethernet同士だからということかもしれないが、そういう話で済ましてしまうわけにもいかない。
|
FDBench 1.01 |
総合スコア |
転送速度詳細 |
コピー回数詳細 |
転送速度 |
コピー回数 |
Read |
Write |
Random Read |
Random Write |
2K |
32K |
256K |
Variable |
(KB/sec) |
(回/分) |
(KB/sec) |
(回/分) |
NVIDIA |
12933 |
8450 |
15730 |
11572 |
13992 |
10440 |
16158 |
12564 |
3970 |
1108 |
Marvell |
18306 |
8119 |
29696 |
10346 |
23235 |
9948 |
14436 |
12594 |
4174 |
1274 |
Intel |
12361 |
8300 |
14680 |
10862 |
13551 |
10353 |
16110 |
12402 |
3626 |
1064 |
表5 |
SiSoftware Sandra XI SP1a |
NVIDIA |
Marvell |
Intel |
ドライブ インデックス |
(MB/s) |
13 |
17 |
12 |
アクセスタイムの平均 |
(ms) |
9 |
17 |
15 |
バッファの読み込み |
(MB/s) |
15 |
27 |
14 |
順次読み込み |
(MB/s) |
13 |
20 |
12 |
ランダム読み込み |
(MB/s) |
12 |
15 |
10 |
バッファの書き込み |
(MB/s) |
18 |
15 |
16 |
順次書き込み |
(MB/s) |
14 |
12 |
13 |
ランダム書き込み |
(MB/s) |
15 |
13 |
14 |
アクセスタイムの平均 |
(ms) |
9 |
17 |
15 |
表6 |
ファイル転送 |
所要時間(秒) |
転送速度(MB/s) |
NVIDIA |
ローカル→玄箱PRO |
140.9 |
16.8 |
玄箱PRO→ローカル |
183.1 |
12.9 |
Marvell |
ローカル→玄箱PRO |
158.6 |
14.9 |
玄箱PRO→ローカル |
117.3 |
20.2 |
Intel |
ローカル→玄箱PRO |
144.8 |
16.3 |
玄箱PRO→ローカル |
192.6 |
12.3 |
そこでもうちょっといじってみる事にした。ひょっとして玄箱側のMTUの値が大きすぎるのが原因か、と思ったからだ。変更は簡単で、コマンドラインから
/sbin/ifconfig eth0 mtu XXXX multicast
と入力するだけだ「と思った」。XXXXに変更後のMTUの値を入れる形になる。
さて、これをやるとどうなるか? であるが、なかなか興味深い事になった。どうも一度立ち上がった後は、MTUの変更が無効とされてしまうらしく、何をやってもMTUが9004Bytesに固定される(写真8)。この部分のソースを探してみると、linux-2.6.12_lsp.1.10.3.src.tar.gzに含まれるSources\linux-2.6.12_lsp.4.10.3\arch\arm\mach-mv88fxx81\LSP\egiga\mv_e_main.cの中のegiga_change_mtu()のようだ。ソースを追いかけると、元はMarvellから提供されたものに玄人志向で多少手を入れたという雰囲気だが、このあたりはオリジナルのままのようだ。で、egiga_change_mtu()から呼ばれるegiga_change_mtu_internals()の中で、現在のMTUと異なる値が設定されると拒否するようで、なので一度MTUを変更すると後からコマンドラインで変更することは事実上不可能となる。
そこでnetworking.shを直接編集して、MTUを9,000Bytesにしてみた。/etc/netinfoの中からMTUの記述を落とした上で、リスト1で
else
mtu=1500
fi
とある部分を
else
mtu=9000
fi
に書き換えてリブートというちょっと乱暴なやりかたである。この状態で、先ほど同様に転送速度を測定したのが表7~9である。NVIDIAは概ね変化なしであるが、Marvellではがくんと性能が下がり、代わりにIntelでの転送速度が先のMarvell並にあがっているのがわかる。やはりJumboFrameでは、通信する相手とのMTUサイズのマッチングが重要という事であろう。とりあえず玄箱PROのデフォルト状態でJumboFrameを使っても、MarvellのGigabit Ethernetと通信する時以外はあまり効果を期待できなさそうだ。もっとも調整は、networking.shあたりに強制的に書き込んで再起動をすれば簡単に行なえるから、自分の環境に合わせて微調整するというのが正しい使い方なのであろう。
表7 |
FDBench 1.01 |
総合スコア |
転送速度詳細 |
コピー回数詳細 |
転送速度 |
コピー回数 |
Read |
Write |
Random Read |
Random Write |
2K |
32K |
256K |
Variable |
(KB/sec) |
(回/分) |
(KB/sec) |
(回/分) |
NVIDIA |
12419 |
7090 |
15930 |
9958 |
14411 |
9376 |
13194 |
10614 |
3524 |
1028 |
Marvell |
13062 |
8285 |
15904 |
11254 |
14509 |
10581 |
16398 |
11682 |
3910 |
1152 |
Intel |
19084 |
8932 |
29917 |
10899 |
25236 |
10283 |
16578 |
13324 |
4474 |
1354 |
|
SiSoftware Sandra XI SP1a |
NVIDIA |
Marvell |
Intel |
ドライブ インデックス |
(MB/s) |
13 |
12 |
17 |
アクセスタイムの平均 |
(ms) |
10 |
16 |
15 |
バッファの読み込み |
(MB/s) |
16 |
15 |
28 |
順次読み込み |
(MB/s) |
13 |
13 |
20 |
ランダム読み込み |
(MB/s) |
12 |
11 |
15 |
バッファの書き込み |
(MB/s) |
17 |
14 |
15 |
順次書き込み |
(MB/s) |
14 |
12 |
13 |
ランダム書き込み |
(MB/s) |
15 |
12 |
13 |
アクセスタイムの平均 |
(ms) |
10 |
16 |
15 |
表9 |
ファイル転送 |
所要時間(秒) |
転送速度(MB/s) |
NVIDIA |
ローカル→玄箱PRO |
140.9 |
16.8 |
玄箱PRO→ローカル |
180.6 |
13.1 |
Marvell |
ローカル→玄箱PRO |
171.0 |
13.8 |
玄箱PRO→ローカル |
182.0 |
13.0 |
Intel |
ローカル→玄箱PRO |
145.7 |
16.3 |
玄箱PRO→ローカル |
110.8 |
21.4 |
余談ながら、/etc/netinfoをいじれば固定IPアドレスを設定することも可能だし、/etc/host.infoを編集するとホスト名も変更できる(写真9)。この例の場合
/etc/netinfo: my_ipaddress=192.168.2.10 my_subnetmask=255.255.255.0 my_dgw=192.168.2.1
/etc/host.info: hostname=KUROBAKO-PRO
と書き換えるだけである。複数台の玄箱PROを使う場合、ここを個別に変更してやれば済む。ちなみにワークグループ名の方は、第1回で説明したSWATの画面から変更が可能である。
|
|
|
写真4:Marvellの88E8053を搭載したPCI Expressカード。今回のために購入したわけでなく、安いPCI ExpressのGigabit Ethernetカードを探していて、たまたま見つけてストックしていたもの。Low Profileカードとしても利用可能 |
写真5:これはバルク品を購入。どこで買ったか既に覚えてないが、確か1万円はしなかったと思う。搭載されるIntel 82572GIは本来Gigabit Ethernetを2ポートだせるが、これは1ポートのみを生かしてあり、その分安価 |
写真6:玄人志向のGBE-PCIe(Marvell Yukon)のプロパティ。JumboFrameは4088/9014Bytesしか設定できない |
|
|
|
写真7:Intel PRO/1000 PTのプロパティ。こちらもまた同じく |
写真8:"Ilegal"という文字そのものがIllegal。ただこれは元のMarvellのソースが既にこうなっているっぽい |
写真9:IPアドレスを192.168.2.10、ホスト名をKUROBAKO-PROに変更した例 |
リスト1:
***** ここから *****
##
## change mtu (frame-size 1518,4100,7418)
##
if [ "$mtu" = "4102" ] ; then
mtu=4084
elif [ "$mtu" = "7422" ] ; then
mtu=7404
elif [ "$mtu" = "9694" ] ; then
mtu=9676
else
mtu=1500
fi
/sbin/ifconfig $ENETNAME mtu $mtu multicast
if [ $? -ne 0 ]; then
echo "mtu fail"
/sbin/ifconfig $ENETNAME mtu 1500 multicast
fi
***** ここまで *****
●PCI Expressポートを使ってみる
玄箱PROのフロントパネルにはPCI Express x1スロットがあるという話は既にレポートした通りだ。実際製品仕様書の最後(Appendix D:動作確認済みPCI Expressカード)には、玄人志向のGBE-PCIeがラインナップされている。ただ、動作確認済≠動作環境が設定済、という話であり、このあたりをちょっといじってみた。
装着は簡単で、玄箱PROのフロントパネルにPCI Expressスロットが配されており、ここに直接カードを取り付ける形になる。ただしブラケットはサブパネルと干渉するので取り外す必要があり、また玄箱PROのフレームとの干渉を避けるためには、カード長はおよそ14cm以内でないといけない。どのみちフロントパネルは利用できないからカードの高さには制限は無いが、カードブラケットが利用できないから余り背が高いカードを取り付けるのは難しいだろう(写真10)。この状態でブートしても、実は何も起きない。もっともdmesgを見てみると
Marvell Gigabit Ethernet Driver 'egiga':
o Ethernet descriptors in DRAM
o DRAM SW cache-coherency
o Checksum offload enabled
o Loading network interface ** egiga_init_module (10)
'eth0'
sk98lin: Network Device Driver v8.34.1.3
(C)Copyright 1999-2006 Marvell(R).
eth1: Marvell Yukon 88E8053 Gigabit Ethernet Controller
PrefPort:A RlmtMode:Check Link State
といった記述が残っており、デバイスが認識されてドライバがロードされているのは間違い無いが、ifconfigでもeth1が見えておらず、当然利用できない。そこでコンソールから
/sbin/ifconfig eth1 up
をかけると
eth1: network connection up using port A
speed: 1000
autonegotiation:yes
duplex mode: full
flowctrl: symmetric
role: slave
irq moderation: disabled
tcp offload: enabled
scatter-gather: enabled
tx-checksum: enabled
rx-checksum: enabled
rx-polling: enabled
というメッセージが出現し、eth1が利用できるようになった。もっとも、これをやってもまだIPアドレスが振られるわけではない。ではDHCPの設定を簡単に行なえるかと思い
export ENETNAME=eth1
/etc/init.d/networking.sh
を実施してみたが、networking.shの中を見てみるとわかる通り、一見複数のEthernetに対応しているように見えながら、実はeth0しかDHCPの対象として考えておらず、結果としてデフォルトのままではDHCPでアドレスを取れない。結局簡単に試すために
/sbin/ifconfig eth1 up
/sbin/ifconfig eth1 192.168.1.200 netmask 255.255.255.0
という記述をnetworking.shの中のstart()の最後に付け加える形で解決した。これを行なう事で、玄箱PROがDual LAN対応NASに進化したというわけだ(写真11)。こちらもDHCPクライアントにしたい、といった場合はnetworking.shの中(特に/sbin/dhcpcdを呼び出すあたり)の改造が必要になるだろう。
|
|
写真10:GBE-PCIeを取り付け中の図。玄箱PROを立てて運用すると、コネクタが底面に開く位置となり、すこぶる使いにくい。やはりこのように水平に置くのが無難だろう。ただ、一時的なテストはともかく長期運用にはもう少し考えないと |
写真11:別系統のLAN(192.168.1.0/255)からアクセスしてみた図 |
●2nd シリアルATAポートを使ってみる
やはりフロントパネルに配された2nd シリアルATAコネクタ。これを使って2つ目のHDDを管理できるかにトライしてみた(写真12)。ドライブはMaxtorのMaxLineIII シリアルATA 250GBを取り付けてみた。さて、この状態で玄箱PROをブートしても、MaxLineはマウントされない。そもそもフォーマットも不明(昔、Windows上でNTFSフォーマットしてそのまま放置していた)なので、まずは裏面のリセットスイッチで強制フォーマット……と思ったのだが、うまく動いてくれない。どうも内蔵HDDが装着された状態だと、正しく認識してくれないようだ。そこで、内蔵HDDを外し、2nd シリアルATAコネクタにMaxLineIIIのみを接続した状態でリブートしなおし、あらためてリセットスイッチを押すと、今度はちゃんと認識され、フォーマット後に自動マウント(写真13)。共有ディレクトリとして公開された(写真14)。
さて、ではBarracuda 7200.10を戻すとどうなるか? というのが次の課題。dmesgを見ると
scsi0 : Marvell SCSI to シリアルATA adapter
scsi1 : Marvell SCSI to シリアルATA adapter
Vendor: Seagate Model: ST3320620AS Rev: 3.AA
Type: Direct-Access ANSI SCSI revision: 03
Vendor: Maxtor Model: 7B250S0 Rev: BANC
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
SCSI device sda: drive cache: write back
sda: sda1
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB)
SCSI device sdb: drive cache: write back
sdb: sdb1
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0
というメッセージが出てきており、MaxLineIIIが/dev/sdb1として認識された事がわかる。さて、これをマウントできるか? という話だが、/etc/init.d/mount_share.sh を見ると、mount()の中で
#Try to mount as xfs , if that would fail, next try ty mount as ext3.
if [ -e /sys/block/sda/dev ] ; then
MountShare ${DISK1_DEV} ${DISK1_MPT}
[ $? -ne 0 ] && MountShare ${DISK1_DEV} ${DISK1_MPT} ext3
fi
if [ -e /sys/block/sdb/dev ] ; then
MountShare ${DISK2_DEV} ${DISK2_MPT}
[ $? -ne 0 ] && MountShare ${DISK2_DEV} ${DISK2_MPT} ext3
fi
MountShare ${MTD_SHARE_DEV} ${MTD_MPT} jffs2
となっており、デフォルトで/dev/sdb1のマウントに対応していることがわかる。試しにこの状態でリブートしてみると、ちゃんと/dev/sdb1が/mnt/disk2にマウントされた(写真15)。こうなると、後は簡単である。SWAT画面に移り、新規のshareポイントを作成(写真16)。パラメータを設定してから“Commit Changes”を押す(写真17)と、新しい共有ディレクトリが出現し(写真18)、正しくMaxLine IIIをマウントできた(写真19)。
|
|
|
写真12:単にシリアルATAコネクタを挿すだけ。ただ、2台目のHDDの電源端子は用意されないので、これは自分で何とかする必要がある。勿論サブパネルの基盤上から無理やり引っ張る事も可能だが、そもそも玄箱PROの電源供給能力がそこまであるか、ちょっと疑わしい感じだ。コネクタがちょっと固めなので注意 |
写真13:容量が250GBなので、これは外部に接続されたMaxLineIIIであることがわかる。2nd シリアルATAなのにもかかわらずデバイス名が/dev/sda1になっているところが、厄介 |
写真14:何もしなくてもこの通り、“share”で公開される |
|
|
|
写真15:/dev/sdb1が出現していることがわかる。なぜかリブート1回目にはこれが見えなかったのだが、再度リブートしたら以後はちゃんと出現するように |
写真16:SWATの呼び出し方は第1回参照。ここで上の“SHARES”ボタンを押すとこの画面になる。新規共有名は“share2”にした |
写真17:写真15で“Create Share”を押すとこの画面に。“path”に“/mnt/disk2”を、“read only”に“No”を、“guest ok”に“Yes”を設定しただけ。ここで“Commit Changes”ボタンを押すとただちに反映される |
|
|
写真18:KUROBOX-PROの下に“share2”が出現 |
写真19:Hドライブにマウントしてプロパティを表示してみた |
●ということで
とりあえずNASとしてちょこちょこいじってみたが、工夫次第ではまだまだ改変できそうだ。今回はOSを入れ替えたりHDDブートしたりといったところまでは手を出して無いが、それらにチャレンジしている人もネット上では散見されるから、適当に検索すればかなり色々ヒットするはずで、これらを参考に「あくまでも自己責任」でチャレンジしていただきたいところ。ちなみにシェルスクリプト類を眺めた感じでは、ほかにUSB HDDの接続も(こっそり)サポートしているようなので、これらを使うのも面白いだろう。
玄人志向のGBE-PCIeを挿して、ついでに外付けシリアルATABOXも繋げてDual LAN/Dual HDDのNASにするのも面白いだろうし、ついでにルータなんぞをさせるのも悪くないかもしれない。ただ、ルータとして使うためのアクセラレータ系がMarvellの88F5182には入っていないっぽいので、ルーティング性能はあまり良くないだろう。Sandra XIのNetwork Bandwidthテストで条件を変えて試してみた結果では、概ね40Mbpsあたりが上限であった。かつて、40MHzのARM 9を搭載したブロードバンドルータが概ね5~6Mbps程度のルーティング性能だったことを考えれば、400MHzで40Mbpsというのは納得できる数字だ。とは言え、こうした使い方は実はあまりお勧めできない。
そもそもARM 9自体が1.1MIPS/MHz程度の性能だから、400MHzでも440MIPS前後で、CPUの絶対性能はそれほど高速ではない。にもかかわらずNASとして性能がそこそこ出るのは、内部でCPUコアとGigabit EthernetやシリアルATAポート、メモリコントローラを高速なバスで接続してDMA転送をがんがんかけるからスループットがあがるという話で、CPUにあれこれやらせてしまうと性能が急に落ちる事になる。このあたりを理解した上で、あれこれHackしてみるには良い教材だろうと思う。少なくとも以前の玄箱とか玄箱/HGよりは、はるかにいじりやすくなっている事は間違いない。
もう時期的には春休みのお楽しみどころではない(とっくに終わってしまった!)が、GWシーズン狙いということでどうだろう? 一時期はかなり供給が逼迫していたようだが、最近また改善されたようで、以前よりは入手性が良くなっているようだ。敷居は高いが、それを楽しみたい人にお勧めする。
□玄人志向のホームページ
http://kuroutoshikou.com/
□製品情報
http://kuroutoshikou.com/modules/display/?iid=966
□関連記事
【4月5日】【槻ノ木】玄人志向「玄箱PRO」を使う【改造編1】
http://pc.watch.impress.co.jp/docs/2007/0405/pclabo40.htm
【3月27日】【槻ノ木】玄人志向「玄箱PRO」を使う【NAS編】
http://pc.watch.impress.co.jp/docs/2007/0327/pclabo39.htm
【2月16日】玄人志向、Linuxサーバー自作キット「KURO-BOX/PRO」
http://pc.watch.impress.co.jp/docs/2007/0216/kuro.htm
□バックナンバー
(2007年4月12日)
[Reported by 槻ノ木隆]
PC Watch編集部
pc-watch-info@impress.co.jp
ご質問に対して、個別にご回答はいたしません
Copyright (c) 2007 Impress Watch Corporation, an Impress Group company. All rights reserved.
|