IBM 伺服器需要很長時間才能通過 UEFI 引導到作業系統
我有一對 IBM System x3620 伺服器。一旦這些伺服器最終到達作業系統接管的地步，它們就可以正常工作，但是它們需要永遠通過新奇的 UEFI 引導系統……大約五分鐘；也許更長。我還沒有計時，但這是一種你在等待的時候去喝杯咖啡，當你回來的時候它還在繼續的事情。
通常我關閉這些的唯一時間是每月維護週期（通常只是 Windows 更新）。這是內置的維護時間，因此額外的 5 分鐘不計入我們的 SLA，也沒什麼大不了的。但是，在我可能會中斷的情況下，我肯定希望恢復那 5 分鐘。我能做些什麼來告訴他們繼續並啟動嗎？就額外的啟動選項而言，我已經禁用了所有我能找到的禁用功能。
所有 IBM uEFI 機器都需要很長時間才能啟動，因為在 eon 進行uEFI初始化和模組啟動後，舊版 BIOS 仿真開始啟動，PCI-E 選項 ROM 被執行等等。這在所有 IBM uEFI 機器上都是“正常的” -無論是刀片伺服器還是標準機架伺服器。
您可以禁用傳統 BIOS 引導、選項 ROM、優化引導順序並通常將該機器保持在 IBM 提供的最新韌體級別。
我同意 System X uEFI 舊版實現非常緩慢，我什至可能會避免將它們作為平台出售給我的客戶。
測量 IBM 從它開始傳統 USB 密鑰引導直到我收到作業系統提示的時間非常長。我正在使用 SmartOS（一種用於所有目的的 illumos/opensolaris 衍生產品，一旦啟動它就會執行並且行為很像 Solaris 11），它的行為就像小狗 Linux，例如它載入一個 275MB 的“壓縮”blob（整個作業系統），然後啟動記憶體中的作業系統。 這確實展示了 IBM uEFI 實現傳統引導的問題。
BEG：下午 1:27:05（啟動 SmartOS USB 2.0 USB 密鑰） 結束：下午 1:33:38（執行 SmartOS - 我們讀取 275MB） --- TOOK：6:33（6 分 33 秒 - 相當慢 - 只有 0.75MB/秒。）就好像 UEFI 實現使用像 512 字節讀取這樣的小塊大小，而不是在讀取期間使用更大的緩衝區。一旦我進入作業系統，我就可以對我啟動的 USB 密鑰的性能進行基準測試，恕我直言，如果 IBM UEFI 程式碼只能讀取 8192 塊大小或更好的塊大小，但結果是 32768 塊大小，那麼由此產生的引導將非常快。
因此，有一次在 SmartOS 作業系統中，我看到了我的 USB 密鑰的以下性能特徵，範圍從 512 字節到 131072 字節。看起來 8192 塊大小（在啟動的作業系統中為 12.3 MB/秒）或更好的 32768 塊大小（在啟動的作業系統中為 20.2 MB/秒）將是不錯的選擇。它看起來也像 512 塊大小（在引導的作業系統中為 0.64 MB/秒）與我在漫長的引導中所經歷的結果非常接近。
時間 dd if=/dev/dsk/c1t0d0p0 of=/dev/null bs=512 count=524288 524288+0 條記錄在 524288+0 條記錄輸出 真正的 31m19.499s => 00.64MB/秒。在像 Solaris 11 這樣的 SmartOS 上（這是 IBM bios 啟動速度的速度） 時間 dd if=/dev/dsk/c1t0d0p0 of=/dev/null bs=1024 count=262144 262144+0 條記錄 262144+0 條記錄 真正的 1m39.989s => 02.56MB/秒。像 Solaris 11 這樣的 SmartOS 時間 dd if=/dev/dsk/c1t0d0p0 of=/dev/null bs=2048 count=131072 131072+0 條記錄 131072+0 條記錄 實際0m50.215s => 05.09MB/秒。像 Solaris 11 這樣的 SmartOS 時間 dd if=/dev/dsk/c1t0d0p0 of=/dev/null bs=4096 count=65536 65536+0 條記錄在 65536+0 條記錄輸出 真正的 0m33.056s => 07.74MB/秒。像 Solaris 11 這樣的 SmartOS 時間 dd if=/dev/dsk/c1t0d0p0 of=/dev/null bs=8192 count=32768 32768+0 條記錄在 32768+0 條記錄 實際0m20.757s => 12.33MB/秒。像 Solaris 11 這樣的 SmartOS 時間 dd if=/dev/dsk/c1t0d0p0 of=/dev/null bs=32768 count=8192 8192+0 條記錄 8192+0 條記錄 真正的 0m12.785s => 20.02MB/秒。在像 Solaris 11 這樣的 SmartOS 上（如在 Win7 機器上所預期和看到的那樣） 時間 dd if=/dev/dsk/c1t0d0p0 of=/dev/null bs=131072 count=2048 2048+0 條記錄 2048+0 條記錄 真正的 0m11.532s => 22.19MB/秒。像 Solaris 11 這樣的 SmartOS我正在使用以下帶有 UEFI (BIOS) rev 1.13 的新 IBM x3550 M3（12GB 記憶體和一個 2.266GHz Xenon 處理器）
韌體類型 版本字元串 發布日期 IMM YUOOC7E 09/30/2011 UEFI D6E154A 09/23/2011 DSA DSYT89P 10/28/2011我必須說我對 IBM UEFI 實現中傳統 BIOS 模式下 USB 啟動的“速度”感到非常失望。
我的 275MB 映像值得深思，Supermicro XSCA9F 或 Oracle-Sun X4275 將分別在 32 或 33 秒內啟動 275 MB usb 密鑰映像，而 IBM x3550 M3 需要 363 秒以上才能獲得相同的映像（慢 11 倍） .
這種性能是完全不能接受的，而且整個 System X 產品線都存在這個問題。我一直在與 IBM 聯繫，他們只是說嘗試 uEFI 引導載入（這就像對我說學習 UEFI 規範，學習 GRUB2 並編寫自己的自定義引導載入程序，是的，它是可行的，但我沒有額外的 2 -3 週來弄亂這些東西）。是的，使用“純”uEFI 引導應該可以快速工作，但我無法證明這一點，但是我不能使用“標準發行版”，而且正如我所指出的，我將被迫編寫自己的 uEFI 引導載入程序。
我在 IBM Problem/Ticket #A02PGGK 下報告了這個問題“舊版啟動緩慢”，我什至嘗試直接聯繫 uEFI 開發人員（我認為是 Michael Brinkman），但是 IBM 似乎並不關心承認這個問題並且受影響的人和公司的龐大社區。
我還在http://communities.intel.com/thread/3909?wapkw=uEFI的一個執行緒中發布了類似的分析，該執行緒還討論了 2009 年 9 月的“緩慢啟動”，這是我一直看到的相同問題
開機時間太慢。使用 EFI 時啟動 VMware ESX 大約需要 20 分鐘，而使用普通 bios 時不到 2 分鐘
這與我經歷的 10 倍或 11 倍的減速相同，希望有一天 IBM 能解決這個問題。
喬恩·斯特拉巴拉