時代おくれ－伝言板

時代おくれ－伝言板

[表紙に戻る]　 [伝言板使用上の注意]　 [ワード検索]　 [過去ログ]　 [管理用]

名前

件名

本文

暗証キー （英数字8文字以内／修正・削除に必要です）

[1710] Speed=0.000925 投稿者：Mariya YAMADA 投稿日：2024/11/15(Fri) 12:59: 業者から納品された動画ファイルがMXF形式で、手持ちのCS6 Premiereでは処理できなかった（現行CCならできるらしい）。

MXFは業界標準でSonyなどのAV機器でも採用されており、α99にもあった気がする。そのままでは作業ができないので調べてみると、ffmpegと言うコンソールツールで変換できることが判った。Windows／Linux／Mac版があるが、まずLinuxでテストした。

> [1686] 非「時代おくれ」メモ（2）　Mariya YAMADA　2024/06/02
> 7950Xで（Coreが）1個しか使われていないのは「負荷が足りない
> から ^_^;」と言う結論に達した。

RyzenのCoreが遊んでいる、これ本当に役に立っているのか？と言う不満（不安 ^_^;）があったのだが、ECOモードからMB Defaultに切替えffmpegを走らせた瞬間、16Core／全32Threadが85～95％に跳ね上がりほぼ飽和状態、久々にファン唸りを聞いた。
Linux版の出来が悪くて単にCoreの無駄使いをしている（必要ではない）可能性を疑い、Windows版でも確認したが同様の結果になった。
再生速度を1とした場合の変換速度はLinux 1.15、Windows 0.975でLinuxが速く、なんだか気分が良い (^_^)

なお、GPU／GeForce RTX 3060を併用するとWindowsの場合で速度1.5倍程度の高速化、CPU負荷も50％程度で使用Core数も半分程度になった。しかしGPU併用は対応可能なコーデックが限られ、画質も落ちるので非採用、今後、作業時間の短縮を迫られない限りソフトウェア・コーデックでRyzenのパワーを楽しむ事を選択する。

　　LinuxはNvidia Driver／Cuda未導入で（現時点では）使えないし (^_^;)

　　2024.11.16追記：Debianにnvidia-driverとcudaを導入、テストした
　　ところSpeed=1.7、使用コア半分程度、その負荷30％以下と大幅に
　　改善したが、変換に失敗／画面は真っ暗。まぁ使う気はないので
　　それはどうでもよいが、またSecure Boot問題に捕まってしまった。
　　[1711]に続く

しかし動画エンコードが再生速度より速いって、Ryzenやはり凄い、お布施は無駄ではなかったと安心納得する。当面必要な3時間分ほどのデータ（30秒～10分程度の細かい多数のファイル）変換は半日かからず完了した。

ふと気になって1Core／1ThreadのAthlon君にも同じミッションを与えてみた。投稿タイトルでネタばれだが、Linux版でSpeed=0.000925と1時間で3秒しか変換できず・・・もちろんCPUは100％ベタ、続けると焼損させてしまいそうなのでそこで止めた。

