Mam parę serwerów IBM System x3620. Te serwery mają się dobrze, gdy w końcu osiągną punkt, w którym system operacyjny przejmuje kontrolę, ale potrzeba im wieczności, aby ominąć nowy system rozruchowy UEFI ... dobre pięć minut; może dłużej. Nie mierzyłem jej czasu, ale jest to rodzaj rzeczy, w której idziesz po filiżankę kawy, gdy czekasz, i wciąż wraca, kiedy wrócisz.
Zwykle wyłączam je tylko na comiesięczny cykl konserwacji (zwykle tylko aktualizacje systemu Windows). Ma wbudowany czas konserwacji, więc dodatkowe 5 minut nie wlicza się do naszych umów SLA i nie jest wielkim problemem. Jednak w przypadku, gdy mogę mieć awarię, z pewnością chciałbym odzyskać te 5 minut. Czy jest coś, co mogę zrobić, aby powiedzieć im, aby po prostu uruchomili już system? Wyłączyłem już wszystko, co mogę znaleźć, aby wyłączyć dodatkowe opcje rozruchu.
Odpowiedzi:
Wszystkie UEFI Maszyna IBM wziąć wieku do buta, a po UEFI inicjalizacji eon podejmowania i moduł starcie kopnięć emulacji Legacy BIOS i PCI-E ROM opcja zostanie wykonany itd. Itd. To jest „normalne” na wszystkich maszynach IBM UEFI - bez względu na to, czy jest to serwer typu blade czy standardowy.
Możesz wyłączyć starsze uruchamianie systemu BIOS, opcjonalne ROM-y, zoptymalizować kolejność uruchamiania i ogólnie utrzymać ten komputer na najnowszym poziomie oprogramowania układowego oferowanym przez IBM.
źródło
Zgadzam się, że starsze wdrożenie uEFI w Systemie X jest tak boleśnie powolne, że mógłbym nawet uniknąć sprzedaży ich jako platformy moim klientom.
Pomiar czasu IBM od momentu uruchomienia starszego rozruchu z klucza USB, dopóki nie pojawi się monit systemu operacyjnego, jest absurdalnie długi. Używam SmartOS (pochodna illumos / opensolaris do wszystkich celów i celów po uruchomieniu, działa i działa podobnie jak Solaris 11), który działa jak szczeniak Linux, np. Ładuje 275 MB „skompresowanego” obiektu blob (cały system operacyjny), a następnie uruchamia System operacyjny w pamięci. To naprawdę pokazuje problem z implementacją starszego rozruchu IBM uEFI .
To prawie tak, jakby implementacja UEFI używa małego rozmiaru bloku, takiego jak 512-bajtowe odczyty, zamiast większego bufora podczas odczytów. Gdy jestem w systemie operacyjnym, mogę porównać wydajność klucza USB, który uruchomiłem, IMHO, jeśli kod IBM UEFI odczytałby tylko rozmiar bloku 8192 lub lepszy, ale rozmiar bloku 32768, wynikowy rozruch byłby super szybki.
Kiedyś w systemach operacyjnych SmartOS widziałem następujące parametry wydajności mojego klucza USB, od 512 bajtów do 131072 bajtów. Wygląda na to, że albo rozmiar bloku 8192 (12,3 MB / s w rozruchowym systemie operacyjnym), albo jeszcze lepiej rozmiar bloku 32768 (20,2 MB / s w rozruchowym systemie operacyjnym) byłby dobrym wyborem. Wygląda też na to, że rozmiar 512 bloku (0,64 MB / s w uruchomionym systemie operacyjnym) odpowiada dość blisko wyników, które wydaje mi się występować w moich długich butach.
czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 512 count = 524288 524288 + 0 rekordów w 524288 + 0 zapisów prawdziwe 31m19.499s => 00,64 MB / s w systemie SmartOS, takim jak Solaris 11 (jest to prędkość uruchamiania systemu BIOS w IBM) czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 1024 count = 262144 262144 + 0 rekordów w 262144 + 0 zapisów prawdziwe 1m 39,989s => 02,56 MB / s SmartOS jak Solaris 11 czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 2048 count = 131072 131072 + 0 rekordów w 131072 + 0 zapisów prawdziwe 0m50.215s => 05.09 MB / s SmartOS jak Solaris 11 czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 4096 liczba = 65536 65536 + 0 rekordów w 65536 + 0 zapisów prawdziwe 0m33.056s => 07.74 MB / sek. SmartOS jak Solaris 11 czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 8192 count = 32768 32768 + 0 rekordów w 32768 + 0 zapisów prawdziwe 0m20.757s => 12,33 MB / s SmartOS jak Solaris 11 czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 32768 count = 8192 8192 + 0 rekordów w 8192 + 0 zapisów prawdziwe 0m 12,785s => 20,02 MB / s na SmartOSie, takim jak Solaris 11 (zgodnie z oczekiwaniami i widocznymi na pudełku Win7) czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 131072 count = 2048 2048 + 0 rekordów w 2048 + 0 zapisów prawdziwe 0m11.532s => 22,19 MB / s SmartOS jak Solaris 11Korzystałem z następującego nowego IBM x3550 M3 z UEFI (BIOS) wersja 1.13 (RAM 12 GB i jeden procesor ksenonowy 2.266 GHz)
Typ oprogramowania układowego Wersja Data wydania IMM YUOOC7E 30.09.2011 UEFI D6E154A 23.09.2011 DSA DSYT89P 28.10.2011Muszę powiedzieć, że jestem bardzo rozczarowany „szybkością” rozruchu USB w starszym trybie BIOS w implementacji IBM UEFI.
Zastanów się nad moim obrazem 275 MB Supermicro XSCA9F lub Oracle-Sun X4275 uruchomi obraz klucza usb 275 MB w ciągu odpowiednio 32 lub 33 sekund, podczas gdy IBM x3550 M3 zajmuje ponad 363 sekundy dla tego samego obrazu (11 razy wolniej) .
Ta wydajność jest całkowicie niedopuszczalna, a problem występuje w całej linii System X. Byłem w kontakcie z IBM i mówią tylko, że wypróbuj ładowanie rozruchowe uEFI (co jest jak powiedzenie mi, że poznaj specyfikację UEFI, naucz się GRUB2 i napisz własny niestandardowy moduł ładujący, tak, jest to wykonalne, ale nie mam dodatkowych 2 -3 tygodnie na bałagan z tymi rzeczami). Tak, użycie „czystego” rozruchu uEFI powinno działać szybko, ale nie mogę tego udowodnić, jednak wtedy nie mogłem użyć „standardowych dystrybucji”, a także, jak wskazałem, będę zmuszony napisać własny moduł ładujący uEFI.
Ten problem „wolne starsze uruchamianie” został zgłoszony przeze mnie pod adresem IBM Problem / Ticket # A02PGGK, nawet próbowałem skontaktować się bezpośrednio z programistą uEFI (myślę, że to Michael Brinkman) bezpośrednio, jednak IBM nie wydaje się, aby chciałby uznać ten problem i duża społeczność ludzi i firm, których to dotyczy.
Opublikowałem również podobną analizę do wątku na stronie http://communities.intel.com/thread/3909?wapkw=uEFI, który omawia także „powolne uruchamianie” we wrześniu 2009 r. Tutaj jest to ten sam problem, który widziałem
jest to to samo spowolnienie 10-krotnie lub 11-krotne, jakiego doświadczam, mam nadzieję, że pewnego dnia IBM to naprawi.
Jon Strabala
źródło