By: Ben T (ben.delete@this.noemail.com), July 24, 2022 5:29 am
Room: Moderated Discussions
> Why not just use cartridges of micro/pico/nano whatever arbitrary name server cards share an electrical and IO subsystems?
Your suggestion sounds like a blade server. I think the best option depends on the failure rate of the processors compared to the failure rate of the drives. If the failure rates are about the same, then blades make sense. If the drives fail at a higher rate than the processors, then hot-swap drives are a better option. With 12 processor packages soldered to a motherboard as I suggested, if a few processors fail, tasks would just not be assigned to those processors. If a lot of the processors in a chassis fail, the whole 1U chassis would be replaced. Having 12 processor packages soldered to a motherboard is less expensive and more reliable than blades because there are fewer connectors and other mechanical hardware.
I was thinking of this system for a general-purpose cloud computing service. Someone pointed out that Apple already has a cloud computing service for app developers called Xcode Cloud. Testing on Xcode Cloud is currently done with device simulators. If Apple developed servers with Apple Silicon, testing on Xcode Cloud could be done on Apple Silicon, which would be faster and more realistic than device simulators.
> - loss of vcpu performance as smaller thermal envelope and smaller shared uncore and memory
The processor die would be like a chiplet or tile in an EPYC or Xeon processor. The lack of sharing of the last level cache and memory between different users is intentional to prevent data leakage between users. If the processor package contains enough memory and last level cache for the working set of an application, there would be no loss of CPU performance. If the processor package doesn’t contain enough memory and last level cache for the working set of an application, the application would not be suitable for this system.
> - added complexity in supply chain, technical support and inventory management
> - added complexity in operations as you'll need new system images, update to orchestration tools
Apple was able to handle of the added complexity of supporting both x86 and Apple Silicon during their transition. Supporting both x86 servers and the type of server I described is not more difficult than that.
> - because of smaller resource pools, more difficult in achieving high utilization to drive economics and energy efficiency
I agree smaller resource pools make it more difficult to get high utilization of the hardware. When comparing Intel x86 to Apple Silicon, the most important thing driving economics and energy efficiency is TSMC process technology, not high utilization of hardware. Similarly, a mainframe has higher utilization of hardware than a personal computer, but a mainframe isn’t less expensive per user.
> For some applications, what you describe may make sense at scale, such as web frontends
If all this server is used for is web frontends, app testing, website testing and Hadoop, that would be plenty.
> the direction is ever larger resource pools
That does seem to be Intel’s direction. It may not be the best solution for everyone. Similarly, a Storage Area Network (SAN) is not the best solution for everyone.
Your suggestion sounds like a blade server. I think the best option depends on the failure rate of the processors compared to the failure rate of the drives. If the failure rates are about the same, then blades make sense. If the drives fail at a higher rate than the processors, then hot-swap drives are a better option. With 12 processor packages soldered to a motherboard as I suggested, if a few processors fail, tasks would just not be assigned to those processors. If a lot of the processors in a chassis fail, the whole 1U chassis would be replaced. Having 12 processor packages soldered to a motherboard is less expensive and more reliable than blades because there are fewer connectors and other mechanical hardware.
I was thinking of this system for a general-purpose cloud computing service. Someone pointed out that Apple already has a cloud computing service for app developers called Xcode Cloud. Testing on Xcode Cloud is currently done with device simulators. If Apple developed servers with Apple Silicon, testing on Xcode Cloud could be done on Apple Silicon, which would be faster and more realistic than device simulators.
> - loss of vcpu performance as smaller thermal envelope and smaller shared uncore and memory
The processor die would be like a chiplet or tile in an EPYC or Xeon processor. The lack of sharing of the last level cache and memory between different users is intentional to prevent data leakage between users. If the processor package contains enough memory and last level cache for the working set of an application, there would be no loss of CPU performance. If the processor package doesn’t contain enough memory and last level cache for the working set of an application, the application would not be suitable for this system.
> - added complexity in supply chain, technical support and inventory management
> - added complexity in operations as you'll need new system images, update to orchestration tools
Apple was able to handle of the added complexity of supporting both x86 and Apple Silicon during their transition. Supporting both x86 servers and the type of server I described is not more difficult than that.
> - because of smaller resource pools, more difficult in achieving high utilization to drive economics and energy efficiency
I agree smaller resource pools make it more difficult to get high utilization of the hardware. When comparing Intel x86 to Apple Silicon, the most important thing driving economics and energy efficiency is TSMC process technology, not high utilization of hardware. Similarly, a mainframe has higher utilization of hardware than a personal computer, but a mainframe isn’t less expensive per user.
> For some applications, what you describe may make sense at scale, such as web frontends
If all this server is used for is web frontends, app testing, website testing and Hadoop, that would be plenty.
> the direction is ever larger resource pools
That does seem to be Intel’s direction. It may not be the best solution for everyone. Similarly, a Storage Area Network (SAN) is not the best solution for everyone.
Topic | Posted By | Date |
---|---|---|
Retbleed | anonymous2 | 2022/07/13 03:14 PM |
Retbleed | anon2 | 2022/07/13 10:03 PM |
Retbleed | Adrian | 2022/07/14 12:05 AM |
Retbleed | Anon4 | 2022/07/14 02:17 PM |
Retbleed | anon2 | 2022/07/14 04:29 PM |
Retbleed | Anon4 | 2022/07/14 05:05 PM |
Retbleed | anon2 | 2022/07/14 05:37 PM |
Retbleed | anon2 | 2022/07/14 06:40 PM |
Retbleed | dmcq | 2022/07/15 04:54 AM |
Retbleed | anon2 | 2022/07/17 07:17 AM |
Retbleed | Michael S | 2022/07/15 07:08 AM |
Retbleed | Ben T | 2022/07/16 05:06 AM |
Retbleed | Michael S | 2022/07/16 11:41 AM |
Public cloud infrastructure | Ben T | 2022/07/16 04:50 PM |
Public cloud infrastructure | Rayla | 2022/07/16 09:15 PM |
Public cloud infrastructure | me | 2022/07/17 09:19 AM |
Public cloud infrastructure | Brett | 2022/07/18 12:38 PM |
Public cloud infrastructure | Adrian | 2022/07/18 01:19 PM |
Public cloud infrastructure | me | 2022/07/18 03:54 PM |
Public cloud infrastructure | Brett | 2022/07/20 03:35 PM |
Public cloud infrastructure | Brett | 2022/07/21 01:18 PM |
Public cloud infrastructure | inthestratosphere | 2022/07/21 02:46 PM |
Public cloud infrastructure | Brett | 2022/07/21 10:38 PM |
What’s needed for a viable Apple server? | Ben T | 2022/07/22 05:31 AM |
What’s needed for a viable Apple server? | Michael S | 2022/07/22 09:09 AM |
More DRAM capacity? | Mark Roulo | 2022/07/22 09:48 AM |
More DRAM capacity? | Doug S | 2022/07/22 11:05 AM |
More DRAM capacity? | Mark Roulo | 2022/07/22 11:20 AM |
More DRAM capacity? | Doug S | 2022/07/22 01:48 PM |
More DRAM capacity? | Wes Felter | 2022/07/22 04:49 PM |
Public cloud infrastructure | anon2 | 2022/07/18 04:25 PM |
Putting 12 processor packages in a 1U server | Ben T | 2022/07/22 10:02 PM |
Putting 12 processor packages in a 1U server | rwessel | 2022/07/23 07:15 AM |
Putting 12 processor packages in a 1U server | Daniel B | 2022/07/23 04:15 PM |
Putting 12 processor packages in a 1U server | Ben T | 2022/07/24 05:29 AM |
Multi-system cluster design space | Paul A. Clayton | 2022/07/24 08:49 AM |
Retbleed | Anon4 | 2022/07/15 03:00 AM |
Retbleed | Michael S | 2022/07/15 06:59 AM |
Retbleed | --- | 2022/07/15 11:14 AM |