Athlon XP 2400+ からRyzen 7950X、この20年で速度が1243倍になっている。雷神様すげ～、ってか、でないと困りマス (^^ゞ
[1709] 賽の河原 投稿者：Mariya YAMADA 投稿日：2024/11/12(Tue) 23:03: WindowsXPのサポート終了後の臨時パッチの適用完了、賽の河原から只今脱出！

クローン取ったら寝よう。

---- TLS1.2対応 XP IE8から ----
[1708] IDE <=> SATA 投稿者：Mariya YAMADA 投稿日：2024/11/11(Mon) 19:59: Athlonが乗るマザーボード、MS-6378 Rev.3(MSI製2002年発売？)はIDE（PATA）のみ、SATAインターフェイスを持たない。これでSSDを使う最も問題が少ない正解は「IDE40pinコネクタの3.5"SSDと換装」することだが、そんなものは既にない。IDE-HDD／SATA-SSDの移行期でもそうした製品は非常に少なかったと聞いている。

すると自動的に、6378にSATAカードを増設する or 個別ストレージにIDE変換コネクタを付ける、の二択となる。SATAカード増設は安直すぎ、かつIDEマザーでは無くなってしまうので個別ストレージのIDE変換を採用する。

厳密にはSSDではないが同様に駆動部をなくす方法として、CF（Compact Flash）→IDE変換アダプタがある。CFはIDE規格の延長上にあるため起動ディスクとして問題なく使え、それなりの速度も出ることは過去にノートPCで確認済みであるが、最大の欠点として「高い・高すぎ」がある。壱萬円超の128GB CFを予備含め複数確保するのは私にとって現実的選択肢ではない。

このCFの代替案として「安価なSD」をIDE変換するアダプタも今回テストした。電送バス／IDEとして認識され動作そのものは安定していたが、4K動画撮影に使用している高速タイプを用いても遅い、元のHDDの半分以下。
そして致命的な欠点が発覚、多くのアダプタでFC1307Aチップが使われているがファームのバージョンにRev1.3と1.5があり、1.3ではLinuxが起動しないと・・・
> https://zenn.dev/mctek/articles/306d1afc153c0b

内容はよく理解できないが、テストに用いた製品はRev1.3で確かにDebianは起動しなかった。ファームは製品の外見では判別できず、実際に取り付けデバイスマネージャ上で確認する必要があるが、売っている（輸入している）側はそんなもの気にしておらず、購入前に知る方法は（多分）ない。
遅いことが判っているアダプタを複数業者からバラバラに購入して「当たり（1.5）」を集めて使うのはどうかと思う、外れはゴミだし。かつ、SDは純粋な消耗品であり規格上も実際上も耐久性と言う概念はない（と言われる）、と言うことでこのSD→IDEアダプタも没となった。

----------------------------------------
SSD化構想時の計画（妄想 ^_^;）は「mSATA（Mini SATA SSD）をIDE変換して使う」だったが、探してみるとmSATA→IDE40pin変換アダプタが流通していない。そのため、mSATA→SATA→IDEの2段下駄となってしまい、速度的デメリットが予想されるが、多少のダウンは許容しよう、と。

　　mSATA→IDE44pin（ノート用）→IDE40pinでも結果は同じであるが、
　　アダプタ単体の使いまわしを考えるとSATA→IDE40pinの方が得、今後
　　IDE2.5"を3.5"に変換する場面はなさそう、と言うことでこれは非採用。

実際に取り付けてみるとOS、少なくともWindowsからは電送バス／SATAとして認識されている。新しいマザーにはSATAをIDEとして認識させるオプションがある様だが、6378にそんなものはない（BiosがSATAを知らない）。将来これに起因するトラブル発生の可能性は否定できず。
認識されないmSATA製品もあるが、その原因がmSATA→SATA段階なのかSATA→IDE段階なのか、あるいは併せ技なのか、そもそもmSATAだからなのか、それは不明。

認識されたmSATAにWindows7をインストールしたら「爆遅（ばくち？ ^_^;）」で27時間かかった。インストール・起動は可能でも、この速度での実運用は無理。2K、XP、7のNT系で確認すると原因はディスクアクセスがKB速度のPIOモードになっていること。
6378にはディスクアクセスに関するオプションはPIO（0～5）とUltra-DMA（Auto／Disable）しかなく、試行錯誤でUltra-DMA／Disableで「DMA MultiWord mode2」で動作することが判った。Windows NT系では本来のUltra-DMAの旧HDD（mode5？）と比較してRead 30→15MB/s、Write 12→15MB/sとなった。

　　なおDebianはマザーの設定に関わらず、Read 32MB/s、Write 28MB/s、
　　Seek 0.3ms（HDDの50msから爆速化）で動作し非常に快適。
　　逆に言うとBiosレベルで何かをマスクしたいとき、それを無視して
　　独自にハードウェア情報を得るLinuxには意味がない事になる。以前、
　　マザーの設定で使用不可にしたNICで通信されてしまった「事故」を
　　思い出した。

MultiWord mode2の場合、Windows7インストールは1時間強で完了、実際に起動してみると元HDDより好感触で特に遅いとは感じず、Read半減を（Linuxから類推して）爆発的なSeek向上で相殺しているのだと思う。なおインストール後にUltra-DMAを有効にしたらPIOモードに落ちた（所謂PIO病）。

　　NT系OSならインストール後にUltra-DMAモードにする方法はあるが、
　　9x系やその他OSでも可能とは限らないので、できるだけハードウェア
　　レベルで問題を解決したい、と考える。

計測上の速度低下は容認、MultiWord mode2運用前提で認識可能なmSATAを複数確保、それでSSD化を図る、そのつもりでヤフオクを漁ったら、SSD化を思い立った5～6年前と状況が変わっていた。当時の価格リサーチでは128GBなら mSATA＜2.5"SSD だったのが、128GB mSATA≒256GB 2.5"SSD となっていた。

　　安いからmSATA採用だったのだが・・・mSATA価格も熟れて
　　安価になっているが、2.5"SSD特に小容量はさらに安価に
　　と言うより下落して完全に逆転している。

- - - - - - - - - - - - - - - - - - - - - - - -
BigDrive縛りで128GB（サバ読んで137GB）以上は使えないが、256GBのSATA SSDを使用し半分だけを領域確保して運用すれば寿命は飛躍的に伸びる（はずだ）。同じ値段ならそちらが得策で、少なくとも不要になるmSATA→SATAアダプター代は確実に節約できる。

早速256GBのSSDを1台調達してテスト・・・この場合も電送バス／SATAとして認識されてしまうが、Ultra-DMA／Autoで問題なく動作した。手持ちの複数のSATA機器、SSDとHDDで確認したがどれもPIO病は発症しない。よく考えてみれば10年ほど前に換装したDVD DriveはSATA→IDEアダプタで変換したSATA規格製品であるが、アクセスには何の問題も起こっていなかった。

　　2024.12.03 追記：我が道をいくLinuxはRead 32MB/s、Write 26MB/s、
　　Seek 0.34msと変化はないが、Windowsでは高速化した。が9x系Read
　　70MB/s、Write 31MB/sに対しNT系は42～52MB/s、15～16MB/sと差が
　　出た。
　　LinuxとWindowsで計測ソフトが違うのでその差はよいとして、同一
　　ソフトで計測した9xとNTの差はなぜだ？
　　ドライバ性能の差、ってNTが劣るのは考えにくい。ファイルシステム、
　　領域フォーマットの差だとしたら「NtfsよりFat32が正解」となって
　　しまうのだが・・・そのうち調べよう。暫くはインストール作業から
　　離れていたい (^_^;)

SATA 2.5"SSD 256GBをSATA→IDE40pin変換アダプターで接続することに決定、同型のSSDを追加で2個購入、1個あたり3年強持てば後10年は大丈夫と言うことになる。先にSSDが尽きるか、MS-6378（予備も1枚あり）が先に死ぬか、勝負である。

なお、SATA→IDE変換には、Master／Slave設定ジャンパーがある
> https://page.auctions.yahoo.co.jp/jp/auction/g1157028069
これを使っている。

設定時などに頻繁にHDDを脱着する場合、面倒なので4pinペリフェラル電源だけ抜いてケーブル上にHDDを残して作業することは多い（この横着は私だけではないはずだ ^_^;）。
しかし、無通電のこのアダプタがケーブル上に存在すると「マザー側から何かが見える」らしく「IDEデバイスの検出に失敗」する、当然起動しない。面倒でも使わない場合は取り外す必要がある。

----------------------------------------
本番に向けたSSDの下処理中に【衝撃の事実】が明らかになった・・・6378はBigDrive対応で【普通に128GB超ディスクを認識】できる。ずっと、少なくとも前回マルチ環境構築の2017年2月以降、6378はBigDrive非対応だと思っていた。冷静に思い返すとその根拠は不明、単なる思い込みだった。

OS側のBigDrive対応であるが、DOS～Windows9xは128GB超でも問題なく起動する（DOSは先頭パーティション、9xは先頭から4GB以内のパーティション、の縛りのみ？）。WindowsXP、7とDebianはもちろんBigDrive対応で、非対応はWindows2K無印～SP3のみだが、これもSP4適用後は設定で対応可能。

つまり、Windows2Kを除けばBigDrive縛りは存在せず、私は思い込みに縛られて128GB前提で計画・行動していた。手持ちが2K SP1なので128GBまで領域確保してインストール、BigDrive対応設定後に残りの領域を確保する、この方法であれば実質的には縛りはなかった。

　　ピンポイントでWindows2Kを再インストールする場合に面倒になる
　　のは避けられないが、まぁ容量確保を優先する場合には十分許容範囲。

ならば調達済み256GB SSDはフルに使って、と一瞬思ったがここは初志貫徹、システム領域（sda1）は耐久性優先で128GB制限とし、データ領域（sda2以降）でBigDriveは生かすことにする。

----------------------------------------
真っ先に除外されたSATAカードの増設であるが、一応リサーチは行った。安価な製品で中国から直（eBay）なら送込み2,000円程度（がヤフオクだと壱萬円！）で、選択肢として十分に有りだとは思う。

3本のPCIスロットはGeForce4、Sound Blaster、増設USB 2.0で既に埋まっているが、見つけたSATAカードは使われていないPCIe（PCI Express）スロット用、将来気が変わった時に備えて2～3枚キープか？とポチる直前、素朴な疑問が・・・あれだけ典型的な化石にPCIeがあるのは不自然、本当にPCIeなのか？

気になってマニュアルを読み返したら、私がPCIeだと信じていたものは、最新（の基準は2000年頃ね ^_^;）の通信用スロットCNR（Communication and Network Riser）といふものだそうな。
また、段ボールの闇に物を沈めるところだった、危な～い (^^ゞ
[1707] Athlon補完計画 投稿者：Mariya YAMADA 投稿日：2024/11/06(Wed) 23:11: 書込みが切番～切番となり間隔も空いてしまったが、臥せっていた訳でも隔離されていた訳でも、もちろん収監されていた訳でもない。長らく放置されていた「Athlon XP補完計画＝SSD化」がついに始動、それに没頭していたのである。
と言うと聞こえが良いが、マルチ環境を不注意で完全崩壊させてしまい、止む無く再構築中。手間は同じなのでこの機会にSSD換装する、が本当のところ。

Debian12アップデートの嬉しさでLinuxツールでHDDを弄っていたら、Windows7インストール済みのsdbに「TiB単位のゴーストパーティション」が発生、7は起動しなくなった。それを復旧しようと足掻いていたらsdaのWindows98と2000が領域ごとなくなり、2000再インストール時に勘違いでDebian12領域に上書き、しかも2000インストールにも失敗。

我家の主力Athlon君はWindows3.1とXPのディユアルマシンと化してしまった、そしてsdbのゴーストは残ったまま (T_T)
非常に古い貰い物のHDDを使用しており寿命的不安（ゴースト発生も単に寿命の可能性）がありこれを修正するより、新ストレージにゼロから再構築したほうが良い、IDE（PATA）のHDDは入手困難なのでSATAにする、価格的メリットもほぼ無くなっているのでHDDではなくSSDにする、と言うことで9月24日に「Athlon XP補完計画＝SSD化」が始動した。

20年前に世間を悩ませた種々の問題に、現在進行で悩まされている。一応、だいぶ前から計画／構想はあったのだが、良くあることで実際に作業すると計画通りには進まない。
Windows3.1、95、98、2000、XP、7とDebianの7環境を128GiB（BigDrive縛り）の単独ストレージから起動する、これが目標であるが、初期化、インストール、クラッシュそしてまた初期化から・・・な日々を送っている。

IDE vs SATAで躓き、HDD vs SSDで転び、FAT vs GPTでまた躓き、と楽勝と予想していたハードウェア補強に2週間以上かかった。ようやくマルチ環境インストール！と思ったら「心霊現象続発」で作業が進まない。

単独だと問題ないのにマルチだと初回再起動で全拡張領域を破壊し拡張領域にインストールできない 98 とか、「このディスクにはOS/2がある」でインストールが終了する 2K とか、パーティションの問題修正をOKしたらディスク全体をフォーマットする XP とか、上手くいったと思ったら最後の1環境インストール失敗で全体が潰れるとか賽の河原状態、Towns時代を思い出してしまった。

現在、7環境を1ストレージにインストールする方法手順はほぼ確立できているが、インストールする順番に縛りがあり、Debianを例外としてピンポイントで問題のある1環境（Windows）を再インストールすることが（今のところ）できない。

この40日で100回超の各種OSインストールを試行、忘れていたこと、知らなかったこと、有り得ない謎現象、などなどネタが蓄積中。これが「新・PC/AT活用講座」に反映される予定、乞うご期待！な雰囲気。

さぁ、今晩も賽の河原で少し石積んでから寝よう。
[1706] 祝 (^_^) 捌萬壱阡アクセス 投稿者：Mariya YAMADA 投稿日：2024/11/06(Wed) 22:43: 告知が遅れてしまいましたが、10月31日「捌萬壱阡アクセス」に到達致しました。ご訪問頂きました多くの方々に感謝致します、有難うございました。

ご訪問頂きながら更新できず、ですが、ついに「PC/AT更新に向けたパーツの撮影」が開始されました。今度こそ「カミングスーン」であってくれ、と本人が祈っているところです (^_^;)

時代おくれ、今後ともよろしくお願い致します m(_ _)m

----------------------------------------
> この1,000アクセスのトップカウンタ
この1,000アクセス（概ね2024.08～10）のトップカウンタは、12.5人／日でキッチリ謎定数、増えもせず減りもせず。
Webalizerによる1日あたりの訪問者数は8月74人、9月73人、10月58人と（100人に向けた）増加傾向から減少に転じたかも・・・

> この1,000アクセスのTop5（Webalizerのヒット数）
【8月】
399　/programming/language.html　フリーの開発環境
234　/pcat/pcat30.html　　　　Windows95と必須パッチの確保
65 　/pc98/desktop1.html　　　PC-9801／デスクトップ 1
51 　/pc98/waruagaki.html　　　PC-9801／悪あがき
46 　/pc98/desktop2.html　　　PC-9801／デスクトップ 2

【9月】
433　/pcat/pcat30.html
302　/programming/language.html
52 　/pc98/desktop1.html
47 　/pc98/waruagaki.html
45 　/soft/dos.html　　　　　　ソフト案内／DOS

【10月】
504　/pcat/pcat30.html
267　/programming/language.html
44 　/pc98/epson.html　　　　　PC-9801／Epson互換機
41 　/soft/w_sys.html　　　　　ソフト案内／システム
39 　/pc98/note.html　　　　　PC-9801／ノート

ここの圧倒的2強はやはり「フリーの開発環境」「Windows95と必須パッチの確保」で、それに98ネタが続いている。ソフト案内の「DOS」「システム」がランクインしているが、それも「NECCD.SYS」「640×400ドット再利用計画」や「EPSON Windows95対応モジュール(11)」など98関連でのヒットかな？と思う。
PC-9801・・・なかなか人気が落ちない、それだけ実機が残っているんだろう、Townsと違って売れたからね (^_^;)

> この1,000アクセスの（突飛な）UA
【8月】
0.17%　MSIE 6.0～11 (Windows NT 5.1～6.3)
0.54%　Firefox 35～73 (Linux／Windows NT 5.1～10)
0.13%　Opera 9.80 (Windows NT 5.0) Presto/12.02
　　　　----- 計0.84％ -----

【9月】
0.97%　MSIE6.0～10 (Windows NT 5.0～10)
1.08%　Firefox 3.5.5～72 (Linux／Windows NT 5.0～11)
1.45%　Opera 9.80 (Linux／Windows NT 5.0～5.1) Presto/12.02
　　　　----- 計3.50％ -----

【10月】
0.60%　MSIE5.5～10 (Windows 98～NT 10)
1.27%　Firefox 4.0.1～79 (Linux／Windows NT 5.0～6.1)
0.01%　Mozilla 4.8 (Windows NT 5.1)
6.92%　Opera 9.80 (Windows NT 5.0～6.2) Presto/12.02
　　　　----- 計8.80％ -----

これはOSの縛り＝旧版Windowsが増えたからとも言えるのだがMSIEが目につく。9月は1％に迫っており通常は有り得ない比率だと思う。

何故かそのような縛りはないはずなのに旧版FireFoxが使用されている。9月には1％を超え3.5.5までいる、10月にはさらに増えもはやFireFoxですらないNetscape Communicator 4.8って。構造の単純な「時代おくれ」すらまともに表示できないのでは？と心配になるレベルの古さ。
差し支えなければ「FireFoxを更新しない理由」をお聞かせ下さい m(_ _)m

旧環境（特にWindows 2000）でPresto版Opera 12を使うのは私の判断では賢い選択であるが、10月はほぼ7％と驚異的な比率。全盛時でもこんなに居なかったはず、これは私のOpera 12キャンペーンの成果か (^_^;)

8月→10月と突飛UA率が急激に跳ね上がっているが、世間の旧版率が上がったのか、旧版で閲覧可能なページが減ってここに吹き溜まったのか・・・後者だろうな、多分。

----------------------------------------
懸案のGo-http-client/1.1のアクセス数は8月2417、9月2298、10月772であるが、順当にブロックされておりForbiddenとほぼ一致している。10月にはかなり減って遂に無駄を悟ったか？と喜んでいたら・・・

11月1～5日の集計であるが、
　　1819（46.44%）　fasthttp
　　　 2（0.05%）　 Go-http-client/1.1　
　　と新たな謎UAと入れ替わっている。

ちなみに10月のfasthttpは2（0.02%）で、調べてみるとこれもGo言語の通信コンポーネントだった。このあまりに露骨な逆転から「使用コンポーネントの変更があった」と判断し「fasthttpもブロックリスト入り」にした。明日以降、Forbiddenが激増したら「正しくfasthttpがブロックされた」ことが確認できる（さくらのログは零時締）。

所謂「いたちごっこ」だが、もういいや、大手botと通常ブラウザ以外は拒否することにする。まぁUA偽装で突破されてしまうわけだが「通常のUAに埋もれる程度の頻度」ならそんなに害はない（不正試行回数は限られる）だろう、だよね、多分。
[1705] Windows 2000 投稿者：Mariya YAMADA 投稿日：2024/11/06(Wed) 20:09: Windows 2000／IE6から書込みできた (^_^)/
[1704] 祝 (^_^) 80486アクセス 投稿者：Mariya YAMADA 投稿日：2024/09/16(Mon) 19:24: 9月14日（たぶん）深夜、トップカウンタが「80486（ハチマルヨンハチロク）アクセス」を通過しました。私にとっては「大切な切番」です。

元祖8ビット8080、初代16ビット8086、伝説の16ビット80286、初代32ビット80386、そして32ビット完成形／栄光の80486、私は「80486（とAm486やAm5x86）」でPC/AT互換機のハード／ファーム／ソフトを学びました。

CD-Romなし低スペックPCへの9xインストール、野良Biosで（32GBとかの）HDD認識上限突破、ドライバの見つからないカードを「ドライバ総当たり」で動かす、設定情報のない中古マザーに試行錯誤で80486を乗せる、インストーラに跳ねられた環境にソフトを手作業でインストール、などなど・・・今思い返すとあの情熱は何処から湧いていたのか、それは謎ですが「たぶん病的に」燃えていました (^_^;)

その頃の経験知識で固まってしまい、新しい技術思想に対応できにくい人になっている可能性もありますが「情報の質と量は一級品」無検証転載ではなくすべて確認済です。その頃の情報を元に「時代おくれ／PC関連項目」は書かれています、必要な方には必要な情報、御参考になれば幸いです（そうでない方にはゴミですが (^^ゞ）。

---------------------------------------
当時（20世紀 ^_^;）のPCセッティングの基準は今では想像もできないだろうが「人間のタイピング速度より処理が速いこと＝入力遅延が起こらないこと」で、PC雑誌にも特集記事があった。

基本はメニューのアニメーションなど無駄な機能の切り捨てで、Officeのカイルなど論外「CPUに目的以外の事をさせない」だが、Windows9xをOSとする限りそれは80386や486SXでは無理、80486DXやDX2では単独のタスク（ウインドウ）であればギリギリ可能、マルチタスク下で入力遅延が発生しなくなったのは80486DX4（100MHz）以降と記憶するが、それでも手加減せずに負荷をかけるとクラッシュした。

そんな非力なCPUの時代、クロックアップは一部暇人の遊びではなく、結構普通のセッティング手法で、Socket3や7マザーはそのように作られていた。と言うかCPUの自動検出機能がないので手作業で自由に設定できた。

メーカーが安定して動作することを保証した上限を越える電圧／クロックで駆動すると、そのうち発熱で不安定になり熱暴走／クラッシュする。この発熱対策がポイントとなった。
涼しい部屋にPCを置くのは当たり前、筐体を開けて扇風機で直に風を当てる、冷却フィンにアルミ洗濯バサミを付けて表面積／放熱量を増やす（私）、熱伝導性の高い純銅製のクーラにする（お金持ち）とか、色々な工夫があった。

その中に「CPUの上面を砥石で削って薄くし放熱能率を上げる」禁断の技があった。シリコンダイを保護するCPUパッケージを可能な限り薄くし、CPUクーラーに効率よく熱を誘導する「予算も高度な知識／技術も不要（要蛮勇 ^_^;）」で確かに有効だが実際には「不毛なチキンレース」だった。
薄いほどクロックは上げられる。削って動作確認、これを繰り返し限界を見極めるのだが、もう少しだけ、あと1回と欲張って「削りすぎでダイがむき出しになり・・・崖から転落」の結末も珍しくなかった。私も何個か昇天させている、合掌。

　　経験者からのアドバイス：非常に有効であることは認めるが
　　削る前に上面にプリントされている型番、電圧、クロック数
　　などをメモしておかないと、元に戻したいとき困る。
　　複数同時に作業する場合は、そのメモとCPUを確実に結びつける
　　目印などの工夫が必要。

　　K7／Athlonでシリコンダイが剥き出しになったとき、そう
　　来たか、それで大丈夫なのか？と思ったが、大丈夫ではなく、
　　クーラ脱着時に割ってしまう事故が多発したらしい。中古品の
　　能書きに「ダイの欠け割れありません」を見かける。

そこまで頑張っても所詮はクロックアップ、使用者がCPU負荷を監視して操作を控え溜まった処理を終わらせるなど配慮しないと暴走クラッシュしてしまう。そのためにタスクバーやデスクトップの隅にCPU使用率を表示するツールもあったが、本当に極限に近いクロックアップだと「CPU使用率表示が加わったことが致命傷」となって落ちてしまう悲しい事故もあった (T_T)

個人的感覚だと「K6-2／400」あたりで「PCは普通に操作できる物」になったように思う。その以降はクロックアップなどしていない。
我家では21世紀初頭のK6-2やAthlonで時間が止まったためすっかり忘れていたが、その当時「将来CPUが十分高速になったらクロックダウンで安定させる！」と誓った事を突然思い出した。

---------------------------------------
ふと見るとそこにRyzen 7950Xがある、これは「十分高速なCPU」である。

Socket7以降のマザーではCPUを弄れないようにCPU自動検出が搭載され、クロックアップにはサードパーティ製の設定ツールが必要になった。それでも変更できないマザーがあったり、CPU側でブロックしている場合もある。

　　2024.09.19 追記：自作ユーザーの「もっと自由に！」の
　　後始末をするのに、メーカー側が手を焼いていた時期があり、
　　私の感覚、判断では
　　　　× 自動検出が搭載された結果CPUが弄れなくなった
　　　　○ CPUが弄れないように自動検出を搭載した
　　である。自作初心者でも手を出し易くなった側面も確かに
　　あるが、それは副次的な物で「好き勝手すんな！」が主因と
　　今も信ずる。

　　また、上位下位のCPUが実際には同製品で、難ありで安価な
　　普及CPUとしたものをテストに合格した高価な高速CPUと同じ
　　速度で動かされては困る、もあったと思う。
　　メーカーの厳密なテストで不合格になっていても、実用上は
　　許容範囲内で使える場合も結構あり、ハックトリビアが盛んに
　　やりとりされていた。

調べてみるとRyzenは、なんと出荷時のデフォルトが全ブロック解除で、個々人の要求にあわせ自由にセットアップして使おう！とAMD純正公認の設定ツール「Ryzen-Master」が提供されている。もっとも使用時にCPUの保証は切れるっぽいが (^_^;)

> https://www.amd.com/ja/products/software/ryzen-master.html

私にその知識があるかは疑問だが、クロックアップができるならダウンもできるはず、と早速ダウンロード。
好都合な事に、詳細な手動設定が可能なManual Modeに加えて、Eco Mode（アンダークロック）／Default（マザーの既定値）／Auto OC（自動オーバークロック）の3モードがありワンクリックで設定可能、経験知識の欠如でCPUを壊してしまう心配もない（この簡単設定モード使用の場合は保証は切れない説あり）。

さっそくテストする。

　　15分の4K動画書出し
　　--------------------------------------------
　　Default　　73°　125W　　　　30分
　　Auto OC　 77°　140W　　　　30分
　　Eco Mode　60°　100W　　　　40分

Auto OCが電気食うだけの役立たずでガッカリだが、AMDよりマザー（Asus）のセッティングが勝っているのか、GeForce併用の作業に向いていないのか、何れにしてもAuto OCを私が使うメリットはない。

Eco Modeは確かに省エネ設定であり、かつ通常操作では感触にまったく変化を認めず、ファン唸りが（エンコード中でも！）しなくなった。ファンの回転が上がらないなら、多分水冷ポンプも回っておらず、マシン可動系部品の消耗を抑える効果もありそう、かつ電圧が低いならシリコン系部品の寿命も伸びるはず。また、Defaultでも十分に安定しているが、Eco Modeにすることでさらに安定したに違いないと信ずる。

と言うことで通常はEco Mode、エンコード時のみDefaultと使い分ける事にした。これがワンクリック（＋再起動）で変更できるのは便利 (^_^)/

この様に25年の時を越え私の誓いは果たされた、File Closed.
[1703] Re:[1702] amdk6updのトリビア 投稿者：Mariya YAMADA 投稿日：2024/09/05(Thu) 13:19: 当時「さすがAMD、速すぎてエラーを出す」とか「WintelがK6狙い撃ちで潰そうとしている」とか、話題でした。

amdk6upd、懐かしいですが、なぜか我家のK6-2／550とIII／450はWindows95でも98でも発症しませんでした。修正パッチ使ってみたかったのですが、出番はなし、原因は今も謎です。

> https://www.os2museum.com/wp/those-win9x-crashes-on-fast-machines/

今でも9xを動かす方↑は結構いる（エミュレータ？）ようですが、Intelでトラブって「よしamdk6upd.exeを当てよう」とは普通思わないので、底なし沼に沈んでしまいそうです。
先の事を考えるなら「もっと別の相応しい名称」があった気がしますが、そもそも現世代は「高速CPU修正パッチ／amdk6upd」を知らないと言う可能性も・・・

そうした世代にとって「時代おくれ／Windows95と必須パッチの確保」は有用なページであり、それだけでも「時代おくれ」には意味がある、と手前味噌で話をまとめます (^_^;)

---------------------------------------
> 現在はIntelのCPUでも同様の不具合が起きるようです。
「Windows95と必須パッチの確保／amdk6upd.exe」に情報を追加しました。6年ぶりの更新です (^_^;;)
[1702] amdk6updのトリビア 投稿者：maekawa 投稿日：2024/09/04(Wed) 14:53: https://www.os2museum.com/wp/those-win9x-crashes-on-fast-machines/
たまたま見つけたのですが、Windows 95のパッチのamdk6upd.exeは実際にはK6用ではなく、不具合が起きるx86のLOOP命令を高速に実行する設計になっていたCPUが当時はK6しかなかったというのが実際で、現在はIntelのCPUでも同様の不具合が起きるようです。
[1701] 雷神、起動セズ・・・（未完） 投稿者：Mariya YAMADA 投稿日：2024/08/29(Thu) 13:22: 今回のデュアル環境破壊の根源はSecure Boot、これまで気にしたことはなかった（有効になっているPCが手元になかった ^_^;）のだが、そろそろ避けて通るのが難しそうなので、今後のために「私の理解」と「都合の良い思い込み」で一通りまとめてみる。

気が付いたらかなり長かった、長文御免 m(_ _)m

> Secure Bootとは------------------
Secure Bootはホワイトリスト的情報とモジュールの電子署名から、改竄されたモジュールや非許可モジュールを起動時に制限し、OS起動前のセキュリティを担保する仕組み。

　　Windows3.1～9xの頃はcommand.com／win.comのリネームや
　　削除で、OSを起動不能にする悪ふざけ的ウイルスが結構あった。
　　今現在もSecure Bootで守らねばならないほど、起動モジュールを
　　狙った攻撃というのはあるんだろうか？
　　疑問、私は経験がない。まぁウイルスやマルウェア全般に未経験
　　だが・・・

UEFI（Unified Extensible Firmware Interface）とSecure Bootはほぼ「＝　イコール」であり、独立したSecure Bootが存在するわけではない。オプションでUEFIブートローダーのセキュリティを強化した状態が「Secure Boot有効」となる。

Secure Bootは技術的にはそれなりに機能しているが、運用体制に諸々の問題を抱えており、最大の問題は任意立候補の11社を中心とする業界団体で管理されていること。

　　幹事11企業：AMD、American Megatrends、Apple、Dell、
　　Hewlett-Packard Company（HP）、IBM、Insyde Software、
　　Intel、Lenovo、Microsoft、Phoenix Technologies
　　この他に協力18企業、賛同123企業

　　ハードウェアに関わる錚々たるメンバーであるが、その本音は
　「PC買ったら大人しく有難く購入時のままWindows（やOS X）を
　　使ってろ！」だと思う。

現状は特定の民間営利企業が「PCで起動して良いOSを決める」と言う極めて宜しくない状態となっている。本人たちも独禁法抵触は警戒しているっぽい。

Microsoftは実費で電子署名を行うサービスを提供しているが、体力のない小コミュニティやそれこそ個人でOSや起動パッチの開発を行っている場合には、実費であっても確実にハードルとなり電子署名が取得できずSecure Boot非対応となる場合が予想される。
当然だがSecure Boot以前のOS（Windowsなら7以前）は電子署名を持っておらず、デフォルトがSecure Boot有効の新しいPCでは設定を変更しないと古い環境を起動できない。

現時点ではオプションでUEFI／Secure Bootの有効・無効が選択できるので、特別な目的状況で起動したい場合は（その知識があれば）「無効」にすればよい。しかし、管理する側からすれば「選択不可／有効固定」の方が面倒が少ないので、将来的にそうなる可能性も否定できない（CSMが駆逐されつつあるように）。
起動トラブル発生時に必要となる修復のための特殊起動はできません、再インストールすれば治ります、買換えでも問題解決できますよ、と・・・(~_~)

　　現時点の自分的な謎
　「ホワイトリスト的もの」の動作原理不明。単純なリストではなく
　　リストの情報と電子署名からスコアを求め判断すると言う。
　　バージョンとかパッチ適用の有無などの揺らぎを吸収する仕組だと
　　思うが、具体的な手法はまったく思い浮かばず（私が思い付く
　　レベルでは瞬殺ハックだと思うが ^_^;)。

　　その「リスト／情報の保管場所」がマザー上なのか？ディスクの
　　起動領域なのか？はっきりした情報見当たらず。
　　確かにリストの場所や詳細な構造動作を広く周知したら、すぐに
　　改竄ツールが作られる気はする、もうあるかもしれない。使用者の
　　判断で例外が追加できる（リストの編集ができる）と便利なんだが、
　　確実にそれは「穴」になるだろう。

　　2024.08.31 追記：理解できれば (^_^;) 役に立つ情報
> 　Ubuntu22.04 GRUBのカスタマイズ mkimage編
> 　https://rohhie.net/ubuntu22-04-customizing-grub-mkimage/
　　本日の雷神様：sbat,1,2022052400　grub,2（呪文？）

> 今回のデュアル環境破壊の原因 ---------
個人デスクトップにLinuxを使うユーザーにとって、そのメリットは「安い（原則無料）」「要求マシンスペックが低い」そして「堅牢性」の三つだと思う。この堅牢性には単にフリーズしにくいだけでなく「高安全性」も暗黙の了解として含まれる。

私のようなよく分っていない下々のLinuxユーザーはLinuxコミュニティを信頼し、その受売りでLinuxの安全性は高いと思って（信じて？願って？）使っている場合がほとんどだと思う。そうしたユーザーはLinuxのデフォルトを疑うことも変えることもしない、私も特別な事情がない限りインストーラ様のデフォルト値には逆らわない。

Windowsに後付けでLinuxをインストールすると、デフォルトではディスク先頭の全体の起動領域にgrubが配置され、Linux主体のデュアルブート構成となる。現在のgrubの主流は2.x系統、俗にいうgrub2でDebianの場合は2019年の10／Busterでセキュアブートに対応（grubの電子署名を取得）している。

grubは非常に柔軟かつ強力なブートローダー、起動時に詳細なパラメータが利用可能でトラブル復旧時にそれは有効である。そして起動イメージを（ネット経由で）パラメータとして与えることでインストールされていないOSも起動可能という超優れモノである。

　　確かに意志に反してこれやられたらコワイかも。

しかし困ったことにgrubは2020年にセキュリティ上の問題が指摘され、各コミュニティで修正が行われているが、4年弱が経過してまだセキュリティホールが残っているとされる。

それに業を煮やしたMicrosoftはWindows単独環境を対象に、grub系の古いローダー禁止にしてSBATをアップデート、それが判定失敗でデュアル／マルチ環境にも適用されてしまった、それが今回のディユアル環境破壊の原因、真相かと。

Microsoftの環境判定失敗は十分な技術力のある企業として恥であり、責任問題であるが、そこに至るまでの4年間のLinuxコミュニティ側の対応にも問題があったのではないかと想像する。少なくとも十分な対話や調整は行われておらず、結果、MicrosoftがSBAT強行アップデートの暴挙「もう待てません！」となったのかな？と。

　　Microsoftにも言い分はあると思うが、Windows単独環境に
　　grub禁止を設定しても特に誰かの安全には繋がらない気がする。
　　そのPCにデュアルでLinuxを導入したとき初めて「導入を
　　失敗させるトラップ」として機能するのではないかと。コレガ
　　モクテキ　ナラ　サイテイ (~_~)

> 何をもって今回のデュアル環境破壊問題の解決とするか？
直ちにSecure Bootを無効にして存在を永久に忘れる、これも（かなり有力な ^_^;）選択肢ではあるが「解決ではない」ので除外する。

今回の問題の「完」は「Windows／Linuxデュアルが、最新SBATを反映したSecure Boot環境で起動すること」で、そのために必要なLinuxコミュニティ・ユーザー側の対応として
　　(1) grubの穴を完全に塞ぎSecure Bootの禁止から除外させる
　　(2) 構造機能的にgrubの修正が困難なら「別ローダー」に変更する
　　(3) 潔くWindows Boot Managerの配下にインストールする
　　が考えられる。

4年かかってgrubの修正が完了しないのは、機能そのものが問題視されているのかなと。grubに改竄がなければSecure Bootにパスするが、それに悪意を持ったパラメータが与えられていたらSecure Bootの意味がなくなる。
Linux側がgrubの特徴である柔軟な起動に拘るなら、機能が制限された別ローダーには移れないし、Microsoft他との調整も難しそう。

(3)は現時点でも可能であるが、手作業になり若干手間がかかる。それをインストール時のオプションに加えて選ばせるのは、結構現実的な解決策な気がする。少なくともSecure Boot保護を優先するユーザーの選択肢としてアリだと思う。

まぁ個人的にはgrub経由でWindowsを起動するとき「主はLinux、お前はオマケなんだよ！」と変な優越感的な高揚感的なナニカがある。逆にLinuxがWindows Boot Managerの配下になるのは気分が悪いな、と思わんでもない (^_^;)

結論：この問題、先が長そうなので今回は「未完」で棚上げとする。

> -------------------------------------
以前（20年以上前 ^_^;）はPCの数も限られエミュレータを快適に動かすスペックもなく、デュアル／マルチブートには意味があり、利用するユーザーも多かったように思う。しかし、PCも十分に普及しゴロゴロとありエミュレータを稼働する余裕のスペックもあり、デュアル／マルチ環境で複数OSを動かすメリットは失われ、ユーザーもかなり少ないらしい。

　　私は「エミュレータは偽物である」の信念に基づき、本物を
　　起動できるデュアル／マルチ環境にかなり拘っている。要は
　　イマドキノヒトではないもので (^_^;)

困っているユーザーが少ない問題に対して、LinuxコミュニティもMicrosoft（他）も頑張らない気がする。障害発生を告知して「デュアル／マルチは止めようね」で終了～！って可能性も・・・その場合は「永遠に未完」のまま「棚の上で朽ち果てる」ことになる。
まぁ我家の主力Athlon君には関係のない話題であり、それで特に困る事はないんだが (^_^;)

[1] [2] [3] [4] [5] [6] [7] [8]

- LightBoard -