IBM服务器需要很长时间才能启动UEFI到OS

我有一对IBM System x3620服务器。这些服务器一旦终于到达操作系统接pipe点的位置，就可以正常工作了，但是这个服务器将永远无法通过新的UEFI引导系统…大概五分钟左右; 也许更长。我没有计时，但是这是等待你喝杯咖啡的时候，当你回来的时候还在继续。

通常我closures这些的唯一时间是每月维护周期（通常只是Windows更新）。这是内置的维护时间，所以额外的5分钟不计入我们的SLA，并没有什么大不了的。但是，如果我可能发生停电的情况，我一定会把那5分钟时间拿回来。有什么我可以做的，告诉他们只是继续开车已经？我已经禁用了一切，我可以find禁用，只要额外的启动选项去。

所有IBM uEFI计算机都需要很长时间才能启动，因为在进行uEFI初始化和模块启动之后，旧版BIOS模拟会启动并执行PCI-E选项ROM等等。在所有IBM uEFI计算机上这是“正常”不pipe是刀片服务器还是标准机架服务器。

您可以禁用传统BIOS引导，选项ROM，优化引导顺序，并通常保持该机器到IBM提供的最新固件级别。

我同意System X uEFI传统的实现过程非常缓慢，甚至可能避免将它们作为平台出售给我的客户。

测量IBMforms的时间，它开始传统的USB密钥启动，直到我得到一个操作系统的提示是可笑的很长。我使用的是SmartOS（一种用于所有意图的Illumos / opensolaris衍生工具，一旦启动，就像Solaris 11一样），就像小狗Linux一样，它加载一个275MB的“压缩”blob（整个操作系统），然后启动内存中的操作系统 这确实显示了IBM的uEFI实施传统引导的问题 。

   BEG：1:27:05 pm（启动SmartOS USB 2.0 USB钥匙）
  结束：1:33:38 pm（完成运行SmartOS  - 我们读取275MB）
   ---
   TOOK：6:33（6分33秒 - 非常慢 - 仅为0.75MB /秒）

就好像UEFI实现使用512字节读取的小块大小，而不是在读取期间更大的缓冲区。一旦我在操作系统中，我可以基准testing我启动的USB密钥的性能，恕我直言，如果IBM UEFI代码只是读取8192块大小或更好的32768块大小，结果引导将是超级快。

所以一旦在SmartOS操作系统中，我看到了我的USB密钥的以下性能特征，从512字节到131072字节。看起来像8192块大小（引导操作系统12.3 MB /秒）或更好，32768块大小（引导操作系统20.2 MB /秒）将是不错的select。它看起来像一个512块大小（引导操作系统0.64 MB /秒）匹配非常接近，我似乎在我的冗长的靴子经验的结果。

 time dd if = / dev / dsk / c1t0d0p0 = / dev / null bs = 512 count = 524288
     524288 + 0logging在
     524288 + 0logging
    真正的31m19.499s
     => 00.64MB /秒。 在像Solaris 11这样的SmartOS上（这是IBM bios启动速度的速度）

时间dd if = / dev / dsk / c1t0d0p0 = / dev / null bs = 1024 count = 262144
     262144 + 0logging
     262144 + 0logging
    真正的1m39.989s
     => 02.56MB /秒。 像Solaris 11一样的SmartOS

时间dd if = / dev / dsk / c1t0d0p0 = / dev / null bs = 2048 count = 131072
     131072 + 0条logging
     131072 + 0logging
    真正的0分50秒15秒
     => 05.09MB /秒。 像Solaris 11一样的SmartOS

时间dd if = / dev / dsk / c1t0d0p0 = / dev / null bs = 4096 count = 65536
     65536 + 0logging在
     65536 + 0logging
    真实0m33.056s
     => 07.74MB /秒。 像Solaris 11一样的SmartOS

时间dd if = / dev / dsk / c1t0d0p0 = / dev / null bs = 8192 count = 32768
     32768 + 0的logging
     32768 + 0logging
    真实0m20.757s
     => 12.33MB /秒。 像Solaris 11一样的SmartOS

时间dd if = / dev / dsk / c1t0d0p0 = / dev / null bs = 32768 count = 8192
     8192 + 0logging在
     8192 + 0logging
    真实0m12.785s
     => 20.02MB /秒。 在像Solaris 11这样的SmartOS上（就像在Win7上看到的那样）

时间dd if = / dev / dsk / c1t0d0p0 = / dev / null bs = 131072 count = 2048
     2048 + 0logging
     2048 + 0logging
    真正的0m11.532s
     => 22.19MB /秒。 像Solaris 11一样的SmartOS

我正在使用以下新的IBM x3550 M3与UEFI（BIOS）rev 1.13（12GB内存和一个2.266GHz氙气处理器）

    固件types版本string发行date
     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引导应该工作得很快，但我不能certificate这一点，然而，我不能使用“标准发行版”，也正如我指出，我将被迫写我自己的uEFI引导装载程序。

这个问题“缓慢的遗留启动”是由IBM问题/票＃A02PGGK我报告，我甚至尝试直接联系uEFI开发人员（我认为它是迈克尔Brinkman），但是，IBM似乎并不喜欢承认这个问题，受影响的人员和公司的大型社区。

我还在http://communities.intel.com/thread/3909?wapkw=uEFI上发布了一个类似的分析，其中还讨论了2009年9月的“慢启动”，这里是我所看到的同样的问题

启动时间太慢。使用EFI时，启动VMware ESX需要大约20分钟的时间，而使用普通BIOS的时间less于2分钟

这是我经历的相同的10倍或11倍放缓，希望有一天IBM可以解决这个问题。

Jon Strabala