task priorities: raise CONNECT and TCPIP_THREAD to osPriorityNormal#5205
Draft
bkerler wants to merge 1 commit intoprusa3d:masterfrom
Draft
task priorities: raise CONNECT and TCPIP_THREAD to osPriorityNormal#5205bkerler wants to merge 1 commit intoprusa3d:masterfrom
bkerler wants to merge 1 commit intoprusa3d:masterfrom
Conversation
During active printing, media_prefetch temporarily raises the async executor thread to TASK_PRIORITY_MEDIA_PREFETCH (osPriorityNormal) for the duration of each fetch_routine call. With TASK_PRIORITY_CONNECT and TASK_PRIORITY_TCPIP_THREAD both at osPriorityBelowNormal, this caused two distinct failures: 1. "net fail" / Connect drops offline while printing (issue prusa3d#5167). The TCPIP thread could not process incoming TCP segments or send ACKs while prefetch was running. The Connect task was also starved, missing the 4-second WebSocket telemetry window and eventually the 15-second ping-inactivity threshold, causing the server to mark the printer offline. 2. "G-Code transfer running too slow" when printing from Connect (issue prusa3d#5174). When printing via inline WebSocket streaming, the Connect task receives chunks from the server and writes them to the partial download file. Media prefetch reads that same file. With prefetch elevated above Connect, Connect could not write new chunks while prefetch was reading — a priority inversion where prefetch hit RESULT_OUT_OF_RANGE on data that the starved Connect task had not yet delivered. Fix: raise both tasks to osPriorityNormal so they are peers of the elevated prefetch thread rather than subordinates to it. They now share CPU fairly with media prefetch during I/O, which is the same relationship the old dual-priority scheme (TASK_PRIORITY_MEDIA_PREFETCH _WHILE_FREAD) provided before BFW-5653 removed it. TASK_PRIORITY_WUI is left at osPriorityBelowNormal (local PrusaLink remains functional and is latency-tolerant). TASK_PRIORITY_ASYNC_JOB_ EXECUTOR remains at osPriorityBelowNormal; the executor only needs elevation during active fetch work, which fetch_routine already handles via osThreadSetPriority.
bkerler
changed the title
Author
|
Moved to draft as Prusa devs said that raising priorities (race print vs. tcpip) is not an option |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
During active printing, media_prefetch temporarily raises the async executor thread to TASK_PRIORITY_MEDIA_PREFETCH (osPriorityNormal) for the duration of each fetch_routine call. With TASK_PRIORITY_CONNECT and TASK_PRIORITY_TCPIP_THREAD both at osPriorityBelowNormal, this caused two distinct failures:
"net fail" / Connect drops offline while printing (issue [BUG] CORE One L 6.5.3. beta connect "net fail" drop out #5167). The TCPIP thread could not process incoming TCP segments or send ACKs while prefetch was running. The Connect task was also starved, missing the 4-second WebSocket telemetry window and eventually the 15-second ping-inactivity threshold, causing the server to mark the printer offline.
"G-Code transfer running too slow" when printing from Connect (issue [BUG]Error while printing with Prusa Connect, "G-code transfer running too slow", print stops/fails 6.5.3-RC #5174). When printing via inline WebSocket streaming, the Connect task receives chunks from the server and writes them to the partial download file. Media prefetch reads that same file. With prefetch elevated above Connect, Connect could not write new chunks while prefetch was reading — a priority inversion where prefetch hit RESULT_OUT_OF_RANGE on data that the starved Connect task had not yet delivered.
Fix: raise both tasks to osPriorityNormal so they are peers of the elevated prefetch thread rather than subordinates to it. They now share CPU fairly with media prefetch during I/O, which is the same relationship the old dual-priority scheme (TASK_PRIORITY_MEDIA_PREFETCH _WHILE_FREAD) provided before BFW-5653 removed it.
TASK_PRIORITY_WUI is left at osPriorityBelowNormal (local PrusaLink remains functional and is latency-tolerant). TASK_PRIORITY_ASYNC_JOB_ EXECUTOR remains at osPriorityBelowNormal; the executor only needs elevation during active fetch work, which fetch_routine already handles via osThreadSetPriority.