メインPC、CPUクーラー交換！（その２）

　前段の話は先行するエントリで。大まかに流れをまとめると、

• Intel Core i7-10700搭載のDell XPS 8940では、CPUパッケージ温度がすぐ100℃まで上がる。要はCPUクーラーの除熱性能が足らない。
• CPUパッケージ温度をを下げるために、ターボブースト時の最大CPU出力の設定を120Wから60Wまで下げた。連続・高負荷時のCPUパッケージ温度は85℃以下となったが、CPUのピーク性能は２割ほど下がった。
• CPUクーラー交換を検討して候補を絞り込んだが、「85℃でいいっしょ」と高をくくって暫く放置。連続・高負荷運転30時間など、長時間の85℃運転を10回程度繰り返した。
• Intelの技術文書を改めて丁寧に読むと、制限最高温度の一つであるケース温度はIntel Core i7-10700でも72℃前後であることが分かった。つまり「85℃運転はヤバい」。以前の検討に基づいて、CPUクーラーとしてID-COOLING SE-914-XTの導入を決心するに至った。ファン径92mmが決め手、120mmだともうミニタワーケースには収まらない。これが8/9の夜。

となる。 

　で、翌8/10は都内の病院への月一の通院日だったので、その帰りに秋葉原に寄った。「こんな時期になんだ」と言われそうだが、中途半端な田舎住まいには逃し難い機会だ。その規模故に密になりにくそうな大店舗を選び、ID-COOLING SE-914-XTとM3×20mmネジを購入して早々に帰宅した。

　元々付いているCPUクーラーはネジ４本を緩めるだけであっさり取り外せた。かつて動画で観た「AMD CPUのすっぽん」の光景が頭をちらついてやや恐る恐るの作業となったが、ネジを緩める過程でネジ部のバネの力だけでCPUとは分離した（私がPCを盛んに自作、改良していた時代は、CPUクーラー無し～リテールクーラーで十分なころ。つまりCPUクーラーをCPUから外すのは生まれて初めて）。グリスは乾いておらず、接触面全体に広がっていたため、CPUクーラーの性能は十分に発揮できていたと思われる。CPUクーラー自体は、少し昔風の言い方をすると「リテール品よりもヒートシンクが厚いトップフロー型」とでも言えようか。埃の付着はファンの最先端部に僅かにある程度で、ヒートシンク内も綺麗だった。

　SE-914-XTの取り付けについては特に述べないが、CPUクーラー固定用のステーとステーとマザーボード基盤との間に挟む樹脂製スペーサを固定するネジは、マザーボード基盤高さにあるネジ穴が全く見えない状態で、上から挿入して締めることになる。私の場合はネジの代わりにつまようじを使って仮組みし、つまようじを１本ずつ実際のネジに置き換えていく方法をとった。なお、CPUクーラーの交換はケースカバーを外しただけの状態で実施した。ただマザーボードのファン電源ピン周りは狭いので、既存のCPUクーラーを外した時点で新しいファンの電源ケーブルを接続しておくのが吉かと思う。

　あ、何故ステー固定が面倒臭いのか、そもそもどうして別途購入のネジなんかで固定するのかについては先行するエントリ（その１）を参照されたい。これは附属品ではSE-914-XTがXPS 8940に取り付けられないというXPS 8940の構造が原因だ。更に言えば、今回の取り付け方法ではマザーボードをケースに組み込んだ状態での作業が必須となる。ステーはマザーボードではなく、マザーボードを半ば貫通している「ケースの一部」に固定するからだ。

 　さてID-COOLING SE-914-XTの性能だが、まず冷却力は私の想定には十分ミートした。良くも悪くもミニタワーケースに入るコンパクトな空冷クーラーである。以下、具体的なCPUパッケージ温度が表れるが、これらは全てCinebench R23のマルチコアテスト（10分）の終盤に得られた値だ。

　まずはターボブースト時の最大出力を150Wに設定した場合のCinebench R23の結果だ。150WはSE-914-XTの最大対応TDPになる。

　ベンチマークの数値自体は「あ、ふ～ん。それっぽい数値出てるね」ぐらいでの受け取り方で良い。このベンチの過程で得られた大事な知見は、CPUパッケージ温度は83℃とケース温度を超えたが、コアクロックは全て最大値の4.6GHzが維持されたことだ。つまり、CPUの計算能力としてのパワーが100%引き出せている。逆に、ターボブースト時の最大出力を150W超とすることに意味は無いことになる。

　ターボブースト時の最大出力を出荷時設定の120Wとした場合はどうか。CPUパッケージ温度は72～74℃とケース温度付近、コアクロックは全て4.4GHzが維持された。コアクロックは最大値に及ばないものの、ケース温度の観点からはこの辺りがターボブースト時の最大出力設定の候補となる。が、さすがにファン音が大きい。ブーンという音が乗って、機械的な不具合発生の不安を感じる一歩手前ぐらいの感じの音だ。

　続いて95W。この出力ならコアクロックが4.0GHz以上とできることが予測され、日常的に使えると嬉しい設定点だ。従来の60W設定時に対してコアクロックが+20%以上となる。CPUパッケージ温度は68℃でケース温度未満、コアクロックは4.0～4.1GHzと狙い通りだ。ファン音にブーンといった音が無くなり、如何にも高速回転中といったサーといった音だけになる。音量は8畳向けエアコンの低風量時よりやや大きいぐらいだが、ノイズ多めなので耳障りで隣で寝るのは無理っぽい。

　60Wならファン音が認識できない静音状態で、アイドル時と変わらない。CPUパッケージ温度は63℃、コアクロックは3.5GHzで、旧CPUクーラーの84℃、3.3GHzとは本質的に違う。なお、アイドル時のCPUパッケージ温度は60℃台から40℃まで下がった。コアクロックの違いは自動制御されているコア電圧の違いを反映している。ファン音が聞こえ始めるは70W、「これは隣では眠れないかも」感が出始めるのが75Wだ。睡眠時も運転することを考えると70W、CPUパッケージ温度64℃、コアクロック3.7GHzでほぼ決まりだ。

　まとめると、連続・全力運転を前提したターボブースト時最大出力は、睡眠時70W、日中不在時は95Wぐらいが良さそうだ。冬場は部屋を温めておいてくれるだろう。

