Slow pixel integration in APP 2.0 Beta 19?

Update:  I had made some assumptions about when the integration actually started last night.  After logging the time/position information in the overall pixel integration, it's now looking like it'll take about 5 days.  This may improve further as I have more time/position recordings, but it still seems very slow.  I'll report back further tonight.

Unfortunately it seems to have slowed from my earlier estimates.  Since checking 7 hours ago, it has only integrated another 4.5 million out of 256 million px.

I wonder if me using the external drive for the APP working folder is the cause, but again, I'm seeing only intermittent reads and rare writes and they are consuming only a tiny fraction of the bandwidth of this drive.  Maybe something in the application switches to single-threaded mode when using an external drive?  I have no idea.

I'll likely let this run overnight, but since I'm only 1/23rd of the way done I will probably kill it in the morning and try either DSS (always fast) or PI.  I may also make a duplicate of my integration files and try running the same process on my Intel laptop just to see if it runs any faster.  Only 32GB RAM there, though...

Yes an external drive will slow down things a lot, we always advice to use the internal storage and preferably a SSD (or a very fast external SSD with very fast connection). I would advice to not use LNC to start with, and integration 100 subs at a time. You'll end up with 4 integrations which you can load in again as lights and integrate those again to get the final result, this won't impact the quality.

@vincent-mod Hi Vincent, have you folks verified that integrating in small chunks and then integrating the final results together doesn't impact quality.   I've read on forums that you get higher quality results with integrating all at once.

I ask because integrating in chunks would be a better solution for me in some cases if I was fairly confident it wouldn't impact quality.

Also, if I integrate in 4 chunks, what integration method should I use.  I would think these would have very high SNR so you would want to average them, but it looks like the default is median for a small number of frames?   Should I make a specific choices if its 4 chunks vs 10 chunks vs 20 for example?

@vincent-mod Interesting, breaking up the workload like that.  I can try it, with the hope that the effective throughput rate of the 4 integrations is less than trying it all at once.  Hopefully it really doesn't affect quality.  

Also:  I should have clarified, I am using very fast external SSD.  It's limited by the interface, but it's still 1 GB/sec actual throughput, and as I said according to my OS it is just not being utilized much.  It seems to me like APP is doing something that A) isn't using much CPU, B) isn't using much GPU, and C) isn't using much disk IO -- but is still taking a long time.  There might be something going on that is throttling resource consumption (which is why I asked if anything could be going single-threaded there; generally if you have a long-running process you want it to use as many system resources as possible -- subject to the thread control slider, of course).

At the moment, I killed the large integration and disabled 2x drizzle, so now it's running much faster with 1/3 the disk used.  With 2x drizzle I'd expect 4x longer, not 25x longer.

Sorry for missing your replies. Theoretically all at once is better, but when you're combining say 50 lights with all the proper calibration data, dithering etc. then it won't really show a difference.