Pages

Jan 11, 2012

減少 Server not found 的頻率

前情提要
最近 (2011-12) 因為使用 Firefox 9, 經常發生 Server not found, 心理面懷疑是 FF9 造成的, 乾脆把整個 FF9 徹底移除, 連同硬碟內的目錄, Registry 通通清除之, 然後重新安裝 FF9, 但是 Server not found 的現象並沒有「緩解」, 這代表著 FF9 是無辜的受害者....

既然不是瀏覽器這個層級的問題, 那問題可能出在更上一層, 於是把 dnscache 給清除了 (但這應該是與問題無關, 原因後述). Windows 7 系統裡面的 dnscache 仍然是 DNS Client 服務, 在命令列上下指令 ipconfig /flushdns.

一般而言 DNS Cache 會依照該項目的 TTL 時間, 自動排出快取範圍, 因此 Cache 不至於失控的成長, 但是 Server not found 的問題並不是 dnscache 能做到的, 之所以發生問題是 cache 根本沒有這個資料或是該主機搬家了, 造成 IP 對應 hostname 發生錯誤. 另一個可能是 DNS 主機 timeout, 超過 FF9 內定的最大容忍範圍, 因此 FF9 回報 Server not found.

清了 dnscache 後, 打開 cfosspeed 的 current connections 功能, 會列出實際上正在連線的列表, 我觀察到了 OpenDNS 主機回應 0 的現象, 這正是原因所在.

問題是 OpenDNS 主機是人家的, 已經超過我們能管控的範圍, 每隔幾分鐘就來一陣子主機回應 0 的事情, 就造成 FF9 或 IE9 完全連不上網路, 該如何解決??

Jun 27, 2011

辛苦的對齊 (Align)

按照預設 Windows 2003 以前的版本, 包含 XP, 2000... 等, 並沒有對儲存裝置 (HDD or SSD) 的分割表作規劃, 因此第一個分割表會自動位移 63 sectors, 造就了 32256 bytes (31.5KB) 的偏移.

然而問題就出在這了, Windows Vista 之後的版本, 如 7, Windows 8... 等, 都最少需要 4KB 為邊界作每一次的 IOS 動作, 顯然 31.5KB 沒辦法被 4KB 整除, 因此當正好讀取在 31.5KB 無法整除的邊界時, 就必須要 2 次 IOS 動作.

現在主流的儲存裝置測試主要分兩類: 循序讀寫, 隨機讀寫. 前者沒什麼好說的, 通常可以測試該儲存裝置最大的效能, 然而 Windows 系統碟每秒鐘都會不斷的有資料讀寫, 而這些讀寫往往都是幾個 bytes 而已. 因此 4K 隨機讀寫就成了關鍵, 這項測試結果直接影響使用者對於電腦「反應速度」的「主觀經歷」, 而...4K 隨機讀寫正是 SSD 的特長. SSD 另一個決定性的關鍵是 track-to-track 反應時間, 趨近於 0ms. 而 HDD 受限於主軸馬達轉速與電磁機械磁臂的來回時間, 上述時間都有 8~18ms 之間.

主題拉回來, 那麼如果修改了分割表的位移量, 真的能「看見」改善的效能?

Mar 13, 2011

Load Unload Cycle Count 所衍生的大問題

最近從朋友那邊拿到一台報廢電腦, 裡面裝了一顆算是蠻新的硬碟 WDC WD5000BEVT-22A0RT0, 不知道她何時安裝的, 但看了製造日期是 2010-JUN-20, 距離現在只有大概 8 個多月左右, 心想就算要故障也機率不高....

拿了 Crystal Disk Info 看了一下 SMART 資料, 我的媽咪阿....
Start/Stop Count 達到 20xxx 次
Load/Unload Cycle Count 衝破 163xxx 次 (沒看錯, 是 16.3 萬次)
而使用時數呢?? Power-On Hours 只有區區 92x 小時

換句話說平均每小時
167 次的磁頭歸位與 21 次的馬達重新運轉
一考察她的作業系統是 Ubuntu 10.04 LTS, 答案出來了.....又是 linux backgound 的狀況

Jan 26, 2011

XP SP3 + EWF 設定備忘錄

利用 EWF (Enhanced Write Filter) 這個驅動, 將所有寫入 HDD 的資料導向到 Memory。用途蠻多的, 例如:
1.免費影子系統
2.百毒不侵
3.最佳的軟體測試場
4.延長(偽)SSD壽命