　SE-914-XTのファン回転数制御は、意地でもCPUパッケージ温度を70℃未満としたいかのようだ。ファン音が気になり始めるのが63～64℃、100W以下の広いCPU出力範囲でCPUパッケージ温度のブレの上限が68℃となる。これはIntel Coreのケース温度（ヒートスプレッダの許容温度）が72℃付近であることを考えると納得の設定だ。半面、CPUパッケージ温度が60℃前半の段階からファン回転数を上げ始めるので、静音運転に拘ると思っていたよりもCPU出力が上げにくくなっている。この辺りはこのサイズのケースに収まるコンパクトさとの兼ね合いというのが実態だろう。ただしケース温度制限を考えなくとも良い、という点は精神衛生上実に好ましい。また、CPUパッケージ温度が低くなれば電圧を上げやすくなるので、同じCPU出力でもコアクロックは僅かではあるが上がる。

　で、別のまとめ方。

　価格.comのレビューなど、他の人によるネット上の情報とも矛盾しないし、値（特にキーとなるCPUパッケージ温度68℃）の一致具合も高い。繰り返すけど、高回転時のファン音はノイズ混じりで、個人的にはやや不安感を煽るものだ。コンパクトさの代償だね。CPU出力70～80Wの範囲でCPUパッケージ温度の変化勾配が上がるが、その上昇はいったん68℃で止まる。つまり80～100Wの範囲内に、CPU出力に依存せずCPUパッケージ温度が68℃一定となる範囲がある。

　なおBIOS/UEFIが既に第11世代Coreに対応しているので、実用性を担保しつつ最低でも一世代はCPUアップグレードできる見通しが立っている。が、現時点ではコストパフォーマンスが悪いからやらないけどね。

　んん？高出力時のこの騒音は実はケースファンからかな？（続くかもしれん）

　雑談。

　今回のCPUクーラー交換の検討段階でCPUクーラーの性能比較や性能紹介動画を多数見た。が、CPU出力を「100%」としか紹介しないものが少なくなかったのが頭痛の種だった。私の観点だと、最高出力を20Wに設定すれば20W出力で100%だし、150Wに設定したら150W出力で100%だ。上のグラフの全ての点が「CPU出力100%におけるCPUパッケージ温度及びコアクロック」の測定結果になるのは明らかで、「100%」と言う表現は付加条件が無いと意味がない。

　3DCGレンダリング時（≒実際の使用時）の負荷は、ターボブースト時のCPU出力設定に使っているIntel Extreme Tuning Utility（Intel XTU）のストレステストの負荷よりも明らかに大きいようだ。CPU出力が同じでも、XTUストレステスト時の方が CPUパッケージ温度は低い。より具体的には、XTUストレステストではCPUパッケージ温度が上下するが、3DCGレンダリングでは上限値に貼りつく。

　ちょっと似た話で、DAWはCPUパワーを要求するため昔からCPU使用率表示が行われてきた。今でもそんな表示は残っているが、パワー要求（デマンド）に対して制限範囲内で計算能力が追従する昨今のCPUに対して意味あるんですかねぇ。

メインPC、CPUクーラー交換！（その１）

　とにかくCPUパッケージ温度が100℃近くまでしょっちゅう上がるので、メインPCのCPUをダウンクロックした話は以前にした。CPUはIntel Core i7-10700で、具体的には120Wだったターボブースト出力を60～70Wにまで下げた。それでも、CPUパッケージ温度は85℃付近まで上がる。

　あらためて断っておくが、私はオーバークロッカーの類ではない。趣味で3DCGをやっているだけだ。が、3DCGの世界のレンダリングという作業では、特に動画を作る場合は、PCを2～３日間全力運転させることなんてざらにある。だから「趣味の範囲で」という注釈の下（つまりまずは安く）、そのようなタスク「も」そこそここなせるPCが欲しい。できるだけCPUの能力を引き出しつつ、故障や不具合発生の可能性を下げた運用が可能で、睡眠を阻害しないレベルで静かなPCだ。じゃぁ何でDellなのか・・・いやいや、先代のメインPCだったDell XPS 8700は、グラフィックボードこそは交換したが上記の私の要求を満点で満たすものだったのだ。Alienwareを買収したあたりから製品の技術的傾向に変化が見られ始めた感じがする。まぁ今回のCPUクーラーの件のようにPC性能の足を引っ張る明確なアキレス腱があって、そこに約￥4000とちょっとした作業だけでPC性能が「そこそこ化ける」・・・って展開は試されてるみたいでまだ楽しめるレベルだし、Dellのハードウェア設計の基礎部分の手堅さみたいなものは感じる・・・感じない？フルタワーケース製品以外に拡張性はもはや求めちゃダメだけどね。

　さて、

　「CPU温度　適正」といったキーワードでググると「高負荷時でも70℃台、80℃越えはヤバい」といった辺りの情報が大勢だが、Intelのスロットリング（上限値制限制御）のロジックからはそういう印象を受けない。という訳で「85℃でもええやんけ」と思っていたのだが、Intelの公開されている技術資料を見て考えが変わった。これが8/9の夜の話。んで8/10にはCPUクーラーを交換しちゃった訳だが、最近のエントリの内容はこういう早い展開が多いな。

　従来よりIntel CPUの許容最大温度としてケース温度T_caseが用いられてきた。これはヒートスプレッダの最高許容温度であり、以前より熱暴走や破損を防ぐ上での基準となっていた。具体的に72℃付近であり、少なくとも第４世代以降のCoreではほぼ変わらない。一方、最近では、書類でかつてT_caseが書かれていた位置にはジャンクション温度T_junction_maxと呼ばれる温度が書かれることが増えた。これはコア内の接続部が破損しない（＝断線しない）温度で、具体的には100℃である。Intel Core i7-10700などでコア温度が100℃に達すると、クロック周波数を下げるなどして温度を下げる制御が為されるのはこのためだと思われる。

　ではCore i7-10700にとってケース温度T_caseは気にしなくても良いかと言えばさに非ず、ネット上に公開されているIntelの技術資料をきっちり読めば Core i7-10700でもケース温度T_caseが72℃程度であることははっきり書かれている。つまり、「85℃でもええやんけ」という考えは間違っている。技術屋気質を気取るなら、反省する間も惜しんで事態の本質的是正に動くべきってところだろう。

　ちなみに、ネット上には「昔はケース温度T_case、今はジャンクション温度T_junction_maxが制限」といった文章もあるが、書いた当人の肩書がどうだろうがIntelが発行・公開している技術文書の記述に基づけばこれは当然間違いである。こんなんに仕事出してるようなレベルお察しな会社、経営大丈夫か。まぁ、ターボブースト運転を連続24時間とか、普通の用途では有り得ない使用条件であることは認める。

