Flow Control System

客人逐漸把產品的散熱從氣冷轉到水冷，至少在我們家的案子是這樣。也許為了省電，氣冷太太占空間，所以改採水冷，可以把正在逐間增加的系統高度，又壓回 1OU 或是 2OU。這樣一台機櫃又可以放更多的系統了。只是，水冷也要做 TIM Reliability Test。 之前，因為其他客人的專案，購買了某家的水冷交換器，冷水供應器。但是....好像不是很好用....在流量很低的時候，表頭並無法顯示流量。於是，客人為了方便我們測試 TIM Rel. Test，於是寄了三台 Flow Control System 給我們。只是，這三台 FloW Control System 的設定頗為複雜，很多東西搞不清楚，本來原始設定就有問題，後來試玩，就....玩出更多問題。不過，這系統倒是不錯的 Flow Control System。 這 Flow Control System 總共有五個部件所組成，電源供應單元，兩個溫度感應器，兩個壓力感應器，一個控制閥，一個流量計，以及一個叫 Gateway 的東西。除了流量計，壓力感應器，溫度感應器和控制閥，都把訊號連接到 Gateway，而 Gateway 可以透過網路，讓其他電腦連接。但是，這 Flow Control System 必須透過專用的 USB Stick 連到 Gateway 去修改設定。整個架構大致上是這些單元。 但是每種單元內，都可以做一些設定，尤其是控制閥與 Gateway，裡面的設定更是多樣。尤其是 Gateway，裡面的設定包含外部如何跟這台 Gateway 溝通，可以採用多種協議。只是，由於 TIM Rel. Test 要做長時間的測試，以及都是在 Linux 環境下，對測試系統的家壓控制，以及 Sensor 讀值的紀錄，所以，要開啟 Gateway 的網路協議的部分。幸虧，在白嫖 Claude 的協助下，已經可以透過網路，對這 Flow Contrl System 下達指令，以及讀取相關壓力，溫度，流量與閥門開度的這些讀值。 設定這系統，最主要的部份，是要建構感應器，控制閥，Gateway 間的連接網路。外部主要是透過 USB 或是網路連到 Gateway，並且，前文提到，除了流量計，都會連接到 Gateway，所以，只要正確定義這些元件對 Gateway 的輸入，以及 Gateway 會輸出給哪個元件，以及單位設定正確，期寄上幾乎就可以使用了。 只是下一個難題是，如何讓 CPU 的溫度直接自己去控制閥門的開度，是下一個階段要克服的問題。

[NVIDIA V100] 高不成低不就的 V100 32G

