我之前劃了一個 300MB 的 partition,沒記錯的話用 Gutmann method 也要兩分多鐘(我的速度顯示為 2.2Mb/s 左右,比教授的快一點點)。
Disk Wipe 對 Gutmann Method 的標註是 「extremely slow」。想像中可能真的龜速會比較接近原作者的描述 :D:D:D
可列印查看
我之前劃了一個 300MB 的 partition,沒記錯的話用 Gutmann method 也要兩分多鐘(我的速度顯示為 2.2Mb/s 左右,比教授的快一點點)。
Disk Wipe 對 Gutmann Method 的標註是 「extremely slow」。想像中可能真的龜速會比較接近原作者的描述 :D:D:D
我是猜想:gangster.tank 的 GUT 非常明確地保證加強供電可以讓 GUT更有力,所以我會只相信經過 USB HUB 與 1500W 的外接硬碟,內接硬碟就沒有試過了。至於要不要發瘋再加上三個大電容還在苦惱中,苦惱的理由很欠扁:再加上三個大電容,獨孤救敗更不可能了!!
我看到 sam0402你們講的速度也嚇了一跳:那有可能麼快?話說在我的電腦,同樣大小的外接硬碟分割區,WIPE成FAT速度慢到只有 1.7M/sec;WIPE成NTSC速度快到近40M/S;然後WIPE成NTSC當然無效.......
所以我大膽猜測速度差2.0M/S太多的(太快的),應該都有問題?.....(giggle) (blush)
後續補充:改內接速度快到60M/S,在電腦本身1500W的情況下,WIPE個10次就可以扺得上USB外接了!所以我都改成內接了。
早上醒來,改變主意了。記憶體的硬體性能應該獨立看待;讓 JPlay 在 RAM Disk 上運作則是不同的考量。記得 sam 大好像提過用 RAM Disk 跑他寫的 ArchQ,聲音不甚滿意?但目前看起來, 若想再提升 JPlay 的表現,除了電腦性能繼續提高外,唯一沒試過而可能讓速度、延遲等客觀性能大幅提升的,大概就是用 RAM disk 載入作業系統。
JPlay 討論區上與此相關的 Win11PE 主題已經出現快一年了。那個討論串剛開始的時候完全沒提到跑 JPlay;那時候我的 JPlay dual PC 有很多問題待解決,不敢多想,就沒再 follow。最近偶然看到那裡已經出現跑 JPlay 的討論,該仔細讀一下了。版上先進若在這方面已有經驗,還請多多分享 (clapping)(clapping)(clapping)
基本上來說,把所有 C:\JPLAY 的 registry keys 改為 X:\JPLAY 該是比較折衷的方法,反正已經有成功的例子,但是小弟不知道 JPLAY 的 activation 狀況會怎麼樣,因為只要更換了 HDD/SSD 也需要再跑一次 C:\JPLAY\TurboActivate.exe,而 Win11PE 則分為 RAM Boot/Flat Boot/USB Boot 這幾種方式,或許最後的那一種比較簡單,但是小弟沒有試過:
http://jplay.eu/forum/index.php?/top...clean/?p=60163另外 internethandle 兄建議使用 Registry Workshop:引用:
Then, I opened up regedit and searched for "JPLAY" with CTRL+F, and used F3 to cycle through all of the results. I changed every instance of C:\JPLAY to X:\JPLAY, except a few. The ones I didn't change were the ones relating to the Start Menu, the Compatibility Assistant ones that are in binary format, and the ones that don't have a drive letter (e.g. "\Device\HarddiskVolume3\JPLAY\JPLAYSettings.exe") that are also in binary format. Everything else I changed. There are filepaths that show up multiple times, like "c:\jplay\jplaydriver64.dll", but I found that after you change one the first time, the repeats get changed automatically. This process of editing the registry only takes 5 minutes or so.
http://jplay.eu/forum/index.php?/top...guide/?p=57758引用:
In my case, I found this too cumbersome, and simply would use another Registry editing program in my host OS (where my VHD’s were all located) such as Registry Workshop (but you could even just use normal Regedit) to load the hives from the mounted VHD in system32\config, make edits, and then unload the hive.
那一位 Dev 網兄相當「風趣幽默」,這邊廂說修改 JPLAY 所屬的 registry keys 就會顯得 messy 云云,那邊廂就問如何修改 Win11PE 所屬的 registry keys(將全部 X: 改為 C:),然後就天曉得他選擇了甚麼方法。
很久以前已經說了那是 hard-coded,隨便搜尋 Win11PE 的 registry hives 也可以找到成千上萬的 X: 例子:
https://web.archive.org/web/20110203....com/kb/892846
僅僅修改個別的 registry keys,真的不知道會變得怎麼樣了:
https://msfn.org/board/topic/155495-...comment-990098
https://msfn.org/board/topic/149173-...comment-951669
並非說 Registry Workshop 那種 Find and Replace 不可行,只是說小弟已經放棄了那種途徑。
Win11PE 還有很多可以優化之處,例如:
- 刪除/重新命名資料夾
- 刪除/重新命名檔案
- 刪除/修改 Registry
- 刪除 Services
- 用 Process Hacker 或 System Informer 卸載 modules
- 用 PsTools 的 PsKill 或 PsSuspend 減少 processes 的數量
- 用 CBSEnum(免費)或 NTLite (收費)刪除 Components 或其他元件
大致上就是參考 Chanh/internethandle/keith_correa/samotc 或其他網兄分享的方法就不錯了,資料太多,不能盡錄。
Chanh 兄的「三合一」系統比較有趣,Roon Core 2.0 不知道是跑 Linux 還是 Windows,假設那是 Linux 吧。
HQPlayer 4 Embedded 就明顯是 Linux,而 NAA 就當然是 Win11PE 加上 Accuphase 的 ASIO driver。
假如 UPnP Media Server(Control PC)由原來的 JPLAY 改為 sam0402 兄的 ArchQ 會不會變得更好聽呢?
https://aur.archlinux.org/packages?K=upnp&SB=p
seeteeyou 大在那個討論串是主要貢獻者之一 (clapping)(clapping)(clapping)(在JPlay 討論區和其他很多發燒討論區也是 key contributor)。我目前跳著爬文剛看到第14頁,seeteeyou 大提到微軟的 Factory OS iso 裡面也有 64bit version 的 WinPE.wim。
除了跑 JPlay 之外,另一個挑戰就是讓 DT2(我覺得 DT2 的聲音真的非常理想)跑 Kernel Streaming (KS) mode。
如果能得到一樣好的聲音,我一定率先棄用 JPlay。最近幾個晚上試了分別用 M10、M15 和 900P 三款 Optane 和 NTFS、exFAT、ReFS 等不同檔案格式的組合當系統碟,作業系統也從 Windows Server 2022 Standard 改成 Windows Server 2022 Datacenter,其間受盡 JPlay 的啟用機制折磨。改用舊版的 JPlay 6.x (我沒用過)是不是可以避開現在版本的啟用機制呢?
我的短期聽覺記憶不夠好,而且從教授提出 GUT 開始,我的電腦數位訊源經歷許多調整改變,所以沒辦法排除所有變項去判斷 GUT 對系統進一步 run in 的效果。只能說從實施 GUT 以來,好像什麼音樂都變得更好聽了。很愛聽的那張 Racha Arodaky 彈孟德爾頌無言歌,聲音從來沒那麼好過(這不是雜誌評論的老梗嗎 :D:D:D)
終於把 JPlay 討論區那個 WinPE 討論串粗略看過一遍,尤其是最後幾頁。現在比較了解 seeteeyou 大的意思了。
時間寶貴。未來就務實一點,分四路進行:
1)JPlay:我看還是照 gangster.tank 上面提到的,以 GUT 加持就好;頂多用 RamOS 試試看。硬想要裝在極度精簡的 WinPE 上跑,最終可能只是浪費時間 (加上 License Expired... (angry)(angry)(angry):D:D:D)
2)ArchQ:sam 大的極致 Linux 播放系統,可能已經超越 JPlay。不知道版上有沒有人配合 DT2 用過?
3)HQPlayer,加 WinPE 當NAA:那位 Chanh 兄的 WinPE 精簡到只剩七個程序在跑 (clapping)(clapping)(clapping)。這個應該有機會用 DT2 KS mode。
4)PureAsioPlayer (PAP):待進一步調查......
也要留意一下 Diretta 這個介面。
關於拷貝檔案的方式,主要分為兩大種類:
https://github.com/EighteenZi/rocksd...d#introductionWindows 還有兩種也不是的第三類:引用:
Direct I/O is a system-wide feature that supports direct reads/writes from/to storage device to/from user memory space bypassing system page cache. Buffered I/O is usually the default I/O mode enabled by most operating systems.
https://learn.microsoft.com/zh-tw/wi...g-data-buffers
https://github.com/MicrosoftDocs/win...g-data-buffers
很久以前曾經有樂友說 FastCopy 的那種 Direct I/O 比較好聽,效果如何則耳聽爲憑了:
https://fastcopy.jp/archive/FastCopy4.2.1_x64.zip
https://portableapps.com/apps/utilit...tcopy-portable
重複拷貝數十或數百次之話就當然是使用那個 fcp.exe:
https://fastcopy.jp/help/fastcopy_eng.htm#cmdline
https://topic.alibabacloud.com/a/fas..._31357058.html
白水 啓章さん的網站:
https://shirouzu.jp/profile
https://groups.google.com/g/fastcopy
https://github.com/FastCopyLab/FastCopy/issues
另外還有其他 Go 語言的資源,Linux 和 Windows 兩者也適用:
https://github.com/ncw/directio
https://github.com/brk0v/directio
https://github.com/eantcal/ioperm
https://www.cnblogs.com/muahao/p/7903230.html
https://www.oreilly.com/library/view...2/ch16s03.html
基本上 hdparm 亦提供類似的選項,但是它的功用跟拷貝檔案沒有甚麼關係:
https://man7.org/linux/man-pages/man8/hdparm.8.html而另一選項則可以用來 wipe 指定的 sectors,不過好像是相當危險的說:代碼:--direct
Use the kernel´s "O_DIRECT" flag when performing a -t
timing test. This bypasses the page cache, causing the
reads to go directly from the drive into hdparm's buffers,
using so-called "raw" I/O. In many cases, this can
produce results that appear much faster than the usual
page cache method, giving a better indication of raw
device and driver performance.
Linux 和 Windows 的版本:代碼:--write-sector
Writes zeros to the specified sector number. VERY
DANGEROUS. The sector number must be given (base10) after
this option. hdparm will issue a low-level write
(completely bypassing the usual block layer read/write
mechanisms) to the specified sector. This can be used to
force a drive to repair a bad sector (media error).
https://archlinux.org/packages/core/x86_64/hdparm/
https://web.archive.org/web/20201019...attredirects=0
還有這個比較特別的軟件:
http://www.compulsivecode.com/Images/CopyInOrder.zip
http://www.compulsivecode.com/Project_CopyInOrder.aspx引用:
This is a program for copying files and folders in alphabetical order. Windows rarely copies files or folders in the order you would expect.
假如主機板能夠支援第二代或以上的 Xeon Scalable(例如 Xeon Silver 4215),Optane DCPMM(用來代替 RAM 的 Optane)還可以支援 DAX,可惜 Windows 只有 NTFS 能夠支援 DAX:
https://learn.microsoft.com/zh-tw/az...access-methods
https://github.com/MicrosoftDocs/azure-stack-docs/blob/main/azure-stack/hci/concepts/deploy-persistent-memory.md#access-methodsLinux 由核心版本 5.5 開始就支援 DAX:引用:
Direct access (DAX), which operates like memory to get the lowest latency. You can only use DAX in combination with NTFS. If you don't use DAX correctly, there is potential for data loss.
https://www.phoronix.com/news/Linux-5.5-HMEM-Driver
相關軟件如下:
https://github.com/pmem/ndctl
https://archlinux.org/packages/extra/x86_64/ndctl/
https://man.archlinux.org/man/extra/ndctl/daxctl.1.en
看來並非那麼簡單,而且一般 Optane 也不支援 DAX,非 DCPMM 版本不可:
https://tanelpoder.com/posts/testing...istent-memory/
https://www.intel.com/content/www/us...ning-pmem.html
Kernel Streaming 和其他資料就有待下回分解了。