Es dauert lange, bis IBM Server über UEFI zum Betriebssystem gestartet ist

Ich habe ein Paar IBM System x3620-Server. Diese Server funktionieren einwandfrei, sobald sie endlich den Punkt erreicht haben, an dem das Betriebssystem die Kontrolle übernimmt, aber es dauert ewig, bis sie das neue UEFI-Boot-System überwunden haben ... gut fünf Minuten oder so; vielleicht länger. Ich habe es nicht geplant, aber es ist die Art von Sache, wo Sie eine Tasse Kaffee holen, während Sie warten, und es geht immer noch, wenn Sie zurückkommen.

Normalerweise schalte ich diese nur für einen monatlichen Wartungszyklus aus (normalerweise nur Windows-Updates). Es ist eine eingebaute Wartungszeit, und daher zählen die zusätzlichen 5 Minuten nicht für unsere SLAs und sind keine große Sache. Für den Fall, dass ich einen Ausfall haben könnte, würde ich diese 5 Minuten sicher gerne zurückbekommen. Kann ich irgendetwas tun, um ihnen zu sagen, dass sie einfach weitermachen und schon booten sollen? Ich habe bereits alles deaktiviert, was ich finden kann, um zusätzliche Startoptionen zu deaktivieren.

Alle IBM UEFI Maschinen nehmen im Alter zu booten, wie er nach der eon-Einnahme UEFI Initialisierung und Modul werden die Legacy - BIOS - Emulation Kicks und die PCI-E Option ROMs usw. erhalten ausgeführt Inbetriebnahme usw. Das ist „normal“ auf allen IBM UEFI Maschinen - Egal ob Blade oder Standard-Rack-Server.

Sie können den Legacy-BIOS-Start und die Options-ROMs deaktivieren, die Startreihenfolge optimieren und diesen Computer im Allgemeinen auf dem neuesten Firmware-Level von IBM halten.

Ich bin damit einverstanden, dass die Legacy-Implementierung von System X uEFI so schmerzhaft langsam ist, dass ich möglicherweise sogar vermeide, sie als Plattform an meine Kunden zu verkaufen.

Das Messen des IBM-Formulars in der Zeit, in der ein älterer USB-Stick gestartet wird, bis ich eine Eingabeaufforderung für das Betriebssystem erhalte, ist lächerlich lang. Ich verwende SmartOS (ein Illumos / OpenSolaris-Derivat in jeder Hinsicht, das nach dem Booten ausgeführt wird und sich ähnlich wie Solaris 11 verhält), das sich wie ein Linux-Welpe verhält, z. B. einen "komprimierten" Blob mit 275 MB (das gesamte Betriebssystem) lädt und dann das System startet Betriebssystem im Speicher. Dies zeigt wirklich das Problem mit der uEFI-Implementierung von Legacy-Booten durch IBM .

  BEG: 13:27:05 Uhr (SmartOS USB 2.0 USB-Stick starten)
  ENDE: 13:33:38 Uhr (fertig mit SmartOS - wir lesen 275 MB)
  --- ---.
  TOOK: 6:33 (sechs Minuten und 33 Sekunden - ziemlich langsam - nur 0,75 MB / s)

Es ist fast so, als ob die UEFI-Implementierung eine winzige Blockgröße wie 512-Byte-Lesevorgänge anstelle eines größeren Puffers während der Lesevorgänge verwendet. Sobald ich im Betriebssystem bin, kann ich die Leistung des von mir gebooteten USB-Sticks bewerten. IMHO, wenn der IBM UEFI-Code nur eine Blockgröße von 8192 oder besser noch eine Blockgröße von 32768 lesen würde, wäre der resultierende Start superschnell.

Einmal in einem SmartOS-Betriebssystem sah ich die folgenden Leistungsmerkmale für meinen USB-Stick im Bereich von 512 Byte bis 131072 Byte. Es sieht so aus, als wäre entweder eine 8192-Blockgröße (12,3 MB / s in einem gebooteten Betriebssystem) oder besser noch eine 32768-Blockgröße (20,2 MB / s in einem gebooteten Betriebssystem) eine gute Wahl. Es sieht auch so aus, als ob eine Blockgröße von 512 (0,64 MB / s in einem gebooteten Betriebssystem) ziemlich genau den Ergebnissen entspricht, die ich in meinen langen Stiefeln zu erleben scheine.

Zeit dd if = / dev / dsk / c1t0d0p0 von = / dev / null bs = 512 count = 524288
    524288 + 0 Datensätze in
    524288 + 0 Datensätze aus
    echte 31m19.499s
    => 00,64 MB / s. unter SmartOS wie Solaris 11 (dies ist die Geschwindigkeit der IBM BIOS-Startgeschwindigkeit)

