インテルはFTCと和解する。VIAとnVidiaは大きな勝利を収める。SemiAccurateのCharlie Demerjian氏記事パート1翻訳

semiaccurate.com Intel settles with the FTC, Via and Nvidia win big Part 1: PCI busses, fabbing, and hens with baseball bats by Charlie Demerjian August 4, 2010 より。

インテルはFTCと和解する。VIAとnVidiaは大きな勝利を収める。

パート1:PCIバス、fabbing、野球バットと一緒のめんどり

by Charlie Demerjian

2010年8月4日

Intelは語る、そして言葉はインテルのより強固でほとんど誰も気がつかないくらい微妙な力の意思表示をした。申し立てられた数多くの病的な和解は半導体の怪物にとって残酷であり、nVidiaとVIAの両方が大きな大きな勝者となる。

和解文章はFTCのページで見つけることができ、Intelに対するすべての避難のアウトラインを表す最高傑作で、それらの全てに取り組み、そして問題があったことに何も言及しないまま和解するということである。結局Intelはすべての技術文章を詮索者から遠ざけ、手錠をかけ、目隠しをして、それらの上を母面取りが泣きながら横切り、苦労して終了させた。野球バットと大量のカフェイン入りの飲み物と共に。

その罰則が厳しくなろうとしたとき、Intelはダラダラと続く議論を行ない、公開裁判事件という選択肢よりもより良い選択をした。Intelは何の悪事も働かず、冒涜的な手榴弾を投げ込む怠惰な弁護士のために開かれた扉から去ることを認められた。誰もがIntelが行なった行為のために労力を咲くべきであろう。Intelは賢い方法で解決を図り、それは明確に正しい行為と呼べる。

それで、罰則とIntelにかけられた手錠についていくつか細かく見ていこう。明白に書かれていることに加えて、私たちは若い文章のいくつかのバックグラウンドについて詳細に調査しようと試みる。それのほとんどがあれこれと最近のIntelの病的な振る舞いについてのいくつかの疑惑について直接示している。

今回の告訴のこの文章について喜びや悲しみなどIntelやnVidia、VIAや他の様々な人々の意見を取り上げてはいない。長年当事者や製品、今回の若い文章に関係する産業界みてきたことを元にした単なる著者の意見である。

■PCIバス

最初の興味深いポイントはPDFの9ページ第II章で、それはPCI Expressバスについて取り扱っている。これは少なくとも今後6年間についてすべての「メインストリームマイクロプロセッサプラットフォーム」にPCI Expressバスを含めることをIntelに要求している。Intelはそれを使うPCI Expressのバージョンのことをつつくだろうが、「様々な関連したGPUの実行や故意に性能に制限をする」だろうことについて何の実効性もない。

これはIntelにとって問題である。なぜなら興味深いx86アーキテクチャのSoC(Sillicon On Chip)群から、それらを防ぐことは難しいからである。SoCの全体のポイントは、あなたが何らかの仕事をする際に必要となるいかなる追加カードを必要とせず、それらはすべて一つのチップの上に載っていることである。これは驚くほど効率的かつコストに影響するが、今IntelはPCI Expressバスと付属ピンを含める必要があり、参照設計の沿うことが適当と思われる。デスクトップPC向けチップのためにこれはほとんど関係ないが、悪いことにAtom CPU側にとって傷ができることになる。FTCのAtomを含むメインストリーム向けマイクロプロセッサープラットフォームの定義条項にはそれらの製品ラインを傷つけるだろう。

そして再び、トラックで通り抜けるのに十分な二つの大きな穴があることがわかる。最初の穴は第II章のA項目、それはこう書かれている…「標準PCIバス」と。そして第II章B項目には「標準PCI Expressバス」と。PCI – Expressではない – は標準PCIバスである。もしIntelがnVidiaにまがい物をつかませるなら、Intelは彼らのすべてのプラットフォームにPCIバス規格バージョン1.0のピン配列を置いておくだろう。そしてnVidiaは欠落したバス帯域で首を閉められる。これは法的な文章として通じるだろう。

更新:幾人かの読者が書き込んでいるところでは、HHセクションではすべてのPCI Expressベースの規格の意味として「標準PCIバス」は定義されてることによってカバーされるとのこと。