　さて、メインPCはDell XPS 8940というちょっと困ったちゃんである。

　まず、CPUファンやケースファンの回転数を取得するインターフェースが無い。安さの秘密だ。つまりケースファン回転数やその制御ロジックはユーザーに対してマスクされていて、BIOS/UEFIやソフトウェアでそれらを確認したり変更することができない。

　次いで、ファンやヒートシンクの大きさを見る限りCPUクーラーはTDP65W級なのだが、ターボブースト時の最大出力のデフォルト値が120Wになっている。実際には色々なスロットリングの所為で100～110W動作が限界だが、それでもCPU温度は100℃を叩き続ける。このためターボブースト時の最大出力を下げて実質的にダウンクロックした訳だ。TDPが65Wだからとの主張は一見正当だが、ターボクロック動作時の性能でCPU製品の価値を位置付けている（＝価格が違う）ところも実態としてあるから、ターボブースト時を考慮しないスペック上のTDPは熱設計においては参考程度の意味しかない。

　更にミニタワー型の筐体は縦置き時の幅（厚み）が160mm程度しかない。これは簡易水冷どころかちょっと大きめの空冷ファンも入らない。定番どころの虎徹Mk.IIも入らない、というか背が高すぎてケースの蓋が閉じられないそうだ。まぁ、メーカーPCはそんなもんでしょ。

　あ、後ひとつ、CPUクーラーは、ケースから伸びてマザーボードを貫通する４本のM3メスネジ（ポリコレ的には不味い表現）付の筒と言うか棒と言うかにそれぞれM3オスネジ（ポリコレ的には不味い表現）で固定する。これは空冷ファン取り付けに良く使われるバックプレートに相当するが、逆に言えばCPUクーラーに添付されている専用バックプレートが取り付けられない。少なくとも４本の筒なり棒なりを切断、除去しなければ無理だ。このような構造も安さの秘密かもしれないが、マザーボードへの荷重負荷をほぼゼロとしつつネジ４本でCPUクーラーなりがきっちり固定できることを考えると割と「冴えたやり方感」はある。要は同じ構造、或いは同じように使える構造、及びそれらに対応したパーツが増えれば状況は変わる訳だ。

　とは言え、Dell XPS 8940のCPU高温の問題に対して私と同じような悩みを持った人が居ない筈も無い。ネットを徘徊すると、価格.comのレビュー内にそのものズバリの内容のものがあった（CPUはIntel Core i7-11700だが、マザーボードやケースは同じ）。製品はID-COOLING SE-914-XTというサイドフロー型の空冷クーラーで、メーカースペック上はTDP150W対応だ。ポイントは、M3×20mmネジを別途用意すれば、CPUクーラー添付のバックプレートを使わないどころか、PCを一切加工することなく取り付けられたという事実、実績だ。これを検討しない手はない。ID-COOLING SE-914-XT自体には特に音についてはネガティブな評価もあり、実際に使ってみて成程と思わなくも無いが、これは

「Dellユーザーなどに堕した報い」

かもしれんね。最近はちょっと部品が高いけど、使用目的が明確な場合には、構成品をきっちり選んだ自作PCに勝るツールはそうそう無いですわな。

続く！

Always look on the bright side of life

っつーか、「偶然による流れは大事にし、決して悪い方には行かないだろうと信じて進もう」「人や物との出会いも同様」というのが私の考え方で、経験則でもある。もちろん「単に流される」と言う訳ではなく、人事は尽くす。「適切に動いていればツキは回ってくる」「考えることをやめてはいけない」と言い換えても良い。「明るい面」の一つや二つぐらいは、自ら作ってやろうじゃないか。

　今回もそんな「明るい面」だと良いな、というのが本エントリのお話。出だしは良好だが、今後の展開や如何に。

　さて、我らが地方自治体は国からのワクチン供給が寂しいことなっていて、私の属する年齢層の接種開始時期は約１ヵ月延期された。４週間前の地元新聞の記事によれば、自治体への7、８月の国からのワクチン供給量は予定していた量の４割程度だという。結局予約開始は来週となったが、予約を受け付ける接種日は月末に届かない。これは月末を待たずにワクチンが枯渇するのを防ぐためと思われる。いやはや、まるで一時期の、或いはとある報道を信じれば９月の大〇民国である。また自治体の公式情報を信じれば、居住地から10km以内で現時点で予約を受け付けている病院は１つしかなく、相当がっつかないと接種１回目の予約ですら取れないと思われた。もちろん２回目の予約なんて取れる筈も無いと観念した。とは言え、がっついて良い思いをした記憶は全くない。これが昨夜の話。

　で、今朝、２回分のワクチン接種の予約が取れた。これは、県庁所在地の大規模接種に私の住む自治体の住民枠が来週から設けられたためだ。今朝もいつも通りに7時に起床し、8時には外出可能となっていた。ただし今日は病院への通院日で、自宅を出るのは10時だ。

　手持ち無沙汰で自治体のワクチン接種情報ページの内容を再確認していたところ、初めて上記の県庁所在地での大規模接種に関する記述に気づいた。ポイントは接種券があれば年齢制限が無いこと、つまり来週を待つことなく私でも予約可能な点だ。会場などをWeb上で確認し、接種券を手元におもむろに居住自治体のワクチン接種Web予約システムにアクセスしてみると予約可能だった。通院日など予約を入れられない日程は10月分まで既にメモにまとめてあったので、さっそくメモを見つつ条件を満たす最直近の日程を選択、予約を確定した。１回目は８月中旬、２回目は９月中旬だ。別の県に住む同年代の親戚が7月中旬に予約確定した接種日よりも早い。

　ただこの展開、ちょっとスムースに過ぎる。オチにして「ツキかも知れない」点は病院からの帰宅後、自治体のワクチン接種情報ページの内容を再び確認して明らかになった。

　「予約受付開始が今日の8時30分から」だったのだ。予約票の発行時刻は8時50分となっている。成程、平日接種なら未だ予約可能枠が多数あったのも当然だ。

　つまり、たまたま時間があったから自治体のワクチン接種情報ページにアクセスし、そこで大規模接種の件に始めて気づき、そうとは知らず予約開始直後のタイミングでワクチン接種Web予約システムにアクセスし、その流れで予約確定までいったことになる。ここまで来るとややオカルティックな感じすらするが、これも毎週の神社参りのご利益だろうか。明日はお参り日なので、一言お礼も言っておこうかと思う。お賽銭も２グレードは弾むので、今後も助力をお願いしよう。

