Re: [閒聊] 電腦的分頁檔調音(?

看板Headphone作者 (Oswyn)時間4年前 (2019/07/19 00:58), 4年前編輯推噓9(9推 0噓 12→)
留言21則, 7人參與, 4年前最新討論串2/2 (看更多)
: 推 louis0407 : 2048～2048是哪邊的推薦啊？ 很少看到講這個 07/17 09:10 2048 是個 magic 數字，有幾十年的歷史了吧，設成固定大小是更久遠的 95 時代就有 了。會定成 2048 固定大小也有磁碟對齊和避免檔案破碎降低效能的意思。因為虛擬記 憶體空間 page 大小一般也是 4 KB 所以只要是 4 的倍數就 OK。 32-bit Windows 的預設虛擬記憶體空間是 Low 2 GB for process (user-mode)、High 2 GB for System (kernel)。如果開啟 4GT 就變 Low 3 GB、High 1 GB。所以 32-bit Windows 的 Kernel Memory Dump 最大也是 2 GB。連 FAT16 檔案最大也是 2 GB。 很多與 Windows 記憶體相關的數據都會出現 2 GB 這個魔術數字，但好像沒看過官方 有任何聲明指出分頁檔設成 2 GB 會爆擊就是了。太大沒意義、小太不夠用，要設成 固定值就找個整數倍的比較舒服。 Windows XP RAM 小於 1 GB 時的最小預設分頁檔大小是 1.5 ×RAM； Windows XP RAM 大於 1 GB 和 Windows Vista & 7 的最小預設分頁檔是 1 ×RAM； Windows 10 的最小預設分頁檔是基於分頁檔的使用歷史； 預設最大分頁檔大小基本上是 3 ×RAM or 4 GB 取最大者、Windows 10 也略有不同， 與 crash dump 的需求在此忽略。 典型上建議分頁檔大小為 RAM 的 1.5 或 2 倍。一些 M$ Server Performance Tuning 課程或文件多半也會告訴你分頁檔大小至少要設為等於或大於實體 RAM 大小。這牽涉 到部分的程式或服務必需要有分頁檔，及 Windows 記憶體管理的記憶體回收問題。 Process 只能存取虛擬記憶體位置，其對應到實際記憶體位置時通常不會分配到連續的 頁面空間。虛擬地址空間也有因保留等與可能的碎片化問題。一般來說當實際使用與分 配的記憶體量很高時，分頁大小不足會導致更多的記憶體回收及更高的 CPU 使用率（ 處理記憶體分配問題）。 但隨著時代改變電腦上插的 RAM 更多了，或許用不完記憶體就沒這麼多問題了！？現 在基本上是擁有的 RAM 越多所需的分頁檔大小就越小，但這還是得看實際上使用的記 憶體大小依個案來決定。 近年的 M$ 的工程師有建議依實際使用狀況去設定，執行［效能監視器］主要針對 Memory \ Committed Bytes 以 weeks 為時間來觀察實際使用狀況找出最大值。一般個 人用不想這麼麻煩可以開［工作管理員］隨便觀察下瞬間值。 ［工作管理員］［效能］分頁中的［記憶體］頁面 ［使用中（已壓縮）］為實際分配使用中的大小，Win 10 會在 CPU 閒置時對 使用率低的記憶體分頁進行壓縮進一步減輕分頁檔需求 ［己認可］＝Committed Bytes ／ Committed Limit ［已快取］＝快取資料，其佔的空間可隨時依需求清出供使用 Memory\Committed Bytes＝已提交的虛擬記憶體量 Memory\Committed Limit＝在不擴張分頁檔下可提交的虛擬記憶體量＝RAM + Page File Memory\% Committed Bytes In Use＝上述兩值相除得出的使用率 ［使用中］與［已認可］的大小不相同主要還是要看已認可。［已認可］可簡單視為虛 擬記憶體總使用量。 在系統高負載尖峰狀態、高記憶體使用率下，也就是 Max Committed Bytes 值就是參 考點。如果電腦實際 RAM 的大小超過 Committed Bytes 最大值且有餘裕就不需要設定 太大的分頁檔，留有應付突發狀況的容量大小就可行。 但由於分頁檔大小對於記憶體管理效能有著一定的作用，且［可用的］記憶體容量也影 響到可供快取使用的大小。有充足的分頁檔容量系統就能將使用率低的記憶體分頁丟到 分頁檔。在磁碟性能、分頁檔大小還會影響 CPU 使用率、可快取容量等怎麼樣才是最 佳平衡不見得統統都設個 2048 就是最佳化就是了。 但不管怎設應該也不會在數位域直接影響到聲音就是了。硬碟進入省電、怠速這卡讀取 的會有嚴重的頓卡聲不會只是感受不同，且播放中的相關程序怎麼說也不太可能被丟到 分頁檔裏。有什麼影響的話多半也就是 CPU 使用率與磁碟機吃電不同的影響使電源迴 路、EMI/RF 雜訊造成的影響了吧。 就跟 Audio Latency 一樣，基本上低 Latency 會有更頻繁的 CPU 喚醒，除了 CPU 功 耗會更高，路上碰到紅燈跟撞車的機會只會更大。M$ 的 WASAPI 官方文件就聲明低 Latency 會讓發生 glitches 的風險更大。 如果真的在不同 Latency 有不同感受的話，至少希望使用 WASAPI 時 buffer 大小設 定為　0、1、2、3 ms 這些數字時是有著相同的感受，不然大概可能就只能說是心靈不 夠堅強了。 -- いざ舞い散れ桜咲いて　命のある限り参れ ^,,,^ 嗚呼、もう誰もいない　ふわり、風が凪いだ… (ミ‵ω′)\m/ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.230.210.90 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Headphone/M.1563469089.A.EC8.html
→
07/19 02:54, 4年前 , 1F
可以改用外部解碼器自己下指令強迫單執行序
07/19 02:54, 1F
推
07/19 10:29, 4年前 , 2F
就越低Latency越接近RTOS, 而音樂重播最理想就RTOS
07/19 10:29, 2F
→
07/19 10:30, 4年前 , 3F
但Windows本身就是離RTOS很遠的東西,硬改是有後果的
07/19 10:30, 3F
OS 最主要負責讀檔、解碼、傳送給 Audio Driver & Device 影響 Audio Latency 最主要在於各 Device Endpoint 間的 Audio data 傳送 Endpoint Buffer 大小形成 Latency，基本上在 OS 端不需要即時這是個誤解 Audio Playback 需要時脈精準的點在 DAC 輸出時，所以是在音效卡或者是外 部 DAC Device 上。良好的 Playback 期望在每個採樣點在正確的時間輸出， 只有在這部份需要像一個即時系統而非整台電腦與 OS，而正確時間的掌握在 於 DAC 上的時脈而非 OS 要滿足 DAC 能正確即時輸出需要餵飽 DAC 的 Buffer，其它部分需要的是保 障資料傳送的即時與精確而非實時 假如 Endpoint Buffer 是個輸送帶，需要保障料件在上面的供應不中斷 工人要一次搬運要移動多少份料件至輸送帶流程才會順暢？ 一次只搬一件拚命來回跑、或一次穩定的搬一定數量讓流程達到一個平衡 就因為不是 RTOS 所以才需要一次搬運一定的數量，而非只搬一個讓系統或硬 體事件更容易干擾到運行 另外、不管在 OS 端怎麼拼老命想趕上 RT，輸送帶那頭的 DAC 還是只會照自 己的時鐘依自己的步調運行，只有伸手時發現輸送帶上空了才會抱怨
推
07/20 10:56, 4年前 , 4F
Hihi 但我猜最大問題是那條輸送帶本身會忽快忽慢又
07/20 10:56, 4F
→
07/20 10:56, 4年前 , 5F
震來震去，所以才有人想把輸送帶儘量跳過，或著縮短
07/20 10:56, 5F
→
07/20 10:56, 4年前 , 6F
或著想辦法弄一條又快又穩的專用通道
07/20 10:56, 6F
推
07/20 10:58, 4年前 , 7F
實際上壓低latency只是一個環節，如果反而造成線路
07/20 10:58, 7F
→
07/20 10:58, 4年前 , 8F
噪訊上升 SI品質下滑(例如大幅超頻)，對最後的重播
07/20 10:58, 8F
→
07/20 10:58, 4年前 , 9F
也沒全面好處
07/20 10:58, 9F
推
07/20 11:00, 4年前 , 10F
至於你說的事件干擾，所有認真在玩CAT的人都會同意
07/20 11:00, 10F
→
07/20 11:00, 4年前 , 11F
，把系統岔斷減少是個很重要的原則，所以，只能說CA
07/20 11:00, 11F
→
07/20 11:00, 4年前 , 12F
T就是個追求特化的需求，跟一般OS的思考不太一樣
07/20 11:00, 12F
推
07/20 11:03, 4年前 , 13F
另外DAC雖然都有自己時鐘，但只要還有跟前端確認同
07/20 11:03, 13F
→
07/20 11:03, 4年前 , 14F
步的溝通在，就無法完全割斷前端的影響，否則asycho
07/20 11:03, 14F
→
07/20 11:03, 4年前 , 15F
us發展十年了，不會還有一堆人在搞前端
07/20 11:03, 15F
推
07/20 11:07, 4年前 , 16F
倒是國外論壇確實有完全割斷前端影響的套件，也就是
07/20 11:07, 16F
→
07/20 11:07, 4年前 , 17F
不同步的接收器套件，在diyaudio可以找到討論
07/20 11:07, 17F
就是因為傳送不穩定所以需要更寬容的時間＝更大的 Buffer＝Latency上升 太過追求硬壓低 Latency 基本上是違反系統穩定的邏輯 就像早年的 CD/卡帶 Walkman 有 N 秒防震，就是把音訊存入 Buffer 再播放 讀取完就直接丟播放看起來最及時、但碰到突發狀況（震動）就立刻跳針 所以讀取 > 存 Buffer > 從 Buffer FIFO 讀取 > 播放 Buffer 大小（秒數）形成 Latency，但也提供了系統面對突發狀況的緩衝 但把 Walkman 拿起來用力搖到超過 Buffer 長度（防震秒數）耗盡緩存後還 是只能跳針給你聽 Windows Audio device 的最小 buffer 一般而這是 3 ms Latency 設成 3 ms＝每次對 Audio device 填充資料都要在 3 ms 內完成 失敗就會出現音頻故障、設成 30 ms 就有比 3 ms 多十倍寬裕的時間來完成 但不論長短這都只是填充 Buffer 的數位域端的工作，只要在 DAC 端的緩衝 耗盡前完成下一次的 Buffer 填充就不會影響輸出 良好的硬體端當然重要，但壓低 Latency 等於聲音品質會提升怎麼想都無理 ※ 編輯: Oswyn (61.230.210.90 臺灣), 07/20/2019 12:20:09
→
07/20 11:40, 4年前 , 18F
有喔 我只是沒錢買來開箱(？
07/20 11:40, 18F
推
07/20 17:51, 4年前 , 19F
調整bios怎摸可能會有差，都4玄學姆咪
07/20 17:51, 19F
推
07/21 19:05, 4年前 , 20F
推一個
07/21 19:05, 20F
推
07/21 20:08, 4年前 , 21F
專業推 雖然霧煞煞XD
07/21 20:08, 21F
‣ 更多 Oswyn 的文章
文章代碼(AID): #1TCAKXx8 (Headphone)
‣ 更多 Oswyn 的文章
文章代碼(AID): #1TCAKXx8 (Headphone)