2番目に、Intelはまがい物をつかませる必要はなく、彼らはただAtomの上にゴミのような通常の半分の帯域のPCI Express2.0リンクを提供し続けるだけである。これは現代的なGPUに古いアナログのタバコ販売機のようなマシンを動作させるのに十分なバス帯域しか提供しない。もしIntelが自分たちのプラットフォームにGPUを必要としないなら、法的文章に順守するのは容易であり、nVidiaにXXXするまでである。それを見ることは楽しいと思わないか?

噂ではIntelはnVidiaのGPUを検出し、それらの性能を縛り付けるチップセットに切り替えさせているという。GPU全てにその行為をさせることはあまりにも露骨すぎるが、性能低下は本の少しだけ水掛け論を呼び起こすだけである。これらは壊れたPCI Expressスペックで変えられるが、大量の専用機器、技術者養成と時間を費やすこと無しに提供することは基本的に不可能である。性能低下はnVidiaの泣き言であり、単純に(かつての)GPUの巨人の単なる技術力を悪さであると思われることがより妥当である。その他は今は議論の余地がある。

■ライセンスと生産について

誰が何をどこで作ることができるのかについての全ての事柄は第III章で適切に対応されている。Intelは長い年月の間、サードパーティに対して脅迫し、それらの行為に対しての疑問に対し単に答えないというビジネスのやり方に疑いがかけられてきた。
Intelは曖昧な脅迫を数多く行い、他の裁判所での同意したことについて単に語らなかった。

第III章のA項目では興味深いがつい最近までほとんど明らかにされなかったAMDとIntelのライセンス条項についてである。それは多かれ少なかれ誰かがAMDの製造工場であると言ったり、ViaもしくはnVidiaのクロスライセンス条項は条項によって特許と製品をカバーするということを話すことができるというように。舞台の背後で演じられてきたゲームは通常のビジネスの流れのように必要になる時同様にそれらの会社に話すことを許可していないようにも見える。

第III章のB項目で、より興味が楚々されることに、FTCは現在から2018年4月7日までトータルで15年間の間IntelにVIAのライセンス条項適用を延長させた。Viaは今様々な疑問が期限切れになるまで明確に販売することができ、オースティンの少年たちに大きな勝利を与えている。

第III章のC項目3でFTCは、IntelはViaがx86アーキテクチャのポーつを作ることができるかを尋ねた時必ず公開文章にする必要があると法制化した。これは「君たち全員笑顔でそこで首を立てにふってくれ」という項目であり、数々の要求に答えなかったいくつかの過去のゲームでIntelはそれは引き起こされ、質問者は法的な辺境にとばされてしまった。それは、いやかつては汚いゲームであったがなんでも言葉に技工を凝らして悪いと言う事無しに汚いゲームをすることが十分簡単になってしまった。

第III章は基本的に「あなたは良いところにいる。もし偶然うまく騙せたら恥じ入りなさい」という販売方針を引き寄せるIntelの手法を排除している。Intelがこれをすることについてではなく、それらについて尋ねるだけだが、わたしはいくつかのIntelの顧客達がIntelの社員達はそれをするだけであるということを個人的に聞いた事がある。全く異なる問題であるかどうか証明されるだろうが今はその必要はない。FTCは野球バットと一緒の母めんどりと認可したのであり、それは6個の空のRed Bull(清涼飲料水)の容器が見えている。

パート2ではは隠蔽されている販売、MCM(Multi Chip Module 最近のIntelのx86CPUで採用されているパッケージ技術)、アップルについて記述する。

—-

続きパート2は気が向いたから翻訳した。途中でxserverは落ちるはmozcはSegment Fault吐くは散々な目にあったw。

「leddownは英文記事を勝手に翻訳しただけであり、このブログ以外で宣伝行為は一切しておりません」一応ね。

IntelがFTC(連邦取引委員会)と和解。VIAとnVidiaに勝利をもたらす…?

semiaccurate.com Intel settles with the FTC, Via and Nvidia win big Part 1: PCI busses, fabbing, and hens with baseball bats by Charlie Demerjian August 4, 2010

マイコミジャーナル Intelが連邦取引委員会と和解、競争阻害と不公正取引をめぐる訴訟 より。

