Max Concurrency Use for Command Line

Hi All - Quick question. When running via command line, I have a “max concurrency” value specified in my input file (value is 48 on a 48 core, 256GB dedicated machine)…

I think this is quite low and I might be imposing core/RAM limitations resulting in slower than desired processing time. When using WebODM docker would do a nice job maximizing things when “max concurrency” was set to default. Should I remove my specified value for command line as well? or Manually increase it? Thanks in advance.

What’s low about 48 threads on a 48 thread machine? I’m not sure I’m understanding what you’re looking to do.

Could you please clarify?

Hi Saijin, Thanks you for the response and sorry for the confusion. I have begun transitioning from WebODM to command line operation. In doing so, I’ve noticed back to back runs (both data set and parameters) taking significantly longer when using command line (both using Docker)…and was just looking to understand if this setting might be part of the reason.

In WebODM I do not specify a value (leaving default which looks to be estimated based on the machine variables), however in command line I am specifying a value (48). I was just looking to understand if this could be part of the increased processing time from command line? and/or if there is something else that might be driving this?

Thanks again.

1 Like

Ah, thanks for the clarification.

It’d be hard to say without having the full set of processing parameters for both your WebODM and Docker runs of the same data.

But in general, as you’ve noted, not passing the max-concurrency will let both WebODM and ODM on commandline decide to use N-number of threads on the machine (8 for me, 48 for you) without worry. Something else must be going on.

Is the chip hyper threaded? If that’s the case, webodm might do 96 threads.

1 Like

Thank you both for the feedback. I have done some more comparison work, testing, and digging. I seems like opensfm is using 100% of 1 out of 48 (96 threads) cores. This is where webODM seems to be moving much faster. The earlier and later stages seem to be fine. Any thoughts on why this could be?

1 Like

There are a few parts of the pipeline that are single-threaded, but I don’t think that’d be any different between ODM on commandline vs WebODM.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.