The CPU in a 3DS system has two cores. The application core can be used freely by applications, while the system core is used by the system to handle device processing. Processing for each device is assigned a priority level, so an increase in one device's processing load may affect other devices. The handling of processes in the system core varies depending on which version of the SDK you are using.
The following list of processes handled by the system core are directly related to the application.
- Cameras
- Graphics
- HID
- Wireless Communication
In addition to these processes, some API functions called by an application (such as FS library API functions) are also processed in the system core.
General information about the processing loads for these devices follows.
Cameras
These processes are involved in obtaining camera images. There is almost no load when the cameras are not being used. The camera’s processing load varies with settings such as the frame rate. Y2R processing is included in this item.
Graphics
The system core synchronizes the GPU and command lists when command lists are executed. Because this involves an interrupt and execution of the next request for every command request, the associated processing load is based primarily on the number of command requests.
HID
The HID (human interface device) executes processing for key input, the touch panel, the accelerometer, and the gyro sensor.
Although the accelerometer and gyro sensor create no processing load when they are not used (when they are shut down), it is not possible to shut down the processing of the other devices. If the accelerometer and gyro sensor are used, the accelerometer puts a larger load on the system core than the gyro sensor, but the overall processing load of the other devices is larger than that of the accelerometer (other devices > accelerometer > gyro sensor). If the debug controller is connected to development hardware, the processing load increases even more.
Wireless Communication
These processes are related to wireless communications. Wireless communication has low priority in the system core, and generally does not affect other processing. However, because it is highly susceptible to the effects of other processing, the smaller the processing load by higher-priority applications, the more stable wireless communication becomes.
7.1. Processing in the System Core
Some system core processing resources are available to the application. The application can operate essential processes in the system core, but a limit is set on the application’s use of the system core. This limit helps to guarantee future operation of system and application processes in the system core.
The maximum amount of system core CPU time that can be assigned by the nn::os::SetApplicationCpuTimeLimit
function to application processes is 30%.
Note:
To run sounds in the system core using NW4C, the associated processing must be carried out within the CPU time allocated to the application. Noise might be introduced during sound playback if other processes are also being handled by the system core at the same time.
In extended applications, even if the same ratio of CPU time is allocated to the application, more processes can be handled due to the increased CPU clock rate.
The following processes operate in the system core, and are listed in order of priority from highest to lowest.
- Cameras
- Graphics
- HID (including Circle Pad Pro)
- Wireless Communication
7.1.1. Changing the Priority of Graphics Processing
You can change the priority of graphics processing in the system core from high to low using the nngxSetInternalDriverPrioMode
function. When graphics processing is set to low priority, the order of priority of the processes carried out in the system core changes as follows.
- Cameras
- HID (including Circle Pad Pro)
- Graphics
- Wireless Communication
Changing the priority of graphics makes no significant difference in the performance of the application.
7.1.2. Cautions When Using the System Core
Some CPU time of the system core is allocated to applications using nn::os::SetApplicationCpuTimeLimit
to allow the creation of threads that run in the system core.
Although running some processes in the system core allows you to increase the processes being executed by an application, some processes are best suited for execution in the system core and some are not because system core scheduling allocates CPU time in 2-ms intervals.
Note:
System processes cannot be run during CPU time allocated to an application even if the application is not using the system core at the time. The execution time of system processes, such as wireless communication, decreases by the amount of system core allocated to the application.
The CPU time allocated to an application is not synced with picture frames.
Note:
For information about system core scheduling, see the System Programming Guide included in the CTR-SDK documentation.
Processing Suited for Execution in the System Core
The system core CPU time allocated to applications is fixed. This CPU time is best suited for processes such as the following that occur regularly and are completely CPU-bound.
- Reading and writing buffers.
Examples include processes that write data (such as movie data or raw sound data) loaded in memory to a work buffer, and processes that copy data between a send/receive buffer used in wireless communication and a work buffer.
- Generating GPU commands.
- AI processes, computational processes, and so on.
Even in cases like these, processing may take more time than execution in the application core due to the graphics or sound interrupts and the fact that time is allocated in specific intervals. We recommend that you execute processes that allow a certain degree of delay.
Processes Not Suited for Execution in the System Core
Processes that are not completely CPU-bound and processes that only reoccur a few times during the course of executing an application are unsuited for execution in the system core (except when you want to emphasize the process).
Make sure to pay particular attention in cases where processes use devices other than graphics and sound-related devices. If an application calls an API function that uses such devices, that process starts when transferred to the system after the system core CPU time allocated to the application passes. In other words, even if the process completes in a short amount of CPU time, the result cannot be obtained by the application until the next interval of CPU time allocated to the application occurs. If a process does not complete within the time allocated to the application, thread processes are completely blocked during the allocated CPU time.
Even though you can reduce the possibility of blocking during wireless communication by splitting send and receive processing into different threads, processes are blocked for a full 2 ms if the number of packets being sent and received is greater than the number that can be handled during the time system processing can execute.
7.1.3. Resetting the Allocated Time (Important)
You can reset the system core CPU time allocated to an application by calling the nn::os::SetApplicationCpuTimeLimit
function again. Resetting the allocation is useful in cases where the amount of processing by the application changes for different scenes, such as with single player and multiplayer modes. Note however, that once set there is no returning to zero, and at least 5% (or approximately 0.1 ms) of an interval will definitely be allocated to the application. Changing the allocation frequently is very risky. We recommend changing the allocation only for high level functionality such as “single player” and “multiplayer.”
Allocating system core CPU to an application has a significant effect on the wireless communication being carried out by the system. We recommend that you do not allocate system core CPU time to applications during multiplayer modes that use wireless communication. To prioritize multiplayer mode, either do not allow applications to use the system core in the first place or make sure that the amount of time allocated is short and has low real-time requirements.
For your reference, we carried out a comparison of communication status while varying the allocation time for an application (equivalent to the sync/simple demo in the CTR-Pia library) that carries out only communication processes. Results showed that communications were very stable when no system core CPU time was allocated in the first place. On the other hand, packet loss apparently proportional to the load on the system core even when threads running in the system core were not created occurred when up to 30% (approximately 0.6 ms) of a CPU time interval was allocated.
Comparison was carried out under the following conditions.
Item
Condition
Protocol
Local UDS communication
Network
Single network consisting of four 3DS systems
Number of packets
60 packets per second per unit (all set to Broadcast)
Wireless signal
Extremely good
Some system core processing resources are available to the application. The application can operate essential processes in the system core, but a limit is set on the application’s use of the system core. This limit helps to guarantee future operation of system and application processes in the system core.
The maximum amount of system core CPU time that can be assigned by the nn::os::SetApplicationCpuTimeLimit
function to application processes is 30%.
To run sounds in the system core using NW4C, the associated processing must be carried out within the CPU time allocated to the application. Noise might be introduced during sound playback if other processes are also being handled by the system core at the same time.
In extended applications, even if the same ratio of CPU time is allocated to the application, more processes can be handled due to the increased CPU clock rate.
The following processes operate in the system core, and are listed in order of priority from highest to lowest.
- Cameras
- Graphics
- HID (including Circle Pad Pro)
- Wireless Communication
7.1.1. Changing the Priority of Graphics Processing
You can change the priority of graphics processing in the system core from high to low using the nngxSetInternalDriverPrioMode
function. When graphics processing is set to low priority, the order of priority of the processes carried out in the system core changes as follows.
- Cameras
- HID (including Circle Pad Pro)
- Graphics
- Wireless Communication
Changing the priority of graphics makes no significant difference in the performance of the application.
7.1.2. Cautions When Using the System Core
Some CPU time of the system core is allocated to applications using nn::os::SetApplicationCpuTimeLimit
to allow the creation of threads that run in the system core.
Although running some processes in the system core allows you to increase the processes being executed by an application, some processes are best suited for execution in the system core and some are not because system core scheduling allocates CPU time in 2-ms intervals.
Note:
System processes cannot be run during CPU time allocated to an application even if the application is not using the system core at the time. The execution time of system processes, such as wireless communication, decreases by the amount of system core allocated to the application.
The CPU time allocated to an application is not synced with picture frames.
Note:
For information about system core scheduling, see the System Programming Guide included in the CTR-SDK documentation.
Processing Suited for Execution in the System Core
The system core CPU time allocated to applications is fixed. This CPU time is best suited for processes such as the following that occur regularly and are completely CPU-bound.
- Reading and writing buffers.
Examples include processes that write data (such as movie data or raw sound data) loaded in memory to a work buffer, and processes that copy data between a send/receive buffer used in wireless communication and a work buffer.
- Generating GPU commands.
- AI processes, computational processes, and so on.
Even in cases like these, processing may take more time than execution in the application core due to the graphics or sound interrupts and the fact that time is allocated in specific intervals. We recommend that you execute processes that allow a certain degree of delay.
Processes Not Suited for Execution in the System Core
Processes that are not completely CPU-bound and processes that only reoccur a few times during the course of executing an application are unsuited for execution in the system core (except when you want to emphasize the process).
Make sure to pay particular attention in cases where processes use devices other than graphics and sound-related devices. If an application calls an API function that uses such devices, that process starts when transferred to the system after the system core CPU time allocated to the application passes. In other words, even if the process completes in a short amount of CPU time, the result cannot be obtained by the application until the next interval of CPU time allocated to the application occurs. If a process does not complete within the time allocated to the application, thread processes are completely blocked during the allocated CPU time.
Even though you can reduce the possibility of blocking during wireless communication by splitting send and receive processing into different threads, processes are blocked for a full 2 ms if the number of packets being sent and received is greater than the number that can be handled during the time system processing can execute.
7.1.3. Resetting the Allocated Time (Important)
You can reset the system core CPU time allocated to an application by calling the nn::os::SetApplicationCpuTimeLimit
function again. Resetting the allocation is useful in cases where the amount of processing by the application changes for different scenes, such as with single player and multiplayer modes. Note however, that once set there is no returning to zero, and at least 5% (or approximately 0.1 ms) of an interval will definitely be allocated to the application. Changing the allocation frequently is very risky. We recommend changing the allocation only for high level functionality such as “single player” and “multiplayer.”
Allocating system core CPU to an application has a significant effect on the wireless communication being carried out by the system. We recommend that you do not allocate system core CPU time to applications during multiplayer modes that use wireless communication. To prioritize multiplayer mode, either do not allow applications to use the system core in the first place or make sure that the amount of time allocated is short and has low real-time requirements.
For your reference, we carried out a comparison of communication status while varying the allocation time for an application (equivalent to the sync/simple demo in the CTR-Pia library) that carries out only communication processes. Results showed that communications were very stable when no system core CPU time was allocated in the first place. On the other hand, packet loss apparently proportional to the load on the system core even when threads running in the system core were not created occurred when up to 30% (approximately 0.6 ms) of a CPU time interval was allocated.
Comparison was carried out under the following conditions.
Item
Condition
Protocol
Local UDS communication
Network
Single network consisting of four 3DS systems
Number of packets
60 packets per second per unit (all set to Broadcast)
Wireless signal
Extremely good
You can change the priority of graphics processing in the system core from high to low using the nngxSetInternalDriverPrioMode
function. When graphics processing is set to low priority, the order of priority of the processes carried out in the system core changes as follows.
- Cameras
- HID (including Circle Pad Pro)
- Graphics
- Wireless Communication
Changing the priority of graphics makes no significant difference in the performance of the application.
Some CPU time of the system core is allocated to applications using nn::os::SetApplicationCpuTimeLimit
to allow the creation of threads that run in the system core.
Although running some processes in the system core allows you to increase the processes being executed by an application, some processes are best suited for execution in the system core and some are not because system core scheduling allocates CPU time in 2-ms intervals.
System processes cannot be run during CPU time allocated to an application even if the application is not using the system core at the time. The execution time of system processes, such as wireless communication, decreases by the amount of system core allocated to the application.
The CPU time allocated to an application is not synced with picture frames.
For information about system core scheduling, see the System Programming Guide included in the CTR-SDK documentation.
Processing Suited for Execution in the System Core
The system core CPU time allocated to applications is fixed. This CPU time is best suited for processes such as the following that occur regularly and are completely CPU-bound.
- Reading and writing buffers.
Examples include processes that write data (such as movie data or raw sound data) loaded in memory to a work buffer, and processes that copy data between a send/receive buffer used in wireless communication and a work buffer.
- Generating GPU commands.
- AI processes, computational processes, and so on.
Even in cases like these, processing may take more time than execution in the application core due to the graphics or sound interrupts and the fact that time is allocated in specific intervals. We recommend that you execute processes that allow a certain degree of delay.
Processes Not Suited for Execution in the System Core
Processes that are not completely CPU-bound and processes that only reoccur a few times during the course of executing an application are unsuited for execution in the system core (except when you want to emphasize the process).
Make sure to pay particular attention in cases where processes use devices other than graphics and sound-related devices. If an application calls an API function that uses such devices, that process starts when transferred to the system after the system core CPU time allocated to the application passes. In other words, even if the process completes in a short amount of CPU time, the result cannot be obtained by the application until the next interval of CPU time allocated to the application occurs. If a process does not complete within the time allocated to the application, thread processes are completely blocked during the allocated CPU time.
Even though you can reduce the possibility of blocking during wireless communication by splitting send and receive processing into different threads, processes are blocked for a full 2 ms if the number of packets being sent and received is greater than the number that can be handled during the time system processing can execute.
7.1.3. Resetting the Allocated Time (Important)
You can reset the system core CPU time allocated to an application by calling the nn::os::SetApplicationCpuTimeLimit
function again. Resetting the allocation is useful in cases where the amount of processing by the application changes for different scenes, such as with single player and multiplayer modes. Note however, that once set there is no returning to zero, and at least 5% (or approximately 0.1 ms) of an interval will definitely be allocated to the application. Changing the allocation frequently is very risky. We recommend changing the allocation only for high level functionality such as “single player” and “multiplayer.”
Allocating system core CPU to an application has a significant effect on the wireless communication being carried out by the system. We recommend that you do not allocate system core CPU time to applications during multiplayer modes that use wireless communication. To prioritize multiplayer mode, either do not allow applications to use the system core in the first place or make sure that the amount of time allocated is short and has low real-time requirements.
For your reference, we carried out a comparison of communication status while varying the allocation time for an application (equivalent to the sync/simple demo in the CTR-Pia library) that carries out only communication processes. Results showed that communications were very stable when no system core CPU time was allocated in the first place. On the other hand, packet loss apparently proportional to the load on the system core even when threads running in the system core were not created occurred when up to 30% (approximately 0.6 ms) of a CPU time interval was allocated.
Comparison was carried out under the following conditions.
Item
Condition
Protocol
Local UDS communication
Network
Single network consisting of four 3DS systems
Number of packets
60 packets per second per unit (all set to Broadcast)
Wireless signal
Extremely good
You can reset the system core CPU time allocated to an application by calling the nn::os::SetApplicationCpuTimeLimit
function again. Resetting the allocation is useful in cases where the amount of processing by the application changes for different scenes, such as with single player and multiplayer modes. Note however, that once set there is no returning to zero, and at least 5% (or approximately 0.1 ms) of an interval will definitely be allocated to the application. Changing the allocation frequently is very risky. We recommend changing the allocation only for high level functionality such as “single player” and “multiplayer.”
Allocating system core CPU to an application has a significant effect on the wireless communication being carried out by the system. We recommend that you do not allocate system core CPU time to applications during multiplayer modes that use wireless communication. To prioritize multiplayer mode, either do not allow applications to use the system core in the first place or make sure that the amount of time allocated is short and has low real-time requirements.
For your reference, we carried out a comparison of communication status while varying the allocation time for an application (equivalent to the sync/simple demo in the CTR-Pia library) that carries out only communication processes. Results showed that communications were very stable when no system core CPU time was allocated in the first place. On the other hand, packet loss apparently proportional to the load on the system core even when threads running in the system core were not created occurred when up to 30% (approximately 0.6 ms) of a CPU time interval was allocated.
Comparison was carried out under the following conditions.
Item |
Condition |
---|---|
Protocol |
Local UDS communication |
Network |
Single network consisting of four 3DS systems |
Number of packets |
60 packets per second per unit (all set to Broadcast) |
Wireless signal |
Extremely good |