簡単に概要のみを。

  • FTCとIntelの間で和解が成立した。
  • それはPCIバスなどに制限をかけることが不当競争行為に当たるということらしい。ただしPCI Express2.0では無さそう。
  • IntelのAtomや各種CPUに接続するPCIバスやPCI Expressの性能に制限をつけることを禁ずるという。
  • その結果、ディスクリートGPUカードを主力としているnVidiaは何を逃れてビジネスを続けられるということ。
  • またx86関連のIntel/AMDが所有している各種ライセンスや特許をVIAは2018年まで利用可能。その結果NanoなどのCPUビジネスは存続可能になる。
  • Intel Compilerで、Intel以外のCPUの場合最適化を行わず意図的にプログラムが遅くなるようにすることを今後止めること。

IntelはSandybridgeというAMD FusionAPUにあたるSoCを発表しているが、nVidiaが直接のビジネス上の障害に成りうるので和解は大勝利ということか。またVIAも当分はx86ビジネスを続けられるということ。AMDのCPUの件については、Intelのコンパイラで自社製品ではないものに最適化する必要はないけど、意図的に遅くするのはどうかと。Charlie氏の記事の翻訳はこちらからどうぞ。

Ubutnu 10.04 Lucid Lynx にてWD20EARS&WD20EADSの9台RAID6の拡張完了に5日間費やす

Ubutnu 10.04 Lucid Lynx にてWD20EARS&WD20EADSの9台RAID6の拡張がようやく明日に完了する予定。やはり3ware 9500s-12をPCI 32bit 33MHz接続ではバス帯域が足りないので実測値110MB/secしかでないので5日間もかかる。

またカーネ ルを2.4.34-999(nightly Build)にアップした。Promise SuperTrak ex8350ドライバのstex不具合等があれば記載する予定。

Ubuntu 10.04 Lucid LynxでRAID6構築 更新2010/06/19

※注意:コマンドラインはあくまで参考です。環境によりパラメータが異なります。またエディタの関係上一部記号がコピー&ペーストできません。自己責任でおねがいします。

先日ネットショップで購入したWD20EARSが我が家に到着した。

5台購入。代理店はCFDの1年保証。ウェスタンデジタル日本語ページのエンドユーザ保証サービスのページから、保証の確認を行うと、5台とも全て「限定保証なし」とつれない回答。

そこでRMAの3年保証を有効にするために、CFDのWesternDigital RMA申請開始手続きページから台数分のRMA有効の申請を行う。ちょっと面倒な作業。10日前後で手続きが完了とのこと。

次にUbuntu 10.04マシンに3ware 9500S-12経由で購入したハードディスク5台を追加接続して起動。

9500S-12はSATA1.5Gbit/secなのだが、8/10シリアルで換算して1台あたり100MB/secも速度が出れば充分なのと、PCI33MHz32bitなので133MB/secが限界値であること、さらにdebianやfedoraなどのイメージ記録用なので問題なしと判断した。

Ubuntu起動後にpalimpsestディスク・ユーティリティで全てのハードディスクが認識していることを確認。

そのままRAID構築でも良いが念のためパーティションを設定する。

GPTパーティションの作成

GPTパーティションを利用するのでfdiskではなくpartedを利用する。

$sudo parted /dev/sdq

$mklabel gpt

パーティションテーブルにGPTを利用する。

$unit MiB

パーティション作成時の単位をMiB(1,024bytes * 1,024  = 1,048,576 bytes)にする。

これは、WD20EARSがAdvanced Format Technology(AFT)を利用したハードディスクだからである。内部のセクタは4KiB(4096bytes)だが、セクタエミュレーションにより512bytesセクタに見せかけている。WindowsXP以前のOSは512bytesセクタに決め打ちしているため互換性を保つためと、セクタサイズを大きくしてもECC(エラー訂正符号)のbit数は比例せず同じ記録密度でディスク容量が最大11%アップするため導入したらしい。またエミュレーションセクタの境界と内部セクタの境界にズレが生じると性能が劣化する(最大2回の読み書きが生じるため)ので、パーティション境界を8の倍数のセクタに合わせておく必要がある。

$ mkpart ext4 1 -1

先頭パーティションを1MiBから開始するようにパーティションを設定する。

$ set 1 raid on

作成したパーティションにLinux RAIDフラグを設定する。

$ quit

この作業を5台分行う。

RAID6の構築

$ sudo mdadm –create /dev/md0 –raid-device=5 –level=6 –metadata=1.0 –chunk=128 –layout=left-symmetric-6 –bitmap=internal  /dev/sd[pqrst]1

長いので分けて解説する。