　なお、病院から帰宅後に閲覧した自治体のワクチン接種情報ページは大幅更新されていた。内容は朝とは完全な別物となっており、９月からのワクチン接種業務の再立ち上げ、正常化をしっかりうかがわせるものとなっている。この点は自治体の名誉のためにも明記しておく。また上記の新聞報道によれば、７月初旬の段階で65歳以上の２回目接種の予約率が80%に達していたかその見通しが得られていたとのことで、接種スピードは決して悪くなかったようだ。

　因みに我らが自治体が政府からのワクチン供給減の対象となった理由は明確ではない（＝ソースが無い）が、可能性としてはVRSへの登録遅れ（備蓄量6週間以上と判定された）がタイミングから考えられよう。ワクチン接種業務の混乱の「理由」は国からのワクチン供給減だが、「原因」がそうではないことは疑いようがない。9～10月の集団接種などの予定は結構意欲的なものなので、上手く進むことを祈るばかりだ。既に下記の件があるからねぇ・・・

　今後、現在議論中のアストラゼネカワクチン導入で新たな混乱が生ずる可能性を個人的には危惧する。接種する側としてはワクチンの性能差、効果の差が気になるから、混乱が起きるとすれば感情的なもの（例えば、不公平感）をも交えた筋の悪いものとなる可能性が高いと見る。これには巻き込まれたくないという思いも、私がワクチン接予約の確定を急いだ理由の一つになっている。

　「ワクチンを接種するという選択の行使を散々封じられ続けた挙句にアストラゼネカしか選択できません」、では不公平感も出る。社会的要請から高リスク層へのワクチン接種が優先されてきたのは当然として、それがほぼ終わろうとしている今こそ全年齢層に選択の行使を認めるべきだ。またアストラゼネカが相対的に不人気であるとすれば、アストラゼネカならそう待たずに接種可、ファイザーやモデルナなら接種までに待つ必要がある、といった状況を成るべくして早々に確立し、ワクチン種も含めて個々人の選択に早く委ねるべきだ。繰り返しになるが、そうしないと世代間などに本当に不要な感情的軋轢を生む。機械的なアストラゼネカの導入は、色々とリスキーだと思わざるを得ない。声はでかいが頭は使わない層の口をふさぎ続けるにはちょっとした知恵があれば良いだけなのだが、現政権にはそれが全く感じられない。本当にリスキーだ。

八面玲瓏（はちめんれいろう）

　出身高校の校歌の歌詞にあった言葉だが、意味を完全に誤解していたことをついさっき知った。ま、そんな元岳南健児もここにいるからよっ、てな。

トクド

 　朝鮮語では「ドクト」との単語発音は有り得ないことに急に気づいて、独島のハングル表記を調べてみると「독도」だった。単独で発音される場合は「トクド」、「ドクト」も「トクト」も有り得ない。「トッド」とか「トックド」っぽいかもしれない。Googleさんに発音してもらおう。

　単語頭では音は濁らない、つまり１文字目の「도」部の発音は「ト（に近い音）」しかない。ところが単語中では「도」は濁る、つまり「ド（に近い音）」になる。ローマ字表記が「Dokdo」なので間違いない。「T」ではなく「D」を使うのは、単語内の位置によって濁ったり濁らなかったりするためだ。朝鮮語には日本語の感覚だと「T」に相当する音があと２種あり、これらは絶対濁らない（発音法の関係で濁らせることができない）。ローマ字表記が「Busan」でも、発音が「ブサン」ではなく「プサン」となるのも同じ理由だ。なお厳密には日本語と朝鮮語の濁音は発音法が違うので、あくまで各言語で用いる近い音での話であることは断っておく。

　日本人だと「トクト」と聞こえる人や、違うのは分かるけど「ド」か「ト」か確信を持って聞き分けられない人もいるだろうと思う。ちなみに中国の普通話（標準語）の濁音は朝鮮語のそれらと基本的に同じ、英語の濁音は日本語のそれらと基本的に同じ、サンスクリット語では中国で使われる濁音も英語で使われる濁音も別の音として使う・・・らしい。

　なんで今まで気づかなかったのかなぁ・・・

ライティングの肝は影

　PCを用いた3DCGI歴は何気に長い。最初のパッケージアプリを使い始めたのはCPUがIntel i286（16bit CPUだ）のころで、i386ネイティブレンダラー（要は32bit専用レイトレーシングレンダラー、使えるメモリが大きくなり、かつ高速）なんてものが後から別売りされたりするようなタイミングだった。モデリングは用意されたプリミティブ（球体などの基本的な三次元形状）を配置、変形、回転させるだけで、表面属性はプリミティブ単位でしか指定できなかった。大学で開発、無料配布されたMODEなんかがそうだ。

　加えてPC本体の表示可能色が4096色中16色（NEC系のデジタル16色）だったので、24bitカラー（当時言うところのトゥルーカラー）だったレンダリング結果をちゃんと見るには追加のハードウェアが必要だった。私の場合は、300×200ドットの24bit表示が可能なフレームバッファを拡張バスに追加していた、当時にして10万円也。

　プリミティブベースではモデリングの自由度の限界に直ぐ至るが、連続的かつ代数的に物体表面特定位置の傾斜が得られるため、代数的に厳密なレイトレーシング計算が可能だ。要は基本原理従った例外のほぼ無いアルゴリズムで、相対的に低い計算負荷と高精度を両立したレイトレーシングが可能となる。代表的な例外は物体の角部だろう。そのような位置では物体表面の勾配及び勾配の一次微分が定義できないから、特別扱いは必至だ。同じ理屈で光源設定の自由度も高く、厳密な点、線、面、スポットが利用可能だった。初期のポリゴンレンダラーの線、面光源が点光源の集合体であることがあったこととは対照的だ。

　やっと本題なのだが、その時点で3DCGIのライティングの肝は影のコントロールだとあっさり悟った。ここでの「肝」の意味は、ほぼ「リアリティの付与或いはリアリティの強化」と同義だ。「光あるところに影あり」とは良く言ったものだが、光源の種類の判別は光が当たっている部分よりその光の影のエッジ部を見た方が良く分かる。光が強く当たっている部分はそれっぽくても、影が「本来あるべき光源にふさわしくないもの」になっているとリアリティは一瞬で失われる。特にあるべき影が無い場合は、3DCGIで画を作ることに疑問すら感じる。早くて安く画ができるといった経済的な理由はもちろん分かった上での話である。

