Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
Computer Vision for Public Transportation - Phase 2
Overview Architecture concepts Solution architecture Validation Sizing the solution
Sizing the solution
Overview
Depot sizes
Sizing guidelines
Sizing example
Scaling guidelines
Depot scaling 5G scaling Data center scaling
Conclusions References

Sizing guidelines

Home > Workload Solutions > Computer Vision > Guides > Computer Vision for Public Transportation - Phase 2 > Sizing guidelines

Sizing guidelines

  • Sizing example

    The sizing begins with what is happening on the bus. Let's take a case where each bus has 9 cameras, and each camera produces 2 Mb/s of data.

    On bus sizing

    The space on a bus is not infinite. The EPIC iO device we used has a 2 TB drive. This drive is not exclusively for video backup. This also hosts the OS files.

    In our example, we produce the following amount of Video data: 

    9 x 2Mb/s cameras produce: 64,800 Megabits of data per hour 
    This equates to: 8.1 GB storage per hour. 
     
    2 days retention on bus =  ~388 GB storage

    In this scenario, it is possible for the bus to store 2 days worth of data without offloading at the depot. Once the bus returns, it offloads and frees up the local storage. Since the EPIC iO device has 2 TB storage, it is possible to extend beyond 2 days but it would be unusual for a bus not to return to a depot for that long period of time.

    If a bus is offline for repairs or had an accident it will usually not be recording data, so no issue with video retention.

    Depot Sizing

    The depot VM compute requirements are within the available resources. When the system was in steady state offloading video from a single bus both Servers in the XR4000 cluster were under 50%. In a HA scenario where one server fails, the compute seamlessly runs on another server. If required a newer 20 CPU processor can be used in each sled.

    For sizing purposes, the available Storage is the critical factor that defines how many buses can be supported by a single XR4000 cluster. In our configuration, we have about 20 TB of vSAN storage available at the depot. This needs to cater for OS requirements and video offloading.

    Another consideration at the depot is to consider how many days of data can be hosted if the connection to the data center is severed. In the normal everyday execution, the video is replicated from the depot to the data center in near real time. Our design looks at the worst case scenario to determine how much data can behold at the depot without data loss. 

    Available video storage at Depot = 15 TB 
    2 days Bus Data = 388 GB 
     
    Max Buses Supported: 39
    Note: This calculation is based on hosting 2 days of data at the depot. Each bus will also cache another 2 days so that would allow an outside maximum of 4 days with no replication to the data center.

    In normal execution, a 4 day outage to the data center would be highly unusual. The parameters can be adjusted by reducing the count of buses or reducing the number of days retained at the depot and on the bus. It depends on how much risk is taken and how reliable the connection is to the data center.

    There is also an option of configuring the XR4000 servers with up to 8 x 3.4TB drives each. This would increase the size of the available storage at the depot, but this comes at the cost of not being able to use any GPU since a storage riser would need to be installed in replacement of the GPU riser.

    Data center Sizing

    The data center sizing was covered in a previous Design Guide-Virtualized Computer Vision for Smart Transportation with Milestone .

    An example of the sizing for a Medium City would be as follows: 

    Medium City = 435 buses 
    Daily storage per bus = 194 GB 
    Daily total storage = ~82 TB 
     
    Total retention period = 30 days 
     
    Total PowerScale storage = 2,472 TB