Or raising the polling rate of USB mice above 10 Hz (as in ten - that’s not a typo).
I don’t know the answer, but I’m interested, what do you use that for?
Fortunately, copying or moving more than 1 GB to or from USB sticks without crashing the entire machine (no matter if NTFS or ExFAT) was solved last year, probably because of a kernel update.
I believe it has a lot to do with the default amount of dirty memory. dirty memory is mostly the write cache, which is unnecessary to have a lot of, as that does not improve anything after a certain point, but at best it can mislead you to believe that a copy opetation started with 200 MB/s and that it finished when it actually did not yet.
you can fix these limits with sysctl files. they are loaded on boot on typical systemd systems. suggestions are in the manjaro post, relevant for any desktop linux system.
maybe it’s worth to set these up even if you are good for now. It’s good to hear a kernel change could have fixed it though. maybe they have finally revised the defaults, they wanted to do that for a few years now…
Thanks for the links. I will have a look, didn’t even know about kernel.org, nobody before you mentioned it.
I suspect the polling rate to be responsible because the movement of all USB mice turns out to be incredibly slow and choppy. A few years ago it was the worst, it looked and felt like it was down to 2 Hz. This got slowly better with kernel updates, now it seems to be around 8-10 Hz but that still makes using USB mice pointless. The mouse problem always occurs no matter if the machine is close to idle or doing a lot (with or without USB, doesn’t matter) and no matter which brand or model.
I also wrote a script to apply gamma correction via xgamma whenever the machine starts or returns from standby (because gamma isn’t remembered and returns to default). A little inconvenient in comparison to Windows or Mac. I would be okay with that - if the script would get executed whenever I start the machine or go out of standby. Which is not the case, sometimes it just doesn’t happen and I have to do it manually. So what’s the point of trying to automate anything then if Linux does things whenever it feels like it?
Yes, there are applets for gamma adjustment which also remember settings. But it turned out updating them crashes Cinnamon when it tries to restart (depending on the kernel version), forcing me to force a shotdown with the power button. This is one of those problems that keeps disappearing and reappearing for years. At some point I had enough and decided to use xgamma.
It’s all those little inconvenient and unreliable things that keep me from using Linux for anything that goes beyond browsing the web or doing office stuff (not mentioning missing drivers). I end up spending too much time with maintenance or finding workarounds, ultimately serving the machine more than the other way around.
I will have a look, didn’t even know about kernel.org, nobody before you mentioned it.
its mostly developer documentation about programming APIs, but there’s also admin docs, not only at the admin-guide pages.
if the script would get executed whenever I start the machine or go out of standby. Which is not the case, sometimes it just doesn’t happen and I have to do it manually.
what is its current trigger?
if yours is a systemd based system, it’s often recommended to make a service unit file for the script, like this:
[Unit]Name=restore gamma on resume
WantedBy=sleep.target
[Service]After=sleep.target
Exec=/usr/local/bin/yourscript.sh
save this in /etc/systemd/system/gammasleep.service (runs services as root), and run systemctl daemon-reload for it to notice the new file. systemctl enable --now to start it and make it autostarted on boot.
I have written this from memory on phone, so it might need corrections, but this is basically it, plus edit the exec line.
docs is in man systemd.service, man systemd.unit. man systemd.directives tells you which man page documents a specific key.
you can check logs with journalctl -u gammasleep.service. an f gives you a running log with shorter history.
probably I could have written all of this after you confirmed you did not use a systemd service yet…
It’s all those little inconvenient and unreliable things that keep me from using Linux for anything that goes beyond browsing the web or doing office stuff
oh I felt the same when I first tried to switch to linux on my main desktop. everything was inconvenient without my usual tools and the system was breaking down from time to time. I got burned out, 2 years later I retried and now I haven’t gone back to the windows install for months, and there’s not much problems now. probably I was being clumsy and doing things the wrong way 2 years ago, but it’s hard to tell because I don’t remember.
Thanks. I don’t remember anymore how I did it exactly and can’t find the particular page that gave me the tip (It was on the Mint forum, discovered it by accident), but I can say that I didn’t run it as service but still with root privileges. It’s weird that it worked in roughly 95 % of all startup/resume cases. Maybe this solution was based on a script function that’s actually obsolete and not fully supported anymore, maybe a bug, who knows. I switched to manual execution two years ago.
I don’t know the answer, but I’m interested, what do you use that for?
I believe it has a lot to do with the default amount of dirty memory. dirty memory is mostly the write cache, which is unnecessary to have a lot of, as that does not improve anything after a certain point, but at best it can mislead you to believe that a copy opetation started with 200 MB/s and that it finished when it actually did not yet.
https://web.archive.org/web/20220828115647/https://archived.forum.manjaro.org/t/decrease-dirty-bytes-for-more-reliable-usb-transfer/62513
https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html
you can fix these limits with sysctl files. they are loaded on boot on typical systemd systems. suggestions are in the manjaro post, relevant for any desktop linux system.
maybe it’s worth to set these up even if you are good for now. It’s good to hear a kernel change could have fixed it though. maybe they have finally revised the defaults, they wanted to do that for a few years now…
Thanks for the links. I will have a look, didn’t even know about kernel.org, nobody before you mentioned it.
I suspect the polling rate to be responsible because the movement of all USB mice turns out to be incredibly slow and choppy. A few years ago it was the worst, it looked and felt like it was down to 2 Hz. This got slowly better with kernel updates, now it seems to be around 8-10 Hz but that still makes using USB mice pointless. The mouse problem always occurs no matter if the machine is close to idle or doing a lot (with or without USB, doesn’t matter) and no matter which brand or model.
I also wrote a script to apply gamma correction via xgamma whenever the machine starts or returns from standby (because gamma isn’t remembered and returns to default). A little inconvenient in comparison to Windows or Mac. I would be okay with that - if the script would get executed whenever I start the machine or go out of standby. Which is not the case, sometimes it just doesn’t happen and I have to do it manually. So what’s the point of trying to automate anything then if Linux does things whenever it feels like it?
Yes, there are applets for gamma adjustment which also remember settings. But it turned out updating them crashes Cinnamon when it tries to restart (depending on the kernel version), forcing me to force a shotdown with the power button. This is one of those problems that keeps disappearing and reappearing for years. At some point I had enough and decided to use xgamma.
It’s all those little inconvenient and unreliable things that keep me from using Linux for anything that goes beyond browsing the web or doing office stuff (not mentioning missing drivers). I end up spending too much time with maintenance or finding workarounds, ultimately serving the machine more than the other way around.
its mostly developer documentation about programming APIs, but there’s also admin docs, not only at the admin-guide pages.
what is its current trigger?
if yours is a systemd based system, it’s often recommended to make a service unit file for the script, like this:
[Unit] Name=restore gamma on resume WantedBy=sleep.target [Service] After=sleep.target Exec=/usr/local/bin/yourscript.shsave this in /etc/systemd/system/gammasleep.service (runs services as root), and run systemctl daemon-reload for it to notice the new file. systemctl enable --now to start it and make it autostarted on boot.
I have written this from memory on phone, so it might need corrections, but this is basically it, plus edit the exec line. docs is in man systemd.service, man systemd.unit. man systemd.directives tells you which man page documents a specific key.
you can check logs with journalctl -u gammasleep.service. an f gives you a running log with shorter history.
probably I could have written all of this after you confirmed you did not use a systemd service yet…
oh I felt the same when I first tried to switch to linux on my main desktop. everything was inconvenient without my usual tools and the system was breaking down from time to time. I got burned out, 2 years later I retried and now I haven’t gone back to the windows install for months, and there’s not much problems now. probably I was being clumsy and doing things the wrong way 2 years ago, but it’s hard to tell because I don’t remember.
Thanks. I don’t remember anymore how I did it exactly and can’t find the particular page that gave me the tip (It was on the Mint forum, discovered it by accident), but I can say that I didn’t run it as service but still with root privileges. It’s weird that it worked in roughly 95 % of all startup/resume cases. Maybe this solution was based on a script function that’s actually obsolete and not fully supported anymore, maybe a bug, who knows. I switched to manual execution two years ago.