　影に関する考え方は当然モデリングにも反映される。レンダリング時に影を落とす必要のない構造物はモデリングせず、バンプマッピングなどで処理することになる。構造物をモデリングするか否かの判断基準は影が全てで、大小などは全く考慮しない。 

　さて、

つい先ほど、たまたまYouTubeで"OBSOLETE"を摘まみ観した。影は基本的に計算されていないし、銃器のフラッシュも点光源で処理している。厳密な点光源はこの世に存在しない点は軽んずべきではない。結果、光と影のリアリティが皆無に近い画作りになっている。個人的には魅力を感じない類のもので、むしろ手描き画で見せろと声を挙げそうになてしまう。3DCGIで、レイトレーシングは点光源を使った最小限のもの・・・安くて早いのだろうが、出来上がったものに何かが宿るということはなさそうだ。

　影が肝と信じる以上、逆の手に出る場合もある。特定の目的の下、他の表現に役割を果させることで影を最小限にする場合がそうだ。アニメ「超時空要塞マクロス」に登場するメカVF-1Aの3DCG動画をかれこれ10年程前にYouTubeに上げているが、これがそうだ。この動画はモデルのショーリール、つまりモデルの形状的な出来具合をアピールするためのものなので、画はモデル全体及び部品の形状や位置関係が分かり易いものであるべきだ。

　ここではラインレンダーを使ってモデルの輪郭や鋭角部を黒線で表示することで、影に頼らずモデル形状が把握できる画作りを目指した。ライティングは上からの白の平行光と白の環境光だけだ。前者は夏の真昼の太陽光をイメージしてもらえればよく、輪郭がはっきりした濃淡分布の無い影を生む。後者は特殊な光で、物体表面をむら無く均一に照らす。従って光の向きはどこでも物体表面に垂直であり、影は落ちない。並行光だけだと機体下面や内部構造物は完全に真っ黒な影に入って見えなくなってしまうが、環境光を使うことで影の内部でも輪郭線などが常に確認できる画となる。

　手描きアニメっぽい画となるラインレンダーを使っているためセルシェーダー（セル塗りシミュレーターの一種）も使っていると勘違いしている視聴者が国内外ともに少なくないが、画作りの意図からは不要なので当然使っていない。セルアニメ風の画作りなら別の考え方に基づいた手法の方が効率が良い（＝安い早い）が、そんなことを3DCGIで何故やるのか？できるからやる、に未だ価値があったのはかれこれ25年ぐらい前の話だ。アマチュア補正も＋10年が限界だ。

　なお"OBSOLETE"の画は、基本的に環境光だけ使った場合のそれに極めて近い。環境光はね、早くて安いのよ。

ソ連/ロシア映画 "The Dawns Here Are Quiet（А зори здесь тихие…）"

　ソ連/ロシア映画にたまにある、こういうウェットと言うか、センチメンタルな作りは日本人にも受け容れやすいのではないかと思う。この土日はネットで同じタイトルの作品のリメイク映画（日本語字幕）、リメイクTVシリーズ版（英語字幕）、そしてオリジナル映画かそれに基づくTVシリーズ（英語字幕版）を観た。やっぱり映画はスクリーンで観るかどうかに拘らず、機会を作ってでも観続けなきゃいかんなぁ。なお、原作小説を始め、この作品はソ連／ロシアでは根強い人気があるらしい。

　作品のタイトルはエントリタイトル記載の通り、"The Dawns Here Are Quiet（А зори здесь тихие…）"で、独ソ戦開戦初期のお話だ。一言で言えば戦争映画である。

　主人公は激戦地に挟まれたとある村に駐屯する対空砲撃部隊の男性指揮官（曹長）だ。ただし主人公は「村に配属されている状態」で、部隊が入れ替わっても彼が常に指揮官になる。村は沼沢地も含む起伏の激しい自然環境に囲まれているため戦場とはなっていないが、上記のように激戦地の間故にドイツ軍機がたまに通過する。このため対空砲が配備されている訳だ。だが裏を返すとこの地域は、後方かく乱などを狙った小部隊にとっては戦線の途中にぽっかりと開いている格好の侵入路だ。

　物語冒頭での主人公の悩みは戦争中としては牧歌的とも言えるものだ。ヒマがちな対空砲撃部隊の兵士たちは酒を飲んでは村人らとトラブルを頻繁に起こすのだ。ついに「酒を飲まない兵士の部隊」の配属を求めた主人公に対する上官の答えは、「女性兵士のみで構成された対空砲撃部隊」の配属だった。そして、そんな女性兵士の一人が村の近くで二人のドイツ兵を目撃したことから物語が本格的に動き出す。舞台が「沼沢地も含む起伏の激しい自然環境」であることがドラマの展開においても十二分に生かされている辺りは心憎いまでにそつがない。

　最初に観たのはGYAO!で無料配信されているリメイク映画版（日本語字幕、2015年）で、タイトルは「レッド・リーコン1942　ナチス侵攻阻止作戦」（2021/8/20まで）だ。「観たい！」と思う人がいたなら、これを勧める。２時間近い作品で、展開はゆっくりしているが、個人的にはダレることなく一気に観れた。「15+」とレーティング付きだが、これは女性兵士の入浴（サウナ）や川での水浴びシーンがあるためだろう。

　YouTubeには、上記映画の撮影フィルムに基づくTVシリーズ（全4エピソード、第１エピソード）が製作会社の公式チャンネルで公開されている。各エピソードが45分弱なので尺は映画の1.5倍あるが、ストーリーは同じものだ。追加の尺は、過去エピソードなどによる登場人物の造形の掘り下げや登場人物の関係性の強化を中心に使われている。映画版ではセリフだけで処理したり描写がそっけなかったりで分かりにくい部分に上手く手が入っている。映画とTVとの視聴環境の違い、視聴者のコンテントへの集中具合の差の観点からは、定番中の定番の処理とは言える。また、連続モノには必須のクリフハンガー（エピソードのラストで主人公大ピンチ！）のための進行調整にも使われているだろう。字幕は英語、ロシア語のみだが、CC機能を使っているのでユルユルで良ければ自動翻訳の日本語も選べる。

　最後はオリジナル映画版かそれに基づくTVシリーズ（1972年）で、英語字幕版をYouTubeで観ることができた。権利関係が？なのでリンクは控える。モノクロ主体でカラーが限定的に使われていることが一つの特長だが、良くも悪くも演出レベルでの使い分けであろう。カラーの発色具合を見てもしやと思ったが、やはり映画「惑星ソラリス」と同年の作品だった。