Zeit dd if = / dev / dsk / c1t0d0p0 von = / dev / null bs = 1024 count = 262144
    262144 + 0 Datensätze in
    262144 + 0 Datensätze aus
    echte 1m39.989s
    => 02,56 MB / s. SmartOS wie Solaris 11

Zeit dd if = / dev / dsk / c1t0d0p0 von = / dev / null bs = 2048 count = 131072
    131072 + 0 Datensätze in
    131072 + 0 Datensätze aus
    echte 0m50.215s
    => 05,09 MB / s. SmartOS wie Solaris 11

Zeit dd if = / dev / dsk / c1t0d0p0 von = / dev / null bs = 4096 count = 65536
    65536 + 0 Datensätze in
    65536 + 0 Datensätze aus
    echte 0m33.056s
    => 07,74 MB / s. SmartOS wie Solaris 11

Zeit dd if = / dev / dsk / c1t0d0p0 von = / dev / null bs = 8192 count = 32768
    32768 + 0 Datensätze in
    32768 + 0 Datensätze aus
    echte 0m20.757s
    => 12,33 MB / s. SmartOS wie Solaris 11

Zeit dd if = / dev / dsk / c1t0d0p0 von = / dev / null bs = 32768 count = 8192
    8192 + 0 Datensätze in
    8192 + 0 Datensätze aus
    echte 0m12.785s
    => 20,02 MB / s. unter SmartOS wie Solaris 11 (wie erwartet und auf einer Win7-Box zu sehen)

Zeit dd if = / dev / dsk / c1t0d0p0 von = / dev / null bs = 131072 count = 2048
    2048 + 0 Datensätze in
    2048 + 0 Datensätze aus
    echte 0m11.532s
    => 22,19 MB / s. SmartOS wie Solaris 11

Ich habe im Folgenden einen neuen IBM x3550 M3 mit UEFI (BIOS) Version 1.13 (12 GB RAM und einem 2,266 GHz Xenon-Prozessor) verwendet.

    Firmware-Typ Versionszeichenfolge Veröffentlichungsdatum
    IMM YUOOC7E 30.09.2011
    UEFI D6E154A 23.09.2011
    DSA DSYT89P 28.10.2011

Ich muss sagen, dass ich von der "Geschwindigkeit" des USB-Bootens im alten BIOS-Modus in der IBM UEFI-Implementierung zutiefst enttäuscht bin.

Denkanstöße für mein 275-MB- Image Ein Supermicro XSCA9F oder ein Oracle-Sun X4275 booten ein 275-MB-USB-Key-Image in nur 32 bzw. 33 Sekunden, während der IBM x3550 M3 für dasselbe Image über 363 Sekunden benötigt (11-mal langsamer). .

Diese Leistung ist völlig inakzeptabel und das Problem besteht in der gesamten System X-Linie. Ich war in Kontakt mit IBM und sie sagen nur, versuchen Sie es mit einem uEFI-Boot-Load (was bedeutet, dass ich die UEFI-Spezifikation lerne, GRUB2 lerne und Ihren eigenen benutzerdefinierten Bootloader schreibe, ja, es ist machbar, aber ich habe keine zusätzlichen 2 -3 Wochen, um sich mit diesem Zeug anzulegen). Ja, ein "reiner" uEFI-Boot sollte schnell funktionieren, aber ich kann es nicht beweisen, aber dann konnte ich keine "Standard-Distributionen" verwenden und auch, wie ich angedeutet habe, wäre ich gezwungen, meinen eigenen uEFI-Bootloader zu schreiben.

Dieses Problem "langsames Legacy-Booten" wurde von mir unter IBM Problem / Ticket # A02PGGK gemeldet. Ich habe sogar versucht, den uEFI-Entwickler (ich denke, es ist Michael Brinkman) direkt zu kontaktieren, aber IBM scheint nicht daran interessiert zu sein, dieses Problem anzuerkennen und die große Gemeinschaft von Menschen und Unternehmen, die betroffen sind.

Ich habe auch eine ähnliche Analyse zu einem Thread unter http://communities.intel.com/thread/3909?wapkw=uEFI gepostet, in dem auch das "langsame Booten" im September 2009 behandelt wird. Hier ist es das gleiche Problem, das ich gesehen habe

Die Startzeit ist zu langsam. Das Starten eines VMware ESX dauert bei Verwendung von EFI etwa 20 Minuten, verglichen mit weniger als 2 Minuten mit dem normalen BIOS

Dies ist die gleiche 10-fache oder 11-fache Verlangsamung, die ich erlebe. Hoffentlich wird IBM dies eines Tages beheben.

Jon Strabala