話說，年紀大了腦子變得不好，再加上變得愈來愈懶，再再加上 AI 似乎很好用，雖然常常胡說八道一通，但用寫一些 Code，似乎還蠻好用的。只是，目前即是付費翻案，大概 Gemini 可以吃到吐之外，其他 ChatGPT 和 Claude 都段時間重置，也許是我沒用得很好，浪費太多 Token。所以，把歪腦筋動到了，乾脆自己弄一個 Local 的 AI，還好系統裡有兩張 GPU，A4000/16G 與 A2000/12G，A2000/12G 已經 DDA 給 Guest OS 了，所以先在 A4000 上試了一下，效果不是很好。主要問題在於模型。A4000 只有 16G VRAM，再加上要保留一些空間給長對話，所以可以塞入的模型大小就受限，如果 VRAM 空間不足，就動用到系統的記憶體，但只要動用到系統的記憶體，那麼速度會慢到吐血。關於這些相關的資訊，相信大家可以在網路上找到，這裡不多說。直接說 V100/32G。 為了塞入更大的模型，所以去查了一下 GPU，乖乖....VRAM 大的顯示卡可不是打工仔所能負擔得起的，好一點的已經是半部汽車的價錢。所以，老規矩，去淘寶找看看。搜尋來搜尋去，口袋勉強負擔得起只剩下 V100 了。V100 可真是道道地地給 Data Center 用的 GPU，沒有影像輸出的接口。當初想說，反正只是塞了個 Model 在裡面，我還有 A4000 和 A2000 可以輸出，應該不是太大問題，所以就從淘寶買了 V100/32G (64G (32Gx2)買不起)，外加個顯卡塢.... 剛拿到 V100 的時候，沒啥時間搞，前陣子有點時間，開始建立的時候....就是災難開始....為何是災難，我先說說我當初的想法。V100 用來替換 A2000/12G，依需要在 Host OS 當作 AI 模型的代理，如果 Guest OS 需要，則 DDA 給 Guest OS。當然，V100 在 Host OS 中，還有其他用途。總之，在我當初的規劃下，遇到的問題如下。 1. V4000 是新世代的顯示卡，V100 是舊世代的顯示卡。安裝完驅動程式後，Win Server 2019 下，A4000 是 WDDM 模式，V100 是 TCC 模式。 2. Ollama 無法將 模型放入 TCC 模式的 V100，每次都會放入 A4000。如果放不進 V100，那購買 V100 就失去了意義。 3. 把模型放入 V100 跑起來，要自己編譯 llama，而 V100 是舊的晶片，要找可以搭配的 CUDA Toolkit 版本。 4. 把 V100 DDA 給 Guest OS (Win10 Pro) 後，還是 TCC 模式，V100 的 OpenGL 無法使用....吐血。要變成 WDDM 模式，才能發揮其 OpenGL 的功效。網路上常看到的解法是安裝較舊版本的驅動程式，外加修改註冊表。但是，當每次把 V100 還給 Host 後，再重新 DDA 給 Guest OS，那麼得重來一次。如果要使用 WDDM 模式，得去 NVIDIA 申請啥 License，反正就是特殊的 License。不僅要錢，而且個人可能也無法申請。我沒申請試用。但目前最好的解法是，去網路上找非官方的驅動程式，好像是直接注入 Grid/vGPU，讓 V100 直接變成 WDDM 模式。目前，我的 Guest OS 就是用這種方式，使用 V100 的 OpenGL，CAD 看圖沒問題，GPU 運算還沒試。但這包非官方的驅動程式打在 Server 2019 上，我的 A4000 就變成基本顯卡，也就是說，A4000 無法使用這非官方的 (Grid/vGPU) 驅動程式。如果驅動 A4000，那麼 V100 又變成 TCC 模式。看來，A4000 與 V100 的 WDDM 是魚與熊掌，不過，讓 A4000 正常啟用，V100 至少能正常驅動，所以，Host OS 下，仍舊採用官方驅動程式。除非，把 A4000 換成 AMD 或其他的顯卡。 大概就這些雷了....

[Gemini] 對於編寫腳本，Google 的 Gemini 大概是最垃圾的 AI 協助者