最悪（かもしれない）に備えよ（、ですか）：アフターサービス

　5/13のエントリで記した予測結果（予想結果ではない）は当たらずと言えども遠からず。約2週間悲観的だったか。

　不幸中の幸いは今でもデルタ株が最も厄介な変異である点で、対応とその結果が時間遅れ含めてかなり正確に予測可能であることと、ワクチン効果がほぼ期待通り見られること。ゲームチェンジは無い。とは言え、オリンピック終了後にマスコミがまた手のひらクルーするかどうかも影響因子としか思えないのには頭が痛い。

　クルーして与党批判に使うか、パラリンピックにも配慮してクルーしないか、個人的には割と見どころではないかと思っている。オリンピック向け手のひらクルーとほぼ同時期にネット上の言説にも動きがあったが、その動きの内容からは少なくともパラの段階では再クルーは無いかも知れないと思わせるものがある。ただし、スポンサーの意図は不明だ。

　国内大手企業に多いシナリオは９月いっぱいでの流行収束だが、現在の流れはそのシナリオを台無しにする方向だ。職域接種にはそのような切実な背景を見る。これまでのマスコミの振る舞いに正直うんざりしている企業は少なくないだろうと思う。多くのマスコミは気づいていないのか意図してかは不明だが、マスコミの張ってきたキャンペーンは多くの企業の新型コロナ対策活動を、よりにもよって虚偽や印象操作での邪魔してきている。新型コロナウィルスはその蔓延の終焉後にマスコミの一部を殺しにかかってくるかもしれない。

USBメモリ運用にこだわって、Linux MintをXPS 8700で使う

　先のエントリに記載の通り、セカンダリPCとなった私のDell XPS 8700は短期のうちに何度も何度もWindows10をクリーンインストールされるという憂き目にあった。が、それと並行してLinuxの導入も試みられていた。そもそもサーバー用途での運用が目的だから、OSには堅牢性、特に原因不明の（嘘、アパート内に迷惑なパケットをばらまく連中がいる）変な通信負荷を喰らっても落ちない強さが求められる。この視点からは、何れかのLinuxディストリビューション（安定版とされるもの）の導入の検討は自然と言える。ただし現行のサーバー運用はあくまで短期的なものなので、いつでもWindows10運用に戻れる状態をPCとしては維持しておきたい。

　なお、約20年程前にはRedhat Linuxベース、自作PCで数値計算用のベオウルフ型PCクラスター（6台構成）を職場で一人で組んだ経験もあるので、私自身のLinux歴自体はわりと長い。

　と言う訳で、Linux Mint MateをUSBメモリベースで運用できないか色々試してみた。Linux Mintを選んだ理由は特に無いが、パステルグリーンは好きな色だ。まぁ数値計算に使う訳ではないので、個人使用での評判が良い印象のubuntu系が良いかなとはちょっと思っていた。具体的な理由は省略するが、”ベクトル化＆MPI並列”ガチ派（地球シミュレータ全盛期に数値計算高速化を経験的に学んだ世代に多い）の生き残りなので、数値計算用ならCentOS一択だったろう（少なくとも３年前までの知識に基づけば。今はどうなんかね）。

　さて、USBメモリベースと一言で言っても、具体的な運用形態として少なくとも以下の３つの方法がある。

1. ライブUSBメモリとして使う（本来はインストールメディアなのだが、これからブートしてデスクトップ環境まで使える）
2. 書き込み可能なライブUSBメモリとして使う
3. USBメモリにインストールする

　１．のライブUSBを使う方法の利点は動作の軽さだ。Linux Mint MateのライブUSB運用でのキビキビした動作は心底衝撃的だった。また後述するように、読み取り速度がそれなりならばUSBメモリの性能を選ばないのも一つの利点だ。USBメモリからの起動となるので別ドライブにインストール済のWindows10にもEFIシステム領域にも触らないし、別PCに刺しても使える。欠点は作成したデータや変更した設定が残せないことだ。直近のサーバー運用ではウェブブラウザと１つのアドオン、加えて１つのシェルスクリプトを使うだけなので、実のところブート後の10分もあれば必要な環境は構築できる。一旦稼働すれば数週間そのままと考えれば大した手間でもないのだが、それでもそこをなんとか・・・と言うところが人間やね。

　３．はUSBメモリ自体をインストール先ドライブとして使い、既に別ドライブにインストール済のWindows10とデュアルブートできるようにする手だ。EFIシステム領域にはLinuxのブートローダー（Linux Mintではubuntuのブートローダー）が追加される。変更した設定や作成したデータは残るが、USBメモリを別のPCに指せばそのまま動く、と言う訳には当然いかない。またオチを書いてしまうと、パッケージを追加していくにつれて急激に動きがもっさりし始める。これはUSBメモリのランダム書き込み速度の影響が大きい様に思われる。別PCに刺しても動かせない、動作は重いとなると、USBメモリへインストールする旨味は実質的に無くなってしまう。要はHDDなりSSDなりにインストールしろと言うことだ。

　で、結局２．を主案として、具体的な使い方を色々試すことにした。２．の方法の利点は１．の方法の利点に加えて、作成したデータや変更した設定が残せることである。他方パッケージの追加などは、３．の方法と同様に動作を重くする要因となる。だから、「色々試す」とは、動作を遅くすることなくどこまでパッケージが追加できるか、を探ることに等しいのが実態だった。ここでメディアの作成やフォーマットには、rufus Ver.3.7を使った。

　最終結果から書くと、OS付属のウェブブラウザFirefoxにアドオンを１つ入れ、vimのパッケージをインストールして運用開始とし、それ以外は日本語環境パッケージすら入れなかった。まぁ良いんですよここまでで、現時点での利用に関してはね。とにかくキビキビ動作するところがミソで、常に開いているウィンドウはシステムモニタ、ブラウザ×２、ターミナル×１だけだ。いじった設定もファイアウォール、キーボードマッピング、電源管理（スリープ機能のオフ）、フォントサイズ（老眼対応）ぐらいだ。

　とは言え、おそらく日本語環境パッケージの導入までは、キビキビ動作をスポイルしないものと考えている。ただし、書き込み速度が高いUSBメモリを使うことが前提っぽい。実は日本語環境パッケージの導入は３つのUSBメモリで試していて、キビキビを維持できたものと、耐えられないレベルでもっさりしたものがあった。あと例外なくもっさりを引き起こしたのは、Chromeリモートデスクトップの導入だ。セカンダリPCには専用モニタが無いのでリモートデスクトップが使えると運用が便利なのだが、パッケージ導入後は起動からデスクトップ表示までは早いものの、それ以降はうんともすんとも言わなくなってしまった。

