Home > AI Solutions > Artificial Intelligence > White Papers > Dell Automotive Reference Architecture > Sizing and scalability
It is important to understand the difference between sizing and scaling. Sizing is a resource planning exercise to estimate how much compute, networking, storage, power, and space is required for each application, service, or workload. Sizing must address expected user demand, storage requirements, expected traffic patterns, training time, and miles simulated per day without over or under provisioning resources. Sizing must occur with each purchasing phase of the program. Whereas scalability refers to an architecture that incrementally increases in size, while still being able to maintain or increase its level of performance even as it is stretched by larger and larger operational demands.
DARA is an example of a scalable architecture that allows the execution environment to grow with each purchasing phase without sacrificing performance. An end user can purchase the DARA starter kit and expand the operational environment with incremental purchases of SUs. An SU is user-defined and can be several different racks of resources depending on the workload and user environment. For example, an SU can be a rack of PowerEdge storage that can be added to the starter kit for archivable purposes. Another example of an SU is a rack of simulation servers (server-based HiL Rigs) that can be combined with the starter kit to increase the model verification coverage in a shorter amount of time. In any case, SUs can be added at any time without disrupting the operational environment or server availability.
The basis for estimating the number of resources required for a specific environment is knowing how many simulated miles per day the project requires. Because the ADAS/AD market is nascent, KPIs and standards are still developing. A good starting point is to use the Rand Corporation’s report, Driving to Safety[8]. It provides an overall project guideline for the total number of simulated miles required to be as good as or better than a human driver by using simulated miles per day as a quantitative approximation for resource sizing.
Resource sizing can be determined using the smallest meaningful building block so the results can be extended to estimate resource requirements to meet project performance goals. For this example, the hardware configuration is one AMD two-socket server (PowerEdge R7525) using three rendering GPUs (RTX8000s).
See the Hardware Configuration legend in the following figure. The benchmark image resolution was scaled to 512x512x8bpp so performance results can be easily compared to other benchmarks using the similar image resolutions. This example is used to demonstrate the sizing process and does not represent results from the starter kit. As newer or different hardware becomes available, the sizing process remains the same and the following graphs must be updated to reflect the new results.
Figure 10. Three graphs show GPU benchmarks from three different perspectives
The figure shows three graphs each showing frames per second (FPS) from three different perspectives: camera, GPU, and system performance. The most important graph for this exercise is the system or aggregate performance graph that indicates that the FPS begins to dip slightly starting at 14 - 1080p cameras. For our sizing example, we can use eight video cameras per vehicle without negatively impacting system performance. From the aggregate system performance graph, eight video cameras translate to about 300 FPS, which we use in the following sizing example.
The following figure shows the first six steps of the sizing example:
Figure 11. Infrastructure sizing example steps 1 through 6
In the figure:
The following figure shows the last four steps of the sizing example.
Figure 12. Infrastructure sizing example steps 7 through 10