最近，用 Gemini 來開發一些 TIM Reliability Test 的測試結果的後處理腳本，畢竟，資料量太大，不可能用人工處理。所以，陸續開發了一歇腳本。使用的語言是 MATLAB。說實話，MATLAB 我也不會，只要 Gemini 會就可以了。但這種想法，會有額外的問題產生，這留待後續再說明吧.... 在剛開始時，我並沒有訂閱任何 AI，全部都是白嫖免費額度。其中，ChatGPT 是白嫖最多的，其次是 Claude，Gemini 最少，Copilot 則幾乎沒有。白嫖時期，ChatGPT 大概可以讓我免斐使用的額度(不知道是不是算 Token)最多，其次是 Claude，Gemini 則是最低。所以，這也造成我當時的偏好。ChatGPT 幾乎完成我最早期的腳本，光是白嫖，就足夠完成。以當時的狀況來說，對 ChatGPT 的表現最滿意，所以，先做了一個月的訂閱。只是，似乎收了錢之後就開始擺爛，感覺愈來愈差，一個月後，就沒有繼續訂閱了。只是，時常有 Linux shell 腳本的需求，測試資料後處理的需求，所以又轉向 Claude，Claude 在程式的表現上，給我的感覺是最佳的。只是，即使是付費使用，使用額度仍舊一下就北我搞光了，一個完整的腳本，會拖上好久的時間，所以一個月後，也沒有繼續訂閱。之後，又開始靠著白嫖過活，好在，靠著之前的腳本，稍微修改，就可以繼續騙吃騙喝。直到....Gemini 幾乎對折優惠....想說，家人也可以用，所以就訂閱了。但惡夢即將開始.... 如果要驗證便宜無好貨，Gemini 如果稱第二，應該沒有人敢稱第一了。這傢伙跟詐騙集團沒兩樣。前幾天已經開始胡言亂語(Gemini 胡言亂語)，今天已經開始罵髒話了(我直接對 Gemini 罵髒話)，除了我之外，不知道有沒有人對 Gemini 罵髒話? 我先來總結我目前發現 Gemini 的缺點，各位先去查看看，我是否說的是真的，再決定要不要訂閱 Gemini，擬就當我在黑 Gemini 也可以。我認為 Gemini 非常大的問題如下: 1. Gemini 有一個地方可以設定 使用者對 Gemini 的指令。我實際上，不知道有這功能，還是 Gemini 跟我說有這功能的。但這功能說實在，幾乎不起作用，說穿了，你只能當 Gemini 的記憶功能，對你的指令，幾乎沒有任何作用。相信如果這幾天有看到我 Facebook 上的截圖，應該都相信我沒有在黑他。 2. Gemini 屢次違反使用者命令。第一點說到，即使你在 使用者對 Gemini 的指令 中，指示 Gemini 應該要如何做，抱歉，除了可以幫她記憶的敘述外，對你對他下的命令毫無用處。這也造成無論你如何下命令，他的 LLM 模型的設定，永遠高於你的命令，這就造成他我行我素的行為。 3. 金魚腦，不要懷疑。不用多久，他會忘了你所說的。如果你早上開了一個新的對話框，或者說是對話串，打算處理某個腳本。抱歉，大概到了中午就無法回憶之前的腳本。Gemini 目前有非常非常嚴重的記憶斷層。很多使用者都有遇到，可以去 APP 一顆星評論看看。這對於開發較為龐大的腳本而言，上午做的，下午忘了。你只好重來一次。 4. 嗑藥。Gemini 的幻覺非常嚴重，而且會隱藏真相，讓你園地打轉。搭配她的金魚腦，實際上，他已經忘了 Code 應該是如何，但她不會跟你老實說，他會跟你東拉西扯，胡說八道一通，直到被你抓包，然後承認他錯了。但是，配合他的金魚腦，不用多久，你就可以繼續感受它的威力。他的幻覺，絕對可以把你逼瘋。 5. 差勁的邏輯能力。這堆於腳本的修改與最佳化時，絕對讓你一槍斃命。即使一個簡短的腳本，他也可以弄錯。前幾天，我才叫他把我指令精簡一下，結果他變動程式的邏輯，讓個程式流程不正確，會造成我的測試交本在測試時失去保護的功能。這老兄說，使用者要做最後的確認，他還可以貼出 Google Gemini 的免責聲明。我想，前幾天有看我 FB 的，應該也有看到我貼的截圖吧。 這幾項問題，對於開發腳本，變得非常非常不友善。以今天為例，今天預計修正我一個小 bug 與新增兩個功能，新增兩個功能，實際上應該只能算新增 1.2 個新功能而已。我通常為了維護方便，把整個程式腳本切成不同的模塊，哪個模塊出問題，就修理哪個模塊。前幾天，我把三個目標相同，但方式不同的的程式，整合成一個程式，結果花了兩天才整合完成。困難度有多少? A 程式為 Main_A, Step01_A, Step02_A, B 程式為 Main_B, Step01_B, Step02_B, C 程式為 Main_C, Step01_C, Step02_C，我要整合成，Main_D, Step01_D, Step02_D, Step03_A, Step03_B。簡單說，Main 是主要控制，Step01 示讀取資料，Step02 是不同的演算法，而 D 只是把原來的演算法放到 Step02, Step03_A, Step03_B，然後在 Main 用選單，選擇我要用哪個演算法處理。原本三個 Main 的相似度就非常高，Step01 也非常高，演算法就直接複製，原來個別的演算法。就僅僅這樣，花了兩天的時間....真是無言.... 以下，將會不定時更新截圖....

TIM Reliability Test

好久好久沒發布文章了，主要是因為在忙 TIM Reliability Test 相關的事情。一開始非常不順，客人加壓程式還沒驗證就丟過來，搞得我好像是在做軟體驗證的。接著，在其他單位的協助下，完成第一個版本的測試腳本。但那單位擺明就是腳本給你了，後續如果要修改，就自己想辦法。但客人卻認為，那是你們自己的問題，你們自己去溝通，搞得我兩面不是人。所以花了許多心力在更新腳本，以及還要做後處理的腳本。事情一多，就懶得寫文章了。 實際已經跑過兩輪的 TIM Reliability Test 的測試，在針對下一個專案所要用的腳本，參考之前遇到的問題，以及對一些重新定義，整個腳本的流程大致如下。

整個測試由兩個腳本構成，一個是負責主要的測試，另一個是由主程式呼叫執行的 Sensor Log 的腳本。其實，Sensor Log 也可以放進主程式，但只是覺得 Sensor Log 常修改，乾脆獨立出來，也可以作為一般測試使用。 不過，客人也沒跟我說 Criteria 是多少，所以，我就將數據整理給客戶，讓他們自己去看吧。後處理的部分，就留待有空再聊，以及湊湊版面吧....

[快訊] FloTHERM 2410.0 已發布....

ㄜ....我是指大家期待的版本。(XT 還不見蹤影)