　なお、私の使ったLinux Mint Mateでは「アイドル10分で画面スリープ」がGUIからは解除できなかったので、ネット上の情報に従ってxsetコマンドでこれを解除した。全くもって先人の知恵は有難い。このエントリを書いている時点で既に４日間連続稼働しており、地味で退屈なタスクを10秒単位でこなし続けている。

　最後に検討時に用いた３本のUSBメモリの性能（CristalDiskMark測定結果）と使用感について簡単に触れておく。

　１本目は容量32GB、USB3.1対応だが、ライブUSB以外では使い物にならなかった。理由はおそらく書き込みの遅さで、特にランダム書き込みの低速ぶりが致命的のようだ。下に示すCristalDiskMark測定結果の図中右下の数値がランダム書き込み速度だが、0.00MB/sって何ですか？このUSBメモリにはインストールも試みたが、ファイルのコピー（書き込み）が余りに遅いため、インストール開始から完了まで20時間程を要した。就寝前に開始したファイルのコピーが、起床時には未だ終わっていなかったのには正直驚かされた。繰り返すが、ライブUSBとしては全く問題を感じることは無く、動作は常にキビキビしていた。また同製品はWindows10の回復ツールを格納してクリーンインストールの際に何度も使っており、そちらでも特に問題や不満を感じたことは無かった。最初にisoイメージファイルをシーケンシャルで書き込み、基本読み出しでしか使わないから、ランダム書き込みが悪さする状況が無いんだわな。

　２本目は容量16GBでUSB3.1対応で、インストール先にしてもインストール作業自体は2時間もあれば終わった。１本目との最大の違いはランダム書き込みが数百倍速いことだ。書き込み可能なライブUSBとしても速度的に使えるレベルだが、容量が小さめなのは微妙に問題。書き込み可能領域として8GBは確保できるので日本語環境のインストール（4GB程度必要）もできて２．の使い方でも容量は十分とする向きもあるが、作業内容によってはtmp下に8GBは欲しい場合もある。私の場合はtmp下に16GB欲しかったので、より容量の大きい３本目を使うこととした。

　３本目は容量128GB、USB3.2対応で、書き込み可能なライブUSBとしては容量的にはオーバースペックかと思う。右上のシーケンシャル書き込みが３本の中で圧倒的に速いが、その差を実感したことは無い。２．の使い方では書き込み可能領域に64GB割り当てたが、tmp下の容量は要求ギリギリの16.7GBだった。まぁ不要ファイルの削除をシェルスクリプトで徹底的に処理するようにしたので、問題無いでしょ。３．の使い方のインストール先としても使ってみたが、Chromeリモートデスクトップの導入後は重いどころの騒ぎではなく使い物にならなかった。LinuxのUSBメモリでの運用では、ランダム書き込みの速度がOSの動作速度に明らかに影響するように見えるが、同レベルの別要素も有るようでイマイチすっきりしない。まぁ、書き込むばかり、読み込むばかりなんて状況は実用上はまず発生しないからねぇ・・・

Dell XPS 8700の受難

　余りに馬鹿々々しい経験をしたのでメモっとく。他人にとっては面白くも無いし、まず役にもたたないだろう。

　昨年9月にほぼ６年ぶりに新規PCを購入し、従来のメインPCだったDell XPS 8700はセカンダリPC扱いとなった。手間はかかるが金はかからない正規の手続きに従いとっとと処分する予定だったが、緊急かつかなり非生産的な理由により24時間稼働のサーバーとなった。ある時はデータサーバー、またある時はネット帯域監視サーバーと用途を変えつつ、今後も暫くは稼働予定である。

　私のDell XPS 8700は2014年のWindows7プレインストールモデルで、CPUはIntel i7-4790（4コア8スレッド）、メモリは32GB、グラボは最終的にnVIDIA GTX1070になった。ゲーム、3DCGI、DAWと全て睨んだ上での構成だ。ただ起動途中のシャットダウンなど故障が予測される兆候も示し始めたことから、第一線を退いてもらうことになった。

　さて、 エントリタイトルにもある受難のスタートラインであり、以降でキーとなる初期状態を列挙する。

• レガシーBIOSブートである。これはプレインストールのWindows7から上書きでWindows10に無償アップグレードしたためだ。
• OSはWindows10 Proで、Windows10自体の機能を使って初期化した。

次いで内部のドライブ構成について示す。

• ドライブ０：SATA 2TB HDD、以降は単にHDD、ドライブレターは\D
  
• ドライブ1：mSATA 256MB SSD、以降は単にSSD、ドライブレターは\C

初期状態のブートドライブはもちろんSSDだ。

　さぁ、淡々と行こう。

１．BIOSのアップデート　→　セキュリティ関連ファームウェアの破損

　BIOSをA13から最新のA14にアップデートした。アップデート用ファイルはもちろんDellから入手したものである。BIOS自体はアップデートされたが、セキュリティデバイスである「Intel Management Engine Interface」のファームウェアのアップデート中にエラーが発生、オプションで強制書き込みを指定してもアップデートが弾かれるようになった。もう少し状況を丁寧に書いておくと、アップデートプログラムがファームウェアのバージョンを取得できないままエラーを吐いて落ちる。結果、OS起動後のデバイスマネージャー上で「Intel Management Engine Interface」と「SMバスコントローラ」に「！」マークが付く状態となった。

２．SSDからのUEFIブートにブート方法を変更　→　SSDのディスク形式を誤変換

　ブート方法を変更するには、まず起動ドライブのパーティション形式をMBRからGPTへと変更しなければならないが、Windows10には"mbr2gpt.exe"というそのためのコマンドが用意されている。"mbr2gpt.exe"の良いところは、ディスクの内容は一切失わないことにある。早速このコマンドを試したところ、エラーで変更できない。原因は所謂OEMパーティションというやつだ。OSプレインストール版メーカーPCの多くで、起動ドライブのパーティション構成はメーカー独自となっている。Microsoftにとっては預かり知らない状況となっている訳で、"mbr2gpt.exe"にパーティション構成を教えてやらなければならない。ネットを漁ると教えるべき内容を見つけることはできるが、まぁ、当然ながら色々とリスクだらけだ。