$ sudo mdadm –create /dev/md0

新規にディスクアレイ(RAID)を作成する。デバイス名をmd0とする。

–raid-device=5

RAIDに利用するハードディスク(デバイス)の数を設定する。

–level=6

RAIDレベルの設定。RAID0(冗長性なし・ストライピング)、RAID1(ミラーリング)、RAID5(1台分の冗長性)、RAID6(2台分の冗 長性)となる。その他にもRAID1の3重ミラーリングやRAID1+0など用途に応じて設定。

–metadata=1.0

LinuxのRAIDは、起動時に自動認識してRAIDデバイスを利用可能な状態にする。その際のRAIDに関する情報(metadata)を記録するのだが、バージョンと記録する位置によりいくつか設定がある。

0.9:ハードディスクの最後にmetadataを記録する。なお古いバージョンのため、1RAIDボリュームあたり2TiBまでなど制限がある。

1.0 1.1 1.2:metadataのバージョンは全て1.0で、小数点以下によりハードディスクの最後・ハードディスクの先頭・ハードディスクの先頭から4KiBとなる。

–chunk=128

単位はKiB。RAIDボリュームから読み出す単位を設定する。標準は64KiB。RAID5・6は128KiBが適切らしい。

–layout=left-symmetric

RAIDボリュームを構成するハードディスクの先頭からデータを書込み、最後にパリティ情報を記録する。詳細は別途検索をお願い。

–bitmap=internal

RAIDボリューム単位で更新情報を記録する。標準はnone。リカバリ時にbitmapの内容を参照して再構築に必要な部分のみを構築するため、時間短縮につながる。

/dev/sd[pqrst]1

続けて構築するハードディスクデバイス名を列挙する。

コマンドは実行すると2~3秒程で終了するが、バックグラウンドジョブで稼働している。

進捗状況を表示するには下記のコマンドで可能。

$ watch -n 1 cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdt1[4] sds1[3] sdr1[2] sdq1[1] sdp1[0]
5860539648 blocks super 1.0 level 6, 128k chunk, algorithm 2 [5/5] [UUUUU]
[>………………..]  resync =  4.5% (89325056/1953513216) finish=1490.8min speed=20840K/sec
bitmap: 446/466 pages [1784KB], 2048KB chunk

unused devices: <none>

などと表示される。resync=4.5%が構築の進捗状況。RAID再構築が完了してmd0デバイスが利用可能になるまで24時間強である。

RAID構築完了後詳細表示を行う。

$ sudo mdadm –detail /dev/md0

