SBC vs Standalone HUGE Performance Differences
-
Hello to all,
We are doing some performance tests and we don't quite understand what happens in the following case:
The same configuration files executed in standalone mode on a Duet3D 6XD board take about 1 second to make it available, but on the SBC (same configuration) take about 15 seconds.
What could be the reason for this huge performance difference? In both cases the functionality is identical, there are no bugs and the only difference is the performance (the time to load macros, variables and settings, which are identical).
The SBC config is runing in a 8Gb Raspberry Pi 4B with an identical SD card as when used in standalone mode.
As we said, both configuration files are identical. How is this possible if the 6XD hardware is inferior to the RPI?
What makes the difference?
-
@Marcossf 'm not sure what your "configuration" is doing, but you may find the following post of interest: https://forum.duet3d.com/topic/25960/macro-files-sbc-v-standalone?_=1683121057324
-
@gloomyandy Thank you, we had have a look to your post. We appreciate.
Still we guess whats the diference in performance with identical configs. No errors, working in both cases and the only difference is the aditional time SBC takes in load the config/macro/whatever.
Unfortunately we can't reveal our configurations and code, but they are complex as they are not running on a standard 3D machine, but the machine is 100% functional.
We are trying to speed up some conditional loops and slow processes by iterations, because of the lack of arrays in a stable version.
Our logic is that with Standalone, due to pure HW power, everything should be slower than in SBC, and the opposite is true. -
@Marcossf have you corrected for RPi startup time and wifi configuration? I.e., check dsf logs to see when the configuration is actually processed.
I cant say I am surprised the Raspbian underlying the DuetPi image takes longer to boot than the standalone board. There are some ways to bring RPi (re) boot time down to 3 seconds but when I suggested them way back (mainly removing dependency conditions causing dsf to start late) I was told that these changes would be unsupported and may introduce hard to debug and spuripus errors.
You can already shave off some boot time from thr RPi by booting from a USB connected SSD and by using Ethernet instead of WiFi.
-
@oliof said in SBC vs Standalone HUGE Performance Differences:
RPi by booting from a USB connected SSD
I had good performance with the RasPiKey, an eMMC memory card.
I had bad USB3.0-SSD adapters slowing traffic down to USB2.0 speeds at startup. (they run fine after a reboot)I've also seen 256GB SD-cards with high performance figures. But never tested, if they are RPi compatible...
There are bigger cards (upto 2TB!) but the Pi limit is 256GB.@Marcossf Comparing Duet3 with RPi is like watching a squirrel vs. elephant chasing peanuts. The squirrel always wins, because it's more determined
-
@Marcossf Hard to say without any configuration files - I reckon you are using v3.4? There have been notable performance improvements in v3.5 to speed up code execution + flush requests used by all sorts of conditional statements. During prints I don't think you should see any performance impacts in v3.4 or later.
-
@oliof Good point, we will testing with two images, one from scratch Raspbian and other taken from Duet3D repository. But that only will show the performance in SBC mode. We get a big difference in performance in standalone mode with exactly the same configuration. We need SBC mode as we run other services and dependencies apart from DFS and DWC.
@o_lampe We are running it in a official Raspberry PI 4 B 8Gb and a SD card (Sandisk 64gb class 10 100Mb/s). The start-up is not the problem, it is the time difference in the execution of configurations, loops, macros and variables between SBC and Standalone.
@chrishamm In 3.4.5 stable it takes 11 seconds to load our configuration files in SBC mode. The same config in standalone mode takes 2 seconds.
And, in 3.5 beta3 it takes 5 seconds to load the same configuration in SBC mode. In standalone 3.5beta3, the same 2 seconds that it takes in the 3.4.5 stable in standalone mode. It's 3.5beta3 without using arrays, exactly the same code.
If we use arrays in 3.5beta3, it improves even more the performance in any of the modes due to the logical optimization of the code. But it still wins in runtime standalone vs SBC.
-
@Marcossf Conditionals take longer than in standalone mode because DSF relies on RRF to parse expressions and to return a response before DSF can proceed with code execution. There is no easy way to change this, even though 3.5 will bring notable performance improvements as you already saw. We're considering to improve the SPI communication timing further, but we have yet to evaluate how much that could help.
In addition, I am happy to check if there are any other bottlenecks slowing down the execution of your configuration provided you can share it with me (e.g. via email to christian@duet3d.com). Of course I would handle this confidentially.
-
@chrishamm Thanks Christian, it makes sense. This is not usually a problem for people in general, as waiting a few seconds longer is not a decisive factor, but in some automated processes, gaining seconds is vital for us.
I will discuss with our client whether dealing with you privately and confidentially on this matter could violate the NDAs signed with them.
I don't think there will be a problem. In the end it benefits all of us.Best,
