I'm noticing on my system that when scheduling 4 threads on a 2TB SSD with a phase 1 limit set to "1", that the 4th thread never starts as it continually rolls back to the phase 1 limiter. This is on a pretty fast plotter.
I know from manually scheduling plotting in the past, that the system can get better overall performance than this by having the 4th thread running. Threads completion is averaging 6.5 hours, but the sweet spot is is about 7.5 hours per plot.
I realize that there are ways around this, but I have a suggestion that could improve this situation, and maybe some other situations, and I am betting it would be pretty simple to add to the project.
My suggestion is that a context menu is added to the jobs queue list, with an option to "start now" or something to that effect for any queued thread. This would allow me to bypass the 1st phase limiter for the 4th thread, but then the subsequent individual thread performance hit would cause the 4th thread to fall back into the "1st phase limit waiting state" and get my up to the performance sweet spot of 4 concurrent threads on the drive, while still avoiding excessive resource usage spikes caused by multiple threads all eventually drifting into concurrent phase 1 operations.
I'm noticing on my system that when scheduling 4 threads on a 2TB SSD with a phase 1 limit set to "1", that the 4th thread never starts as it continually rolls back to the phase 1 limiter. This is on a pretty fast plotter.
I know from manually scheduling plotting in the past, that the system can get better overall performance than this by having the 4th thread running. Threads completion is averaging 6.5 hours, but the sweet spot is is about 7.5 hours per plot.
I realize that there are ways around this, but I have a suggestion that could improve this situation, and maybe some other situations, and I am betting it would be pretty simple to add to the project.
My suggestion is that a context menu is added to the jobs queue list, with an option to "start now" or something to that effect for any queued thread. This would allow me to bypass the 1st phase limiter for the 4th thread, but then the subsequent individual thread performance hit would cause the 4th thread to fall back into the "1st phase limit waiting state" and get my up to the performance sweet spot of 4 concurrent threads on the drive, while still avoiding excessive resource usage spikes caused by multiple threads all eventually drifting into concurrent phase 1 operations.