/dev/md0:
Version : 01.00
Creation Time : Fri May  7 18:10:52 2010
Raid Level : raid6
Array Size : 5860539648 (5589.05 GiB 6001.19 GB)
Used Dev Size : 3907026432 (3726.03 GiB 4000.80 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Sat May  8 23:57:37 2010
State : active
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0

Chunk Size : 128K

Name : momoserver:0  (local to host momoserver)
UUID : f246dae2:6b221399:fea2f6a8:5e7dfdd2
Events : 20404

Number   Major   Minor   RaidDevice State
0       8      241        0      active sync   /dev/sdp1
1      65        1        1      active sync   /dev/sdq1
2      65       17        2      active sync   /dev/sdr1
3      65       33        3      active sync   /dev/sds1
4      65       49        4      active sync   /dev/sdt1

ここではChunk Size : 128Kを覚えておく。

LVM(Logical Volume Managementの設定

/dev/md0構築後直ぐにmkfs.ext4でも良いのだが、気分的にLVMを構築してからにする。

$ sudo vgcreate Array00 /dev/md0

PVとVGを同時に作成する。Array00はボリュームグループ名(VG)、/dev/md0以降は VGに参加させるデバイス(PV)を列挙する。

Volume group “Array00” successfully created

作 成すると上記のメッセージを表示する。

次にロジカルボリューム(LV)を作成する。これが実質的なパーティション名となる。

$ sudo vgdisplay -v Array00

作成したVGの詳細表示。

Using volume group(s) on command line
Finding volume group “Array00”
— Volume group —
VG Name               Array00
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No  1
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                0
Open LV               0
Max PV                0
Cur PV                1
Act PV                1
VG Size               5.46 TiB
PE Size               4.00 MiB
Total PE              1430795
Alloc PE / Size       0 / 0
Free  PE / Size       1430795 / 5.46 TiB
VG UUID               PGcd8f-w2nM-22he-GRPl-y6Wr-kgyP-Mw3N6P

— Physical volumes —
PV Name               /dev/md0
PV UUID               eAZgg9-1tAW-XY36-UmBc-LjGn-HXiG-aiIvZF
PV Status             allocatable
Total PE / Free PE    1430795 / 1430795

PEとは、Physical Extentの略で、LVMで扱う情報の最小単位と思えばいい。

デフォルトでは1PE=4MiBなので、Total PE 1430795×4MiB=5590GiBとなる。

ここで最後に論理ボリューム(Logical Volume)の作成を行う。

$ sudo lvcreate -l 100%VG -n lv00 Array00

最後のパラメータにLVに追加するVGを列挙する。

-l 100%VG

これはVGの容量の100%で作成するというパラメータ。

-n lv00

LV名の設定

Logical volume “lv00” created

これでLVMの設定は完了。

ext4でLVをフォーマット

$ sudo mkfs.ext4 /dev/Array00/lv00

ここでext4フォーマットを行う。

Invalid argument 100%VG
Error during parsing of command line.
mtama@momoserver:~$ sudo lvcreate -l 100%VG -n lv00 Array00
Logical volume “lv00” created
mtama@momoserver:~$ sudo mkfs.ext4 /dev/Array00/lv00
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=32 blocks, Stripe width=96 blocks
366288896 inodes, 1465134080 blocks
73256704 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
44713 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544

Writing inode tables:   399/44713

フォーマットしている間に/dev/md0を自動認識させるよう設定する。

$ sudo mdadm -Ds /dev/md0

ARRAY /dev/md0 level=raid6 num-devices=5 metadata=01.00 name=momoserver:0 UUID=f246dae2:6b221399:fea2f6a8:5e7dfdd2

$ sudo mdadm -Ds /dev/mdo >> /etc/mdadm/mdadm.conf

次に手作業でmdadm.confを編集する。

$ sudo vi /etc/mdadm/mdadm.conf

# definitions of existing MD arrays
ARRAY /dev/md0 name=server:0 metadata=01.00 UUID=XXXXXX auto=yes

下線部をmetadata=1.0に書き換える。

マウントして完了

フォーマットが終わると下記のメッセージが表示される。

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 20 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

マウントする。

$ sudo mount -t ext4 /dev/Array00/lv00 /mnt/disk/

次に自動マウントするためfstabを編集する。

$ sudo vi /etc/fstab

下記の行を追加する。

# RAID6 LVM2 Array00
/dev/Array00/lv00        /mnt/disk    ext4    rw,auto,noatime 0       2

最後の数字はfsckをどのタイミングで行うか。詳しくは検索すること。

これで完了。

作業時間は1時間弱、作業期間は4日程度であった。次回はディスクの増設を行う予定。

RAID構築後にRAIDユニットがマウントできない場合 2010年06月06日追加

何かの表紙でRAIDボードやSATAデバイスのドライバがエラーを起こした場合、ハードディスクは正常なのにArray StatusがFaildとなってアレイをマウントできなくなる場合がある。

その際に有効なコマンドをいくつかメモする。

$ sudo mdadm -QE –scan

ARRAY /dev/md/2 level=raid5 metadata=1.0 num-devices=3 UUID=5cbbccda:b3b74458:8f193a8e:d66021d8 name=server:2
ARRAY /dev/md/1 level=raid5 metadata=1.0 num-devices=4 UUID=0aeedf27:e5a4d11e:44d6b3de:5aa5e901 name=server:1
ARRAY /dev/md/0 level=raid6 metadata=1.0 num-devices=9 UUID=f246dae2:6b221399:fea2f6a8:5e7dfdd2 name=server:0

mdadm.confに間違ったUUIDを記載した場合に正常なUUID値をハードディスクのスーパーブロックから読み出すコマンド。

出力されたリストをmdadm.confに追加するだけで良い。

$ sudo mdadm -As /dev/md0

mdadm.confに記載されたmdデバイスを開始する。

$ sudo mdadm -E /dev/sdc1

ハードディスクのスーパーブロックからRAID情報を読み出す。古いRAIDアレイで利用していたハードディスクを再利用使用する際に、UUIDが古いままだと新しいRAIDアレイに追加できない。-QEコマンドと使うとUUIDを比較して正しいか判断ができる。