Poor performance in Kubuntu/Debian

Hi.
I’ve been running KiCad on Windows for quite a while, but as my work computer requires a Linux distribution, I’ve tested Kubuntu and Debian and performance is really bad in both the schematic and layout editors. It feels like the editor’s refresh rate is way lower than the monitor’s, which is already 60Hz and the more cluttered the layout gets, the more choppy the performance becomes, to the point that for my current design, it is barely usable.

I’m currently running:

Application: KiCad PCB Editor x86_64 on x86_64

Version: 8.0.3, release build

Libraries:
wxWidgets 3.2.5
FreeType 2.13.2
HarfBuzz 8.1.1
FontConfig 2.15.0
libcurl/8.7.0-DEV OpenSSL/3.1.5 zlib/1.3.1 libidn2/2.3.4 libpsl/0.21.2 nghttp2/1.58.0

Platform: Freedesktop SDK 23.08 (Flatpak runtime), 64 bit, Little endian, wxGTK, X11, KDE, x11

Build Info:
Date: Jun 4 2024 18:52:11
wxWidgets: 3.2.5 (wchar_t,wx containers) GTK+ 3.24
Boost: 1.85.0
OCC: 7.7.2
Curl: 8.7.0-DEV
ngspice: 42
Compiler: GCC 13.2.0 with C++ ABI 1018

My workstation settings are:

Processor: Intel Xeon E5-2680
RAM: 12GB DDR3
GPU: Quadro P2000

I’ve already tried using fallback graphics and updating my video card’s drivers, but it actually got worse, since now I can’t even use OpenGL any longer. Different schematics and layouts were tested, including the demo ones and they all have the same issues.

I am aware that it is an old machine, but since Windows runs KiCad just fine, I’m wondering if there is any workaround to improve performance on Kubuntu or Debian. I’ve also tested KiCad 6 and it runs way better than 8.0. Also, does this qualifies as a bug to be reported?

Thanks in advance!

1 Like

I’ve also noticed a slowdown on later KiCad versions.
In previous versions after placing a label and then depressing the [Ins] key, it could keep up with the keyboard repetition rate. Now it’s a lot slower, and labels keep on coming after releasing the [Ins] key. (I have an AMD Ryzen 5600G) This is a bit annoying and I’m also not sure how to handle this.

2 Likes

On Kubuntu you should be able to use the Ubuntu native packages instead of Flatpak. Have you tried?

My specs are:
i7-7700, 16GB DDR4, 1060 3GB (pretty similiar performancewise to your system) on Debian 12 and KiCAD v8.0.3 (from the repo) is very performant without much system load. My projects are mostly below 500 components with no noticeable performance differences between projects. So in theory it should work fine, I guess

3 Likes

I have no issues with graphics on Linux, the only thing I’ve noticed with large projects is the time to refill zones. But I guess that’s a CPU thing.

I use Fedora Linux, and my system is Ryzen 5 5600X, 32 GB RAM, Nvidia GTX 1070 and SSD disks.

I recommend using the proprietary Nvidia driver. In my experience the open source driver has a lot of issues.

If you can’t use OpenGL you will most probably have poor performance. Modern Linux desktops (KDE, Gnome) also require acceleration. Without that, the experience will suffer.

First of all, thanks for the comments! I’ll address every one of them.

@retiredfeline I was using flatpak because I was not able to add the repository via terminal. That’s what happens when I try it:

sudo add-apt-repository --yes ppa:kicad/kicad-8.0-releases
Traceback (most recent call last):
File “/usr/bin/add-apt-repository”, line 364, in
sys.exit(0 if addaptrepo.main() else 1)
File “/usr/bin/add-apt-repository”, line 347, in main
shortcut = handler(source, **shortcut_params)
File “/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py”, line 40, in shortcut_handler
return handler(shortcut, **kwargs)
File “/usr/lib/python3/dist-packages/softwareproperties/ppa.py”, line 82, in init
if self.lpppa.publish_debug_symbols:
File “/usr/lib/python3/dist-packages/softwareproperties/ppa.py”, line 120, in lpppa
self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
File “/usr/lib/python3/dist-packages/softwareproperties/ppa.py”, line 107, in lpteam
self._lpteam = self.lp.people(self.teamname)
File “/usr/lib/python3/dist-packages/softwareproperties/ppa.py”, line 98, in lp
self._lp = login_func(“%s.%s” % (self.module, self.class.name),
File “/usr/lib/python3/dist-packages/launchpadlib/launchpad.py”, line 494, in login_anonymously
return cls(
File “/usr/lib/python3/dist-packages/launchpadlib/launchpad.py”, line 230, in init
super(Launchpad, self).init(
File “/usr/lib/python3/dist-packages/lazr/restfulclient/resource.py”, line 472, in init
self._wadl = self._browser.get_wadl_application(self._root_uri)
File “/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py”, line 447, in get_wadl_application
response, content = self._request(url, media_type=wadl_type)
File “/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py”, line 389, in _request
response, content = self._request_and_retry(
File “/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py”, line 359, in _request_and_retry
response, content = self._connection.request(
File “/usr/lib/python3/dist-packages/httplib2/init.py”, line 1725, in request
(response, content) = self._request(
File “/usr/lib/python3/dist-packages/launchpadlib/launchpad.py”, line 144, in _request
response, content = super(LaunchpadOAuthAwareHttp, self)._request(
File “/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py”, line 184, in _request
return super(RestfulHttp, self)._request(
File “/usr/lib/python3/dist-packages/httplib2/init.py”, line 1441, in _request
(response, content) = self._conn_request(conn, request_uri, method, body, headers)
File “/usr/lib/python3/dist-packages/httplib2/init.py”, line 1363, in _conn_request
conn.connect()
File “/usr/lib/python3/dist-packages/httplib2/init.py”, line 1153, in connect
sock.connect((self.host, self.port))
TimeoutError: [Errno 110] Connection timed out

I am not quite the Linux poweruser yet, so I have no idea how to fix that, but it seems like either my PC isn’t being able to connect to the repository or there’s been a problem in any of those python codes. Tried doing it through Discover as well and had no luck either.

@johanh I actually fixed the drivers and restored OpenGL functionalities, but it is still choppy, though.
I will try again installing directly from the ppa and see if anything works. I’m currently running NVIDIA’s nvidia-driver-545, (kernel modules provided by nvidia-dkms-545) driver package.

As a temporary fix, I’m running the Windows version through Wine and here’s the fun part: although it is a bit stuttery, the refresh rate problem seems to be fixed. It would be great if everything worked correctly in this Wine solution, but I’m getting some other really strange problems that I won’t dive into since I really want to get the native version fixed.

The repository error shows a connection timed out.
So either the ppa repository was down (Unlikely but not impossible. Try again and see if you get the same error), or there is some local issue connecting to the internet.

Can you
ping ppa.launchpadcontent.net

Launchpad seems to be fine:

~$ ping ppa.launchpadcontent.net
PING ppa.launchpadcontent.net (185.125.190.80) 56(84) bytes of data.
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=1 ttl=55 time=200 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=2 ttl=55 time=209 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=3 ttl=55 time=205 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=4 ttl=55 time=208 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=5 ttl=55 time=206 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=6 ttl=55 time=208 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=7 ttl=55 time=210 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=8 ttl=55 time=209 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=9 ttl=55 time=215 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=10 ttl=55 time=212 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=11 ttl=55 time=203 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=12 ttl=55 time=213 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=13 ttl=55 time=235 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=14 ttl=55 time=211 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=15 ttl=55 time=212 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=16 ttl=55 time=213 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=17 ttl=55 time=239 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=18 ttl=55 time=217 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=19 ttl=55 time=218 ms
64 bytes from ppa.launchpadcontent.net (185.125.190.80): icmp_seq=20 ttl=55 time=220 ms
ppa.launchpadcontent.net ping statistics —
20 packets transmitted, 20 received, 0% packet loss, time 19009ms
rtt min/avg/max/mdev = 199.728/213.154/238.899/9.236 ms

Try without the yes, maybe there is some useful info being hidden. Also try with debug flag to see if there is anymore info provided:

sudo add-apt-repository -d ppa:kicad/kicad-8.0-releases

Basic IP connectivity to a site does not mean the server application is responding to connection requests. I just tried the same query and the TCP connection sat in SYN_SENT state until it timed out.

I installed Kubuntu 24.04 on a system last month and despite repeated attempts over several days was never able to connect to Launchpad to via this command to add PPAs. I ended up downloading the software I needed though other means. Something is definitely wrong on Launchpad or in the 24.04 distros.

A ping does not use TCP. It uses ICMP.

But pings are not useful beyond checking that the host is up. A more useful check would be to use the web browser to go to the download directory.

Pings are quite low level. I’ve had web servers that were wedged, but pinging it still elicited a response. It just says that the network stack is still alive.

That’s exactly my point.

SYN_SENT is the first state in the 3-way TCP connection establishment handshake. If a connection is waiting in SYN_SENT state, the remote server is not responding to incoming connections.

The https protocol a web browser uses to talk to a web server rides on top of TCP. If the TCP connection is not getting established, then https cannot not function either.

Or it could be site IT policy that blocks direct connections to the destination web server, requiring the use of a proxy, and yet allow ICMP to get through.

Network administrators have an incredible amount of flexibility in configuring.

I remembered what I did to fix this.

The Launchpad service for adding PPAs does not respond to IPv6 connections. If you disable IPv6 in your host’s connection configuration, then disconnect and reconnect the network connection, add-apt-repository will work. Once the PPA is configured you can re-enable IPv6.

Or it could be that the client isn’t configured to reject IPv6 results for DNS lookups and isn’t able to connect using TCP6 due to a restriction somewhere. I had a similar issue with the update repos of my distro where I would have to wait for timeouts until I enabled the option to prefer IPv4 in the package management.

Here we have no shortage of IPv4 addresses so most Internet providers don’t offer IPv6 to customers even though the OSes have supported it for quite some time.

It could be, but it isn’t. I have IPv6 connectivity and use it regularly. The problem is on Launchpad’s end.

I am my network administrator. :smiley: I’ve been working with TCP/IP since I helped develop and maintain a TCP/IP implementation for VAX/VMS in the 1990s, followed by a 4-year stint designing IP routers for Ericsson in the 2000s.

It’s possible that the IPv6 address for Launchpad is misrouted somewhere in Verizon’s net or beyond, or that the firewall on the system that hosts the Launchpad service used by add-apt-repository blocks IPv6. It looks suspiciously like the SYN packet is being dropped silently. It certainly isn’t returning a Host Unreachable or Port Unreachable error, or the connection wouldn’t hang in SYN_SENT state.

Regardless of the reason for the packet loss, it’s not a problem on the client’s end. The easiest thing for an end-user to do is disable IPv6 while adding the PPAs, then re-enabling it afterward.

Well, disabling IPv6 worked for the ppa package, but I still get the same choppy performance. Since I’m in a time-critical phase of my current project, I think I’ll just go ahead and try installing Windows and running a Linux distribution through a virtual machine, then.

Thanks, regardless.

The reason I mentioned client side configuration is that in my case in a sense I brought the problem upon myself because I run my own DNS server on my LAN and it serves AAAA records too, instead of forwarding queries to my provider’s resolver. Most people would not see the problem I did because they would not get IPv6 results at all. Sounds like you earned your keep diagnosing the actual cause.

I use Kicad 8.0.3 on Ubuntu derived OS (Linux Mint 21.3 MATE) installed from Flatpak in two systems. No performance problems at all. System configurations:

#1: AMD Ryzen 7 5800X, 16 GB RAM, Nvidia RTX 3080 (10G), 1440p display resolution.
#2: Intel i7-8700, 16 GB RAM, Nvidia GTX 1650 (8G), 4K display resolution.

In #2 RAM was recently upgraded to 64 GB. But that doesn’t change the fact that with 16 GB too Kicad 8.x works just fine without performance problems. I believe that 8 GB RAM without some other RAM eater in background would go fine too.

I believe that the real cause is hardware configuration. Pretty much possible that latest Kicad builds doesn’t play well with older CPUs or P2000 Nvidia card drivers. I had serious performance problems when used Kicad 8.0.0-8.0.1 on computer with Intel i7-2600 CPU and 16 GB RAM.

Just a quick update on my situation: I couldn’t fix this issue at all. I’ve changed my OS to Windows and like @Krotow mentioned, it really seems like a driver problem, since my current workstation’s GPU and CPU are both ancient.