PI V1.9 disables WLAN

1

Yesterday I upgrated to V1.9.
Now, when I start the Script the WLAN Adaper is diabled after a short while…
I posted this at PI Forum, here I´ve got a reply: Third Party Script, not a Pixinsight issue.
HP Envy 360, 64Gb, Win 11 24H2, lates official.

2

I find it a bit odd that there are quite a lot of hardware issues. But they are mostly on Mac, I guess the Qt library causes the problems there.

I am using an Intel desktop with Windows 11, no problems for me. I do not have 24H2 yet, though.

There are few places where AutoIntegrate could potentially access the WLAN adapter. During Image solving, the Image Solver script may access the Vizier database (if I remember it correctly). But AutoIntegrate just calls a script that comes with PixInsight. Then if you click the document button it will open a web page, again using PixInsight services.

I believe there are some scripts that more actively access the WLAN adapter (I mean, use internet access) but killing the adapter from Javascript is not very likely. Or if that is possible, then it really is a bug in the Javascript. Some tools that come as an external process, it may be a more likely candidate.

Jarmo

3

Hi !

What is this script you call with your script? So I can try to reproduce this directly.

I find it strange that they deleted my Post at Bug Report without any comment.

4

I can see your post in Support Questions. I guess they do not like bug reports if it involves non-PixInsight components. I know that if you can present a reproducible test case, they will fix it. But in your case it may not be possible if it is a combination of PixInsight and non-PixInsight components like WIndows and hardware.

I am referring to Script / Astrometry / ImageSolver. I do not know if it is even called in your workflow, though.

I think there could be at least a few things to try:

  1. Run the script with defaults settings. Then it uses only native PixInsight components. And then it should not call for example ImageSolver.
  2. The problem could be related to PixInsight using all resources. In Edit / Global Preferences / Parallel Processing and Threads you can try to change some settings.
    2.1. For example limit the Maximum number of processor threads used to something like half of those available in your system,
    2.2. A new thing in 1.9.0 is that the default thread priority is Time Critical. Lowering that might help.

If some threading options help to remove the problem then they might respond and change some default settings. And at least you can get your system running without problems.

Jarmo

5

Hi,

I found my Post. Did you see my Reply? I can reproduce it with the “Weighted Batch Preprocessing Script V2.8.0”

I used it with no spcial settings

What do you think?

6

Just checked it.

I suggest you try lowering thread priority in PixInsight (point 2.2). If that helps then you can argue that it is related to changes in PI 1.9.0. Anyway Time Critical priority does not sound good to me.

Jarmo

7

Well,
I reduced as you mentioned Threat Priority from Time Critical to High. Now its working and Wlan is not dissapearing

Thanks for your Help. What should I do now at PI Forum?

CS
Reiner

8

Great to hear that your problem is solved!

I think you should report the solution as others may see the same issue. I am not sure if you should mention it in the old thread as it is already marked “cannot reproduce”. But then, it will be the same for a new thread too as it does not reproduce on all machines.

Maybe still a new thread with a new title like “Time Critical thread priority breaks network connection on some machines”? And then explain your experiment with WBPP. They really should be interested in your findings as this is new to 1.9.0. And I am sure they are, as long as it does not get dismissed for the wrong reason. Obviously they have a lot of stuff to go through.

Anyway, those are my suggestions and obviously you need to do what you feel is the best.

Regards,
Jarmo

9

This is from Perplexity:

Using time-critical thread priority carries several significant risks:

  1. System instability: Time-critical threads can interfere with essential system processes, potentially disrupting normal system operations[
  2. Resource starvation: High-priority threads may monopolize CPU time, leading to starvation of lower-priority threads and processes
  3. Unpredictable behavior: Overuse of high-priority threads can make program behavior unpredictable and difficult to debug, especially in multi-threaded environments
  4. Performance degradation: Contrary to expectations, using time-critical priority can lead to performance bottlenecks and overall system slowdowns
  5. Deadlock potential: Poorly managed thread priorities can contribute to deadlock scenarios
  6. Platform inconsistency: Thread priority handling is platform-dependent, leading to inconsistent behavior across different operating systems
  7. Scheduler conflicts: Time-critical threads may interfere with the operating system’s scheduler, potentially causing scheduling issues for other processes

To mitigate these risks, it’s generally recommended to use normal priority for most threads and let the operating system handle scheduling. Only use higher priorities sparingly for truly time-sensitive tasks, and thoroughly test across different platforms to ensure consistent behavior[

10

Hi !
Just FYI,

since V1.92 I went backt to Time-Critical and all Processors. Now without the WLAN-Issue.

Regards
Reiner

11

Interesting info! I wonder if they actually changed something in threading.

Jarmo