　で、Dellのユーザーコミュニティスレッドで見つけたとある情報を使って"mbr2gpt.exe"を実行したところ見事変換完了、BIOS/UEFIでブート方法をUEFI、Windows Boot Managerに変更したところ見事OSが起動した。動作は快調だったのだが、ディスク管理画面を見るとSSD（\C）の中身が見えない。実は "mbr2gpt.exe"実行時に使った情報には１ヶ所誤りがあり、本来ディスク形式を「ベーシック」のままにしておくところを「ダイナミック」に変換してしまっていたのだ。

　SSDの中身を失なわずに「ベーシック」に戻す方法は基本的に無い。有料中華アプリで対応できるものもあるとのことだったが、本質的な原因はWindows7プレインストールPC用のOEMパーティション構成だ。ここはもう意味の無くなったOEMパーティションの呪縛から逃れるべく、Microsoftの回復ツールを使ってWindows10をSSDへクリーンインストールすることにした。既に紐付け済みのマイクロソフトアカウントとXPS 8700のハードウェア情報に基づいてWindowsライセンスを認証してもらう必要から、インストール時はインターネットと有線接続しておいた。

３．Windows10をHDDにインストール後、SSDに再インストール
　　→　OSはSSD、EFIシステムパーティションはHDD

　Microsoftの回復ツールを書き込んだUSBメモリからブートしても、SSDの再フォーマットなどは回復ツール上からはできない。これがダイナミックディスクの罠だ。一方、HDDはNTFSでベーシックドライブ、しかも空っぽだ。

　と言う訳でSSDを取り外し、Microsoftの回復ツールでまずHDDにWindows10をインストールした。HDDからブートすれば再取り付けしたSSDのディスク形式などもディスク管理機能で変更でき、晴れてSSDへのWindows10のクリーインストールの準備が整った。SSDへのインストールの為だけに、一度HDDにインストールした訳だ。当然ながら、EFIシステムパーテションはこの時点ではHDD上にある。

　USBメモリ上の回復ツールを使ったSSDへのWindows10のインストールは何のトラブルも無く完了し、これで万事OKかと思いきや、EFIシステムパーティションがHDDに残っている、っつーか、HDDにあったEFIシステムパーティションがアクティブのまま使われていて、SSDにはEFIシステムパーティションすら無い。これはHDDを使ってSSDをブートすると言う余り上手くない状況と言える。場合によってはHDDは外してしまおうかとも思っていた矢先、本当に上手くない。

４．Windows10をSSDに再々インストール、HDDをまっさらに

　HDDの信号及び電源ケーブルを抜いてMicrosoftの回復ツールを書き込んだUSBメモリでブート、SSDへWindows10を再々インストールした。アクティブなEFIシステムパーティションがSSDに移動したのを確認し、アクティブではないEFIシステムパーティションを含むHDDの全領域を削除、フォーマットした。本来は２．の途中で終わっていた筈の作業がここまでかかってしまった。

　ところが24時間稼働状態にしたところ、特定の通信内容に対してネットワーク機器が停止することが分かった。時に不意の再起動も起こす。調べると、PC起動から10分程度経つと「Intel Management Engine Interface」に「！」マークが付き、不具合が起きた時にはその状態にあることが分かった。

　実は「Intel Management Engine Interface」に「！」マークが付くことは以前から少なからずあり、これまではBIOSアップデートなどで解決してきた。が、「Intel Management Engine Interface」に「！」マークが付いているからと言って、ネットワーク接続やPC自体が不安定化した記憶は無かった。その当時との違いについて改めて考えてみると、ブート方法とWindows10のバージョンの違いしか思いつかなかった。

５．Windows10をSSDに再々々インストール、レガシーBIOSブートに戻す
　　　→　「違う、そうじゃない」ことに思い至る

　レガシーBIOSブートとすべく、SSDにwindows10を再々々インストールした。インストール作業が必要な理由は、SSDのパーティション形式をEFIブート用のGPTからレガシーBIOSブート用のMBRにする際に、ディスクの内容が全て消えるからだ。

　さて、レガシーBIOSブートとすることで、「Intel Management Engine Interface」に「！」マークが付いていても、OS自体の勝手な再起動やシャットダウンは発生しなくなった。 一方、ネットワーク機器の停止は１日に２回程度発生し続けた。

　いよいよ頭を抱えざるを得なくなったところで天啓（になるかも知れない）が訪れた。2000年代前半まで、つまりPCを自作していた時代の自分なら真っ先にやっただろうことを思いついたのだ。

　CMOSのクリアだ、困ったらコレ。That's the PC-AT!!

　手順と結果は別エントリに記載してあるが、"Intel Management Engine Interface"のファームウェア更新も成功し、デバイスマネージャーから全ての「！」が消えた。

６．EFIブート再び

　72時間連続稼働に耐えたし、「！」マークも現れないので、改めてレガシーBIOSブートからEFIブートに変更することにした。今回のSSDのパーティション構成はMicrosoftによるものだから（＝OEMパーティションではないから）、"mbr2gpt.exe"はそのまま使える筈だ。結論から言えば全く問題無し、"mbr2gpt.exe"実行後に２回再起動（BIOS/UEFI設定変更含む）して以降は快調そのものだ。現在24時間稼働の２日目に突入、ログを見ると以前はネットワーク機器停止に至ることが多かったイベントにもきっちり耐えている。テスト兼実運用は暫く続くことになる。

　あと、「！」マークを消す件は色々と重要だ。「Intel Management Engine Interface」に「！」マークが付いている状態では、EFIブートに異様に時間がかかった。Dellロゴが表示されている時間が３～５分、Windowsロゴが表示されている時間が約20秒といった具合だった。今やDellロゴが10～20秒、Windowsロゴは表示されることもなくサインイン画面に至る。

７．実は書いていないこともある

　やれ24時間稼働だ、やれサーバーだ、なんて話なら、Windows10に拘る必然性は全く無い。実際、並行してLinuxの某ディストリビューションの導入も試していたのだが、USBメモリでの運用に拘ったために沼ってしまっている。昨夜辺りで「快適に使いたければここまでにしときなさい」というラインが具体的に見えたので、それが再確認できて気が向いたら別エントリに顛末を書くことになると思う。それはそうと、他製品と比べてシーケンシャルリード・ライト、シーケンシャルライトは悪くないのに、ランダムライトだけ1/200以下っていう製品（個体ではない）があるのは、USBメモリ界隈では普通なんですかねぇ？