I'm running KStars (v.2.5.0 with KDE Frameworks 5.9.0) as a client on Xubuntu (15.10) on a Dell Latitude D830 laptop. When KStars is first launched the kstars process consumes ~15% (according to 'top') and KStars is very usable. However, after about 10 minutes of normal operation (doing nothing other than scrolling around the KStars sky and looking at stuff), KStars starts hogging CPU, getting to between 60% and 80%; the lag makes it pretty much unusable at the point. The laptop has Intel Core 2 Duo T7100/1.8 GHz processors and 4 Gbytes RAM. The RAM is never more than half used, the swap file is unused. I am running the correct NVIDIA drivers for the graphics card. When it gets into this state only a reboot will fix it. If I just close and restart KStars it takes a very long time to load and the kstars process still consumes between 60% and 80% of CPU when just sitting there idle. I'm very happy if there's a workaround or some tuning required for this: I really want to use KStars! Reproducible: Always Steps to Reproduce: 1. Start kstars. 2. Scroll around looking at the sky for more than 10 minutes. 3. Wait for things to slow down. Actual Results: The kstars process was using between %60 and %80 of CPU and the lag caused it to be unusable. Expected Results: The kstars process to consistently consume no more than 20% to 30% CPU when idle. The processing system has Intel Core 2 Duo T7100/1.8 GHz processors and 4 Gbytes RAM. The RAM is never more than half used, the swap file is unused. I am running the correct NVIDIA drivers for the graphics card (nvidia-340). My intention is to use Ekos as a client with remote Indi but the above happens without any of that running.
One more thing: before running on Xubuntu I had tried KStars on Ubuntu and the situation was the same.
FYI, I've tried disabling all OpenGL items in the NVidia X Server Settings dialogue and selecting "High Performance" for the image settings rather than "Quality", then rebooting. I've also tried switching off stars, planets and deep-sky objects in the KStars screen so that it is just ground and black sky. Nothing makes a difference so far.
Dear Rob I'm sorry that this is happening. Such an issue is rather hard to debug, unless we can find out what KStars is doing / spending time on. If we can isolate the problem a bit more and find what can be disabled to prevent this, we could introduce a patch that has timers to further trace the issue. The other option, if it works is to run KStars on valgrind with callgrind, keep the machinery off until the problem begins, and then turn on the machinery to investigate what KStars is spending most of its time. I didn't read this anywhere in your post, but have you tried turning off the simulation clock? Does that have any impact? I had a similar issue a while ago with simulation clock running. If the simulation clock being off ameliorates the problem, a temporary solution would be to keep it off and update the time once every minute using a DBus command like this: while true; do qdbus org.kde.kstars /KStars org.kde.kstars.setTimeToNow; sleep 55; done;
It's very hard to confirm this. I just left KStars running for 3 days straight and came back to only 11% CPU usage. Not different from what it started at 3 days ago. It's usually some issue with graphics driver.
Thanks for the comments guys. I agree that this is likely some interaction with the graphics driver. I suggest that we keep this open while I experiment with settings so that we can track the resolution here. I'll also see if I can find the simulation clock in the settings and get valgrind running. It will take a little time to do, hopefully I'll get back with more information next week.
Created attachment 98551 [details] Callgraph for KStars when in "slow down" state This is a callgraph output from kcachegrind after I loaded it with callgrind output from a session where kstars was started off and got into it's "slow" state.
Above I've added a callgraph that was generated as follows: - Clean reboot of computer - Start kstars under callgrind to generate a callgrind log - Wait for it to get to about 20% loaded NGIC/IC objects - Give up 'cos I know it's going to take too long running this way - Now start kstars in the normal way and find that it is running very slowly - Use kcachegrind to generate the call tree. Now of course this may not necessarily be the case in question but it is most definitely a slow-down and it definitely occurred while starting kstars. Unfortunately I managed to delete the callgrind file while attempting to zip it (:-() so I only have the call tree above and, I will next load, a screenshot from kcachegrind.
Created attachment 98552 [details] kcachegrind overview The top-level view from kcachegrind of the callgrind tree. Detailed views for each kstars element above the 20% mark follows.
Created attachment 98553 [details] kcachegrind screenshots for each item > 20% (part 1) Detailed views for each kstars element in the callgrind tree above 20% (part 1).
Created attachment 98554 [details] kcachegrind screenshots for each item > 20% (part 2) Detailed views for each kstars element in the callgrind tree above 20% (part 2).
In case there is anything that looks unusual, I do still have the callgrind output loaded in kcachegrind and i will [attempt to remember to] not close kcachegrind or shut down the computer...! Rob
Created attachment 98568 [details] HTMesh_performIntersection callgraph One thing: RangeConvex::testTrixel() seems to be recursive: surely that's not good? Rob
Created attachment 98674 [details] EKOS window freezes 1 OK, let's try a different attack. The attached callgrind output was taken as follows: - Run kstars with Valgrind but with callgrind instrumentation off (valgrind --tool=callgrind --instr-atstart=no kstars) - Use kstars and find that Ekos window freezes up; I can't cause close it or cause other dialogue boxes to appear - Switch on callgrind instrumentation (callgrind_control -i on) - Wait a few seconds and switch callgrind instrumentation off (callgrind_control -i off) Rob
Created attachment 98675 [details] EKOS window freezes 2 This is another case of the same EKOS window freezing, captured in the same way. Rob
Created attachment 98676 [details] Normal case for comparison This is a normal case, no EKOS window freezing, for comparison. Note that I'm not at all sure that these frozen windows are exactly the same as the slow-down I saw originally.
Hi Rob, I just made a change that should help performance. If you're using my PPA, please wait until tomorrow and then update and try the new version.
That's excellent news, I'll update tomorrow and let you know how it goes. Many thanks. Rob
Hi Jasem. I tried sudo apt-get install kstars-bleeding ...last night but no update. Should I have seen one?
If you update now you should see a newer version
Ah, yes, got it now, testing...
Any update?
I've not reached a conclusion yet, but results so far suggest: - the latest KStars may be slightly better but the slow down is still there (sorry!) - switching off as much OpenGL as I can in the video driver doesn't help - pausing the KStars clock at launch doesn't help - I needed to increase the speed/use of my CPU fan to keep improve laptop performance in general That said, I've now performed four sessions, rebooting inbetween, without a slow down and the only difference is that setting in KStars to use the computer for time/location etc. rather than the devices. I'm going to leave it running for the evening and then I will try switching KStars back to using device for time/location to see if the problem then comes back. KStars/Ekos/Indi is sooo sweet with this problem resolved, I'm really looking forward to using it for real. :-)
OK, I think I have confirmed to my satisfaction that there are two things going on here: 1. My laptop sometimes suffers from a generic slow-down which seems to be connected with the fan not running aggressively enough. Looking at the core temperatures they don't _seem_ excessive (not much more than 60 C worst case) but running the fans more aggressively seems to have removed that problem. 2. Irrespective of (1), if I tell KStars to get time/location etc. from the device rather than from the computer then, sometimes immediately, sometimes after a little while, KStars slowly starts to freeze up. I can see CPU usage start pulsing to max and then I can see 100% of one CPU used, etc. Maybe some sort of beating going on as clocks slip? Or maybe something wrong in my EQMod driver configuration? Anyway, unless you want me to do more experimentation, I'm happy with the workaround of setting KStars to use the computer for time/location as that is more natural for me in any case.