Improving speed of USB live persistent use

nogo10 · 2020-09-13 15:26:05

I recently made a BL Lithium persistent USB live key (Kingston Data Traveller 64gb 100-G3 no partition all FAT32) which I will typically use on a Laptop i5 6th gen with 8gb ram. I did not modify BL, it is stock Lithium Debian 10. I occasionally get lagging on Firefox, application and file access.

eg: It took 15 seconds just to open a terminal, but instant afterwards.
EDIT: In fact after boot up using any of the common short cut keys to open,Editor, File Manager, Browser or Terminal involves 15+ second lag the first time is opened after bootup.

What improvements can I make to drastically improve speed and reduce lag for browser use (Firefox right now), file access (on USB) and terminal ssh?

I am willing to redo the USB key and even consider a new one.

Last edited by nogo10 (2020-09-13 16:36:50)

rbh · 2020-09-13 17:12:18

Another path, is installing BL to an m2-device with an usb-enclosure.
In an USB3 port, it will be nearly as responsive as installed to an internal harddrive, but takes a little more cost.

Running live, persistent session from usb, lead to some lagging.
Even installing to usb attached hd, will be much faster than runing persistent live session. But is a little more bulky than an m2

rbh · 2020-09-13 17:17:40

You could maybe configure a ramdrive, large enough to hold the system.

nogo10 · 2020-09-13 17:51:48

rbh wrote:

You could maybe configure a ramdrive, large enough to hold the system.

Could I preload specific applications in RAM?

rbh · 2020-09-13 18:02:30

Sounds possible to do, but I have no idea how to do it.

nogo10 · 2020-09-13 21:05:19

Seriously Im experiencing lag whenever I access an application. Luckily there's seems to be good documentation on this issue about using a package called PRELOAD.

However this package is no longer available for Deb 10.

Last edited by nogo10 (2020-09-13 21:31:34)

johnraff · 2020-09-13 23:38:23

A bit off topic maybe, but I'm surprised a linux system works at all on a FAT32 file system, which does not support users or permissions.

nogo10 · 2020-09-14 00:38:35

johnraff wrote:

A bit off topic maybe, but I'm surprised a linux system works at all on a FAT32 file system, which does not support users or permissions.

Not quite, this is what the partition looks like

Last edited by nogo10 (2020-09-14 01:29:56)

johnraff · 2020-09-14 05:34:46

^sorry that's too small to read. Can you post a larger image, linked from a thumbnail?
If you right-click the image in Thunar, there is an option "Upload Image" which will do it for you.

rbh · 2020-09-14 06:18:02

You can "boot to ram" what live rescudiscs as "Finnix" use.
More info here: https://calvin.me/create-persistent-ubu … -boots-ram
You can then not have bigger persistance partition/file than some GB.

Perharpes it is better to change file-system from fat32 to extfs. Fat is not the fastest file-system... If you want to be able to edit the content of the stick on windows computer, Paragon has extfs driver for windows. https://www.paragon-software.com/busine … or-windows

Or, you maybe you has to face the fact that you can not accomplish what you want. Live Session, is for rescue mission or just test, not for everyday productive work.

Last edited by rbh (2020-09-14 06:48:50)

AndrewSmart · 2021-01-23 16:39:41

I experienced the same issue with lithium on a persistent USB (all ext4 partitions), I saw your other thread. There is a substantial delay in launching most anything the first time. They typically launched quicker, within 1-10 seconds after being launched the first time. This issue didn't exist with kernel 3.16 on an older USB persistence setup I made. vlc's interface would be unresponsive for maybe 6-10 seconds after looping but yet playback would continue (video frames play) while the interface was unresponsive (no GUI widgets responsive), I'm not sure if that is related, but makes me think that some GUI code may be the issue if so. toram didn't change the issue. Having /var/log being tmpfs didn't help either. Initial launch delay was around 8-10 seconds typically, sometimes longer like 30-60 seconds. I don't believe nouveau or proprietary nvidia drivers made a difference on this particular issue.

I'd installed more packages since then, and now I no longer have this problem. Everything is able to launch *immediately* after booting to the desktop, no delays. Quicker than before. IIRC the only changes I made were installing firejail and steam dependencies... a bunch of 32-bit GUI packages. I'm using proprietary nvidia drivers right now.

I'd suggest doubling the cache lookahead in vlc (Preferences -> Input/Codecs) to mitigate audio/video playback problems (momentary stops in playback). The default I've found to be not sufficient for this persistence setup.

For browser improvement I suggest both using profile-sync-daemon and setting the browser's cache to be on a tmpfs instead of the filesystem on the USB (either e.g. ln -s /tmp/mozilla ~/.cache/mozilla, or via settings in the browser).

The mq_deadline scheduler seems fine. I tried the bfq scheduler too. But, I don't think this issue had to do with that, but maybe something GUI library related. Puzzling.

And yes there is normally GUI unresponsiveness due to waiting on I/O which I've come to expect with USB persistence, but this was excessive/unusual. i.e. idle desktop taking 10-60 seconds to launch a text editor or terminal. Normally if there is thrashing or at least one application doing heavy I/O then yes I'd expect something like that, but not an idle system.

I had this issue for months and I think I found a remedy for it, so I thought I'd share what insights I had here. This remedy doesn't make much sense to me though.

Last edited by AndrewSmart (2021-01-23 17:08:06)

AndrewSmart · 2021-01-26 09:52:54

Time it takes to boot:

$ systemd-analyze 
Startup finished in 15.529s (kernel) + 12.977s (userspace) = 28.506s

Here is a demonstration of the speed improvement in launching things. By 35s system uptime I demonstrate having launched both the terminal and filesystem browser.
https://youtu.be/JdnA6LblqOE?t=54

Last edited by AndrewSmart (2021-01-26 11:34:06)

#1 2020-09-13 15:26:05

Improving speed of USB live persistent use

#2 2020-09-13 17:12:18

Re: Improving speed of USB live persistent use

#3 2020-09-13 17:17:40

Re: Improving speed of USB live persistent use

#4 2020-09-13 17:51:48

Re: Improving speed of USB live persistent use

#5 2020-09-13 18:02:30

Re: Improving speed of USB live persistent use

#6 2020-09-13 21:05:19

Re: Improving speed of USB live persistent use

#7 2020-09-13 23:38:23

Re: Improving speed of USB live persistent use

#8 2020-09-14 00:38:35

Re: Improving speed of USB live persistent use

#9 2020-09-14 05:34:46

Re: Improving speed of USB live persistent use

#10 2020-09-14 06:18:02

Re: Improving speed of USB live persistent use

#11 2021-01-23 16:39:41

Re: Improving speed of USB live persistent use

#12 2021-01-26 09:52:54

Re: Improving speed of USB live persistent use

Board footer