4 ms·

Depends on the specific server hardware of course. Generally, yes the hardware RAID controller does consume a great deal of time (often displaying a splash scre

by Alupis 4y ago

Depends on the specific server hardware of course. Generally, yes the hardware RAID controller does consume a great deal of time (often displaying a splash screen with progress on the console, if one is connected at boot). Server hardware also tends to do other hardware checks/validate before booting as well. Some of these checks are able to be disabled, and some others are not. Then, there are systems like IBM iSeries running iOS/OS400 which then hands over to the OS to perform a great deal of system integrity checks before enabling services and I/O. Our Power7 series "400" system used to take upwards of 20 minutes to come online before we decommissioned it. Generally speaking, for a server, boot time is not a factor. Nobody needs their physical server to boot and be ready in 5 seconds... so it's never been a priority. Stability and integrity are much more important in this arena.

kevin_thibedeau 4y ago
My system boots slow because I have a legacy SCSI card installed and it's boot ROM takes ages to get running and scan the bus. Servers are more likely to have these sort of facilities onboard.
- Alupis 4y ago
  Absolutely. Although I wouldn't peg this to just legacy support - in my experience even modern SAS arrays take ages to come online. As the GP noted, modern systems coordinate the array through an integral backplane and control spin-up of individual disks plus a lot more. The main difference between a "server" and a desktop is the reliability/integrity/redundancy built into the system, which comes at the cost of boot time. A worthy trade-off in most cases, and once the system is "alive", the expected performance is achieved.
JoshTriplett 4y ago
> Generally speaking, for a server, boot time is not a factor. Nobody needs their physical server to boot and be ready in 5 seconds Nobody has had the option of this. I very much have use cases for this, and while the firmware remains a persistent problem, I've been able to bring up the kernel and userspace on server hardware in a fraction of a second. I'd love to have the firmware stop adding so much time here.
- Alupis 4y ago
  I'm curious what that use-case might be, if you are able to elaborate. Physical servers tend to have extreme uptimes, compared to desktops and even VM's. It's a fairly rare occurrence to need to reboot a physical server (by rare, I mean only when doing updates that require a reboot, such as a kernel update, and these days there are mechanisms to avoid rebooting even under that scenario). Needing to reboot often and be available in seconds just isn't a thing needed by most folks operating physical servers. Typically folks that require that operate VM's instead, which can freely be rebooted without powering down the hardware.
  - JoshTriplett 4y ago
    Many people want to use physical servers via the same kind of infrastructure that gets used for VMs. Consider something comparable to AWS's `.metal` instance types or the Kubernetes "bare metal" provider, for running things that don't run in a VM (such as VMs, since nested virtualization is variously unavailable or slow).
    - Alupis 4y ago
      Perhaps I'm just "old-school", but I still am not seeing the reason why this physical server needs to be capable of coming online in seconds. When renting a physical server, typically one understands the trade offs they are making versus operating a pure VM infrastructure, even for development purposes. VM's alleviate concerns about hardware for the most part. Physical servers just are not typically spun up and down in short succession - making the boot time completely irrelevant for all but the most extreme use cases. Many/most of the things a physical server is doing during POST and boot are necessary to guarantee reliability and integrity. Perhaps desktop "off the shelf" hardware is more what should be prescribed under your scenario.
      - JoshTriplett 4y ago
        > I still am not seeing the reason why this physical server needs to be capable of coming online in seconds. Spinning up in response to requests, without having to be constantly running (and being billed for).
c_o_n_v_e_x 4y ago
>Generally speaking, for a server, boot time is not a factor. Nobody needs their physical server to boot and be ready in 5 seconds... so it's never been a priority. Stability and integrity are much more important in this arena. Standard compute isn't the use case. Intel offers Slim Bootloader for systems that require very fast booting.. as close to "instant on" as you can get. An example would be a collision avoidance system in vehicles. Safety critical systems that require the ability to recover quickly.

by Alupis 4y ago

kevin_thibedeau 4y ago

My system boots slow because I have a legacy SCSI card installed and it's boot ROM takes ages to get running and scan the bus. Servers are more likely to have these sort of facilities onboard.

Alupis 4y ago
Absolutely. Although I wouldn't peg this to just legacy support - in my experience even modern SAS arrays take ages to come online. As the GP noted, modern systems coordinate the array through an integral backplane and control spin-up of individual disks plus a lot more. The main difference between a "server" and a desktop is the reliability/integrity/redundancy built into the system, which comes at the cost of boot time. A worthy trade-off in most cases, and once the system is "alive", the expected performance is achieved.

JoshTriplett 4y ago

> Generally speaking, for a server, boot time is not a factor. Nobody needs their physical server to boot and be ready in 5 seconds Nobody has had the option of this. I very much have use cases for this, and while the firmware remains a persistent problem, I've been able to bring up the kernel and userspace on server hardware in a fraction of a second. I'd love to have the firmware stop adding so much time here.

Alupis 4y ago
I'm curious what that use-case might be, if you are able to elaborate. Physical servers tend to have extreme uptimes, compared to desktops and even VM's. It's a fairly rare occurrence to need to reboot a physical server (by rare, I mean only when doing updates that require a reboot, such as a kernel update, and these days there are mechanisms to avoid rebooting even under that scenario). Needing to reboot often and be available in seconds just isn't a thing needed by most folks operating physical servers. Typically folks that require that operate VM's instead, which can freely be rebooted without powering down the hardware.
- JoshTriplett 4y ago
  Many people want to use physical servers via the same kind of infrastructure that gets used for VMs. Consider something comparable to AWS's `.metal` instance types or the Kubernetes "bare metal" provider, for running things that don't run in a VM (such as VMs, since nested virtualization is variously unavailable or slow).
  - Alupis 4y ago
    Perhaps I'm just "old-school", but I still am not seeing the reason why this physical server needs to be capable of coming online in seconds. When renting a physical server, typically one understands the trade offs they are making versus operating a pure VM infrastructure, even for development purposes. VM's alleviate concerns about hardware for the most part. Physical servers just are not typically spun up and down in short succession - making the boot time completely irrelevant for all but the most extreme use cases. Many/most of the things a physical server is doing during POST and boot are necessary to guarantee reliability and integrity. Perhaps desktop "off the shelf" hardware is more what should be prescribed under your scenario.
    - JoshTriplett 4y ago
      > I still am not seeing the reason why this physical server needs to be capable of coming online in seconds. Spinning up in response to requests, without having to be constantly running (and being billed for).

c_o_n_v_e_x 4y ago

>Generally speaking, for a server, boot time is not a factor. Nobody needs their physical server to boot and be ready in 5 seconds... so it's never been a priority. Stability and integrity are much more important in this arena. Standard compute isn't the use case. Intel offers Slim Bootloader for systems that require very fast booting.. as close to "instant on" as you can get. An example would be a collision avoidance system in vehicles. Safety critical systems that require the ability to recover quickly.