low cpu utilization on cam path generation

[lekonna]

Hi, 

How can i check what is bottle-necking the cam from utilizing the system resources better? If i run a complicated adaptive tool path, my overall cpu utilization is around 20%, which leaves a lot on the table and in essence means that i'm waiting 5 times as long as i should for the task to finish ?

When i generate the paths, fusion first spawns 3 cam kernel tasks that momentarily utilize bit more resources and then is left with only 1 that doodles around 20-30% utilization, peaking in the 43% range for the rest of the generation. 

It doesn't seem that i'm memory or IO bound here, so the only thing seems to be the CAM performance, which i would assume even without parallelism would consume 100% of a single threads performance. 

[lekonna]

Hi, 

How can i check what is bottle-necking the cam from utilizing the system resources better? If i run a complicated adaptive tool path, my overall cpu utilization is around 20%, which leaves a lot on the table and in essence means that i'm waiting 5 times as long as i should for the task to finish ?

When i generate the paths, fusion first spawns 3 cam kernel tasks that momentarily utilize bit more resources and then is left with only 1 that doodles around 20-30% utilization, peaking in the 43% range for the rest of the generation. 

It doesn't seem that i'm memory or IO bound here, so the only thing seems to be the CAM performance, which i would assume even without parallelism would consume 100% of a single threads performance. 

[seth.madore]

Does this happen on all your files, or specific ones? Can you share a file that is doing this?
File > Export > Save to local folder. Return to thread and attach the .f3d file in your reply

[seth.madore]

Does this happen on all your files, or specific ones? Can you share a file that is doing this?
File > Export > Save to local folder. Return to thread and attach the .f3d file in your reply

[lekonna]

Happens on most files, just while making an example file (cannot share the original one) I noticed that on the first time i generated the second adaptive, the CPU load stayed at 100% for much longer, then on the second generate it drops down more quickly:

first one:

on the first run, the cpu stayed at 100% for 20 seconds, 

on the second run:

It stayed at 100% only for 10 seconds.  Overall time to generate this particular example on my machine is 50 seconds. The CPU is not throttling, max CPU temp on any core is 66C during this generation.  

example file attached. Note that the time on this kinda file is pretty irrelevant, the complex ones that do lot of operations based on previous stock is where it gets tedious.

[lekonna]

Happens on most files, just while making an example file (cannot share the original one) I noticed that on the first time i generated the second adaptive, the CPU load stayed at 100% for much longer, then on the second generate it drops down more quickly:

first one:

on the first run, the cpu stayed at 100% for 20 seconds, 

on the second run:

It stayed at 100% only for 10 seconds.  Overall time to generate this particular example on my machine is 50 seconds. The CPU is not throttling, max CPU temp on any core is 66C during this generation.  

example file attached. Note that the time on this kinda file is pretty irrelevant, the complex ones that do lot of operations based on previous stock is where it gets tedious.

[johnswetz1982 · Accepted solution]

On an [Adaptive] toolpath you would almost never get 100% utilization. The reason being is that with multiple [step downs] the results from the first are needed for the second, etc. This is the same reason most video games do not run on more than one thread. The second point you made has to do with having different [step downs] and [stock to leave] settings. Make sure the setting are the exact same to do an apples to apples comparison. 

[johnswetz1982 · Accepted solution]

On an [Adaptive] toolpath you would almost never get 100% utilization. The reason being is that with multiple [step downs] the results from the first are needed for the second, etc. This is the same reason most video games do not run on more than one thread. The second point you made has to do with having different [step downs] and [stock to leave] settings. Make sure the setting are the exact same to do an apples to apples comparison. 

[lekonna]

Hi, thanks for the update. i was kinda expecting to see single thread
atleast utilized to 100%. but i do understand the reasonong, thanks for
checking it out!

[lekonna]

Hi, thanks for the update. i was kinda expecting to see single thread
atleast utilized to 100%. but i do understand the reasonong, thanks for
checking it out!

[Anonymous]

I have the same issue, waiting 10-20 minutes for a 3D adaptive toolpath (rest machining) to compute, while CPU sits at 20% utilization overall, and no core ever goes over 80%, even for a second, with all cores below 70% the rest of the time. This is on the latest software and a pretty high-end windows machine (10700K CPU, lots of RAM, disk, 3080 RTX video card). What is the bottleneck here?

I can only assume there is some problem with the algorithm, even if it's single-threaded, if it doesn't use even a single core close to max.

[Anonymous]

I have the same issue, waiting 10-20 minutes for a 3D adaptive toolpath (rest machining) to compute, while CPU sits at 20% utilization overall, and no core ever goes over 80%, even for a second, with all cores below 70% the rest of the time. This is on the latest software and a pretty high-end windows machine (10700K CPU, lots of RAM, disk, 3080 RTX video card). What is the bottleneck here?

I can only assume there is some problem with the algorithm, even if it's single-threaded, if it doesn't use even a single core close to max.

[johnswetz1982]

There is a alot that can go into this. Do you have [Stay down] amount set to most or least or somewhere in between? The processor in your computer has many sub components, so these algorithm may be using the floating point compute units but not the other to full utiiazation. Also the fact still does not change that you have to have the results of some calculations before you can use those for the inputs of later calculations. I am not sure any CAD/CAM software would be able to utilize a PC to 100%.

[johnswetz1982]

There is a alot that can go into this. Do you have [Stay down] amount set to most or least or somewhere in between? The processor in your computer has many sub components, so these algorithm may be using the floating point compute units but not the other to full utiiazation. Also the fact still does not change that you have to have the results of some calculations before you can use those for the inputs of later calculations. I am not sure any CAD/CAM software would be able to utilize a PC to 100%.

[Anonymous]

Good points, but nonetheless something seems to be not working as it should. My stay-down is set to "least".

If it's calculating a toolpath, something has to be the rate-limiting step, and it doesn't seem to be the CPU, based on the load of each CPU core. My web browser uses as much or more CPU than the toolpath generation, and it's taking an age. And no other system component indicates it's being taxed at all. Floating point benchmark tests make one or more cores go to 100%. (That doesn't mean every single transistor in the CPU is being used all the time, but it does mean the CPU is calculating as fast as it can.)

This is not just academic to me. One of my finishing (rest machining) passes is taking so long to calculate, I've given up and I'm going to to the finishing by hand if I have to. Happy to share the file for this if it would help.

[Anonymous]

Good points, but nonetheless something seems to be not working as it should. My stay-down is set to "least".

If it's calculating a toolpath, something has to be the rate-limiting step, and it doesn't seem to be the CPU, based on the load of each CPU core. My web browser uses as much or more CPU than the toolpath generation, and it's taking an age. And no other system component indicates it's being taxed at all. Floating point benchmark tests make one or more cores go to 100%. (That doesn't mean every single transistor in the CPU is being used all the time, but it does mean the CPU is calculating as fast as it can.)

This is not just academic to me. One of my finishing (rest machining) passes is taking so long to calculate, I've given up and I'm going to to the finishing by hand if I have to. Happy to share the file for this if it would help.

[johnswetz1982]

Yes, if you can share please do. If there is something broken or buggy and it can be reproduced that at lest is a step in the direction of getting it fixed (If there is something wrong). Certainly more experienced users can chime in.

[johnswetz1982]

Yes, if you can share please do. If there is something broken or buggy and it can be reproduced that at lest is a step in the direction of getting it fixed (If there is something wrong). Certainly more experienced users can chime in.

[Anonymous]

Thanks for the help.

On further investigation, I believe I have two problems mixed together. One is slow toolpath generation, and one is already documented here (https://knowledge.autodesk.com/support/fusion-360/learn-explore/caas/sfdcarticles/sfdcarticles/Adapt...). This muddies the waters quite a bit, and so I don't think my file is a good one to test toolpath generation times.

I will post here if I encounter this problem with other toolpaths.  

[Anonymous]

Thanks for the help.

On further investigation, I believe I have two problems mixed together. One is slow toolpath generation, and one is already documented here (https://knowledge.autodesk.com/support/fusion-360/learn-explore/caas/sfdcarticles/sfdcarticles/Adapt...). This muddies the waters quite a bit, and so I don't think my file is a good one to test toolpath generation times.

I will post here if I encounter this problem with other toolpaths.