Running parallel copies of NTLite??
- Thread starter garlin
- Start date
garlin 
OK, UI objection noted, will add right-click on editions to "Load in another instance" in one of the upcoming updates.
Multi-instancing helps a lot to speed up productivity if editing more than one image.
There's been a lot of work on it since v2.0? to not clash operations of one instance with another, it's much more complex than it seems at first.
Now it's ready for prime time, also why there is the core of it being used for parallel integration for editions on the same image since the last few updates.
That was the first stage of making this ability more visible - automatically used if using Reapply tasks to other editions option on the Apply page.
Second was unloading all mounted images, it now does it in parallel, right-click folder or WIM and choose Unload, much faster to restart edit than before.
Also when saving, it should save boot.wim in parallel with install.wim, not wait in sequence if it does not need to be.
Let me know if you see more opportunities for parallelism.
OK, UI objection noted, will add right-click on editions to "Load in another instance" in one of the upcoming updates.
Multi-instancing helps a lot to speed up productivity if editing more than one image.
There's been a lot of work on it since v2.0? to not clash operations of one instance with another, it's much more complex than it seems at first.
Now it's ready for prime time, also why there is the core of it being used for parallel integration for editions on the same image since the last few updates.
That was the first stage of making this ability more visible - automatically used if using Reapply tasks to other editions option on the Apply page.
Second was unloading all mounted images, it now does it in parallel, right-click folder or WIM and choose Unload, much faster to restart edit than before.
Also when saving, it should save boot.wim in parallel with install.wim, not wait in sequence if it does not need to be.
Let me know if you see more opportunities for parallelism.
A Core/Thread Affinity Toolbar option for each instance? ive been setting affinites in task manager(6c i5) and had smooth results in fairly heavy multitasking rather than everything using all cores.
Toolbar option to switch between Inline and Parallel processing depending on the job in hand?
edit - i would prefer to have a Settings/Preferences window instead of manually editing settings.xml and have a Set All Defaults button.
Perhaps a single multitabbed Preferences window.
Last edited:
I read the changelogs too, but if you skipped a few quarters of releases it's not going to obvious. Many casual users make an ISO, go away and return when a new Windows appears. I dropped off this forum for a year after making W7 EOL.
Agree with Clanger on managing thread affinity.
firefox(f-ton of plugins) idm and vlc all banging away on all 6 cores stutters, assign 2 cores to each smooth as butter.
i think a toolbar button for core affinity would be better/quicker than having a setting in settings.xml or a preferences window.
pop up window for affinity as tool opens.
Last edited:
NTLite_19403.1111-[date and time started? Y-M-D 00.23(example)].log
certain have mentioned this to nuhi before but package preset xml, ntlite and dism logs into zip file - OS build date+time and keep them inside Logs folder, Program Files\NTLite\Logs. add this task so it shows on Apply page so new users can see where it is. easier for users to review and upload when needed.
certain have mentioned this to nuhi before but package preset xml, ntlite and dism logs into zip file - OS build date+time and keep them inside Logs folder, Program Files\NTLite\Logs. add this task so it shows on Apply page so new users can see where it is. easier for users to review and upload when needed.
Last edited:
Thanks for the suggestions, replies below.
I think controlling is the way backwards, we need to do less, not more.
Anything longer overbloats the filename - however, now that we have a unique ID and a short filename, we could add the start time to it for better overview, will do.
I think it's more shareable in the root of the ISO (outside of WIM), as is now with the log+preset, just will replace those with something like NTLiteSession.zip
And there is the existing option to skip that backup on the Apply page.
Usually people don't want anything extra on their ISO, this way they can also easily clean it up manually.
It would include a lot of duplication and user confusion, and it's just about downloading updates, very lite/rare/relatively fast process.
Actually let's not even talk about the aesthetics, let me put it like this:
With the existing Enqueue option, downloading updates is a side-thought, you add it like it's already there and process.
My goal is to do less when possible, not more for the sake of feeling in control.
How about simply putting all parallel tasks to low priority, and let the OS do its thing?
I think controlling is the way backwards, we need to do less, not more.
The hex-looking string is actually a unique hash for the image path, so it's always the same for that image.
Anything longer overbloats the filename - however, now that we have a unique ID and a short filename, we could add the start time to it for better overview, will do.
Yeah... long time coming, will do.
I think it's more shareable in the root of the ISO (outside of WIM), as is now with the log+preset, just will replace those with something like NTLiteSession.zip
And there is the existing option to skip that backup on the Apply page.
Usually people don't want anything extra on their ISO, this way they can also easily clean it up manually.
Hm, not liking this one
It would include a lot of duplication and user confusion, and it's just about downloading updates, very lite/rare/relatively fast process.
Actually let's not even talk about the aesthetics, let me put it like this:
With the existing Enqueue option, downloading updates is a side-thought, you add it like it's already there and process.
My goal is to do less when possible, not more for the sake of feeling in control.