Feedback please: foundation of a laptop and desktop work group

[noise]

I wonder whether I could notice the desktop feel difference that people are aiming for by setting Linux to server-optimized preemption and use the most un-desktoppy CPU and I/O scheduler there.

Probably not, unless you stress the system somehow. In typical desktop use the machine sits idle most of the time and waits for user input. Snappiness then comes down to how quickly the short bursts of user requests are executed. Since all resources are readily available, even a trivial scheduler can give satisfactory results in that case.

The question is what background tasks could be running and whether they affect the desktop experience: File indexer, buildworld, some network services? In my experience the disk IO latency is still the number one issue and the resource that is most difficult to share between processes. Put a faster SSD / NVMe disk into the stinkpad, no other optimization will have a comparable effect on desktop usage.

 

[noise]

Does this really make a difference? Sometimes I have the compiler pull down the speed of my browser music. Is that what you mean? Nice -20 firefox might help but I didn't try it yet. It requires extreme circumstances like 50 cc threads in a batch while almost out of RAM. That's not normal use anyway

One of the criticisms of the current scheduler is that the nice values have almost no effect on the relative share of CPU processing time. They want to fix this, see Olivier Certner's notes in the status report linked above.

Currently you have to put your batch job into the idle priority scheduling class (see idprio()) to get a meaningful difference in CPU priority.

 

[T-Aoki]

Does this really make a difference? Sometimes I have the compiler pull down the speed of my browser music. Is that what you mean?

Including but not limited with it. For example, on my previous (and of course slower) computer, invoking LibreOffice (and chromium for any pages hesitate to display on Firefox) caused inresponsive seconds. It would need not only disk I/O but also CPU times for initialization.
And someone randomly claims for hiccups (stutterings) on playing audio/video on heavy loads. It would affect more and more for slower computers.

Nice -20 firefox might help but I didn't try it yet. It requires extreme circumstances like 50 cc threads in a batch while almost out of RAM. That's not normal use anyway

I don't think adjusting nice for the whole processes (except for apps with single threaded) is good thing. But prioritizing (maybe needs both CPU and I/O) threads responsible with user interaction (accepting inputs and feeding back) would be essentially needed.

 

[vermaden]

A graphical snapshot program (like timeshift) for ZFS would be amazing, I think that's a good project for my C code learning process.

I proposed something like that for Caja - which is fork of Nautilus from Gnome 2.x - which were used in OpenSolaris some time ago:

Time Slider in Caja · Issue #1776 · mate-desktop/caja

Hi, this is kinda rather 'feature proposal' then 'issue'. On OpenIndiana there is a feature implemented in Caja called Time Slider - to show various ZFS snapshots in file manager: As Ubuntu comes t...

github.com

 

[MG]

I wonder whether I could notice the desktop feel difference that people are aiming for by setting Linux to server-optimized preemption and use the most un-desktoppy CPU and I/O scheduler there.

No idea how to do it, but Slackware would be worth a try. In FreeBSD I have a slight input lag on USB mouse and keyboard. It seems to be caused by my openbox event loop to catch keyboard shortcuts. This doesn't happen in Slackware with similar X-configuration. It could be the FreeBSD priority handling of system calls...

 

[cracauer@]

openbox event loop

What's that?

 

[cmoerz]

I'm working on getting an official mailing list set up. Once we have that set up, we should be able to schedule a date for a "maiden call".

I've followed up with bapt@; we'll stick with the regular freebsd-desktop@freebsd.org mailing list for the moment. In case we find this too noisy, we'll create a separate one. For starters, I'll post everything with a [LDWG] prefix so it's easy to filter.

 

[MG]

What's that?

Openbox wm signal procedure for X keyboard input. Don't know what it's called exactly but it takes time without causing any visible load. Or do these signals get less priority than server-like processes because they are UI-related?

 

[cy@]

Scheduler differences are hard to measure, though. Especially the interactive reactivity.

Yeah. When I did MVS (IBM mainframe) tuning people would tell me "it feels slower." Looking at the numbers it didn't appear that way. Because people wouldn't believe SRM performance metrics , we'd attach a busy light monitor to their IBM 3270 terminals to collect some timings at the terminal. The takeaway virtually every time was that seat of the pants measurements (feelings) were almost always mistaken.

 

[michael_hackson]

For the sake of having a smooth transition for users that come from full desktop experiences a good thing can be a to add an option in the installer to suggest extra packages to pick from like:
Gnome or KDE, and other packages that could be of use. And if the Desktop install is wanted common desktop things are installed together with the Xorg and drm-kmod. Some common Linux installers behave like this.

Of the top of my head I believe this in turn ends up in something in the like of NomadBSD.

So closer in line with the Linux, as a lot seem to come anyhow.

Personally I haven't found any desktop-user related things as 'missing' and most, if not all, of my hardware have support. Lucky perhaps.

 

[T-Aoki]

I proposed something like that for Caja - which is for of Nautilus from Gnome 2.x - which were used in OpenSolaris some time ago:

Time Slider in Caja · Issue #1776 · mate-desktop/caja

Hi, this is kinda rather 'feature proposal' then 'issue'. On OpenIndiana there is a feature implemented in Caja called Time Slider - to show various ZFS snapshots in file manager: As Ubuntu comes t...

github.com

Caja is a part of Mate DE, which is a fork of Gnome2.

 

[vermaden]

Caja is a part of Mate DE, which is a fork of Gnome2.

Yep, that is what I said generally, just in different words.

 

[astyle]

Regular users who can provide valuable feedback on their experiences and pain points.

Wi-fi is a peristent pain point for me. I complained about it in other threads. I kept getting answers like 'Dig around in /etc/wpa_supplicant.conf'. Connecting and disconnecting from wi-fi needs to be predictable and reproducible, no matter the utility in use.
bsdconfig wireless kind of works, but even there, navigation and visible behavior is somewhat unpredictable... Like, even if I succeed in making a connection, I can't go back via the 'exit' menu item, it can only be done via the 'cancel' menu item. I used to be concerned that the 'cancel' will undo a successful connection, and it took some time to get used to the idea that no, the wi-fi connection will persist in spite of misleading visible info.

 

[cmoerz]

Wi-fi is a peristent pain point for me.

I can relate; I've had my notebook reboot unannounced after disconnection and reconnecting wifi. Nothing in the logs afterwards. Never ever had that kind of experience with anything else in FreeBSD.

Fortunately, the Foundation now has launched an effort that touches and improves wireless amongst other things. I hope the workgroup also brings all stakeholders closer together and helps making progress more public and accessible.

 

[T-Aoki]

I can relate; I've had my notebook reboot unannounced after disconnection and reconnecting wifi. Nothing in the logs afterwards. Never ever had that kind of experience with anything else in FreeBSD.

Me, too, with iwlwifi Intel(R) Wireless-AC 9560 160MHz, REV=0x312.
As I've not tested a while, possibly fixed on main, though.

And this kind of crash can happen on device drivers under developement, especially when no good helps are given by hardware manufacturers, like on FreeBSD.
And more, what I've often experienced (whether hard reboot happens or not) is firmware crash.
In quite early phase, firmware crash caused immediate hard reboot. But the last time I've enabled iwlwifi, immediate switch to wired connection and stop attempting to switch again could help, but once attempted again, not always but often rebooted.

 

[kpedersen]

Me, too, with iwlwifi Intel(R) Wireless-AC 9560 160MHz, REV=0x312.

I get what they are doing with iwlwifi. The abstraction layer approach is a marathon rather than a sprint. However the iwlwifi has not been stable for me either. Especially after factoring in suspend / resumes.

I am surprised that FreeBSD jumped in feet first with iwlwifi as the *only* choice for a number of intel cards. A more staggered approach of additionally improving iwm, iwn to support the newer cards at the more limited 802.11g would have been a good compromise (so we can switch between until iwlwifi is in a better state). Obviously we need to factor into account the limited man power of the project, so potentially this was not feasible.

Other than driver issues, wpa_supplicant and the rest of the configuration tools work well. Hopefully when Linux breaks everything as it migrates to iwd, FreeBSD can provide a good safety net for those requiring working wifi.

 

[Deleted member 81054]

And I also recalled "1 second rule" on OS/2, which was not achieved in many cases.
It was, if I recall correctly, "Any application should (shall?) resopnd with user interaction in 1 second, in any form.".

Humans actually prefer some sort of "reaction" in much less time -- I design appliances with 250ms to 300ms as the "threshold of annoyance".
But, one needn't complete the desired activity in that timeframe... just acknowledge the user's action (preferably with more than a keyclick -- as that is handled outside of the actual application's scope).

 

[T-Aoki]

Humans actually prefer some sort of "reaction" in much less time -- I design appliances with 250ms to 300ms as the "threshold of annoyance".
But, one needn't complete the desired activity in that timeframe... just acknowledge the user's action (preferably with more than a keyclick -- as that is handled outside of the actual application's scope).

Exactly.
1 second would be chosen just because it can be noticed with non trivial amount of wall clocks and watches.

But even for 1 second, it would not be possible with OS alone on heavy load. Would also affected by the design of the apps the user want to react in time.

But even if all apps installed are well designed, if underlyingy OS does not properly support realtime (for human) interactivity, reactions should be delayed too much.

 

[Deleted member 81054]

Exactly.
1 second would be chosen just because it can be noticed with non trivial amount of wall clocks and watches.

But even for 1 second, it would not be possible with OS alone on heavy load. Would also affected by the design of the apps the user want to react in time.

But even if all apps installed are well designed, if underlyingy OS does not properly support realtime (for human) interactivity, reactions should be delayed too much.

There are things that you can do to give an illusion of responsiveness. E.g., have the driver generate keyclicks each time a keystroke is processed -- even if the application layer hasn't seen them. The risk, there, is that the user can get ahead of the application and has no way to undo the keystrokes he may have accidentally "typed ahead".

[IBM had an OS that dynamically split the screen so what you had typed-ahead was visible in the lower half of the screen (text console). This is somewhat handled in a shell but not as prettily]

For example, Windows apps throw up a splash screen before the binary has completely loaded. Then, typically adorn that with "progress messages" to reassure the user that the system hasn't "hung" (especially valuable if the user can't hear the disk activity as all of the DLLs are pulled into play).

In an appliance that I'm currently developing, I deliberately load each application ("object server") in two pieces; the first is responsible for setting up the environment for the service while the second actually provides the service. This lets the service announce itself (to other clients) before it is actually ready for requests AND lets the resources that were used in setting it up to be freed/discarded once that phase is complete.

Traditionally, interactive tasks were given enhanced priority (for an initial short time) in the hope that this would enhance responsiveness. If a task ran for longer, then its priority would diminish.

But, you also have to worry about how applications can exploit this to the detriment of other applications (e.g., keep exec()ing bits of yourself as new processes so THEY continue to run at elevated priority as YOURS diminishes)

 

[T-Aoki]

There are things that you can do to give an illusion of responsiveness. E.g., have the driver generate keyclicks each time a keystroke is processed -- even if the application layer hasn't seen them. The risk, there, is that the user can get ahead of the application and has no way to undo the keystrokes he may have accidentally "typed ahead".

[IBM had an OS that dynamically split the screen so what you had typed-ahead was visible in the lower half of the screen (text console). This is somewhat handled in a shell but not as prettily]

For example, Windows apps throw up a splash screen before the binary has completely loaded. Then, typically adorn that with "progress messages" to reassure the user that the system hasn't "hung" (especially valuable if the user can't hear the disk activity as all of the DLLs are pulled into play).

In an appliance that I'm currently developing, I deliberately load each application ("object server") in two pieces; the first is responsible for setting up the environment for the service while the second actually provides the service. This lets the service announce itself (to other clients) before it is actually ready for requests AND lets the resources that were used in setting it up to be freed/discarded once that phase is complete.

Traditionally, interactive tasks were given enhanced priority (for an initial short time) in the hope that this would enhance responsiveness. If a task ran for longer, then its priority would diminish.

But, you also have to worry about how applications can exploit this to the detriment of other applications (e.g., keep exec()ing bits of yourself as new processes so THEY continue to run at elevated priority as YOURS diminishes)

Mostly agreed. But I don't think prioritizing the whole process (with nice?) being good thing, but per thread prioritizing with separating human interdace parts and others would be better.

 

[Koen Martens]

Hi, great initiative! For me, the one thing stopping me from using FreeBSD on my laptop daily is the lack of suspend/resume (it's this new-fangled microsoft sleep state that's unsupported). For laptop usage, no amount of graphical installers or snapshot utilities is going to help, as long as there's no suspend/resume, it's not fit for use on a laptop.
It's this new S2Idle thing from Microsoft that seems to be the standard on modern laptops that's lacking support in FreeBSD.

I'm happy to help with testing things. I'm an (embedded) developer myself, and use FreeBSD on servers. Given time, I'd probably be able to make some contributions on this subject, but I'd need to get to know the FreeBSD kernel pretty intimately first. And that would take quite some time next to the dayjob.

I had a look a the wiki page. It suggests subscribing to the freebsd-desktop list to stay up to date, but looking at the archive it's pretty busy and not all traffic relates to this workgroup. If there are other ways to make sure I don't miss progress on this workshop, I'd love to hear about it. Otherwise, I'll try and subscribe and filter out the 'noise' with some procmail rules.

 

[NapoleonWils0n]

dont add a desktop like gnome or kde to the installer whatever you do

gnome is basically a rip off of mac osx and ios
and has a nanny knows best attitude to everything

the gnome network switcher in the panel wont work at all on freebsd because of systemd
so you wont get the same gnome experience on freebsd as you would on linux

kde is just a bloated crashfest rip off of windows
and it doesnt have independent virtual workspaces per display

so is useless with multiple monitors

 

[T-Aoki]

dont add a desktop like gnome or kde to the installer whatever you do

gnome is basically a rip off of mac osx and ios
and has a nanny knows best attitude to everything

the gnome network switcher in the panel wont work at all on freebsd because of systemd
so you wont get the same gnome experience on freebsd as you would on linux

kde is just a bloated crashfest rip off of windows
and it doesnt have independent virtual workspaces per display

so is useless with multiple monitors

I've not use installer for actual installation (used for rescue only) and the last time I used for installation was sysinstall, the former installer of current bsdinstall.
But if I recall correctly, sysinstall had ability to install official packages (in CDROM at the moment, or via Internet connection) after installing and minimally configured base.
So if bsdsintall still has the functionality, it should be on the admin, including any kind of DEs/GUIs.
Not forcing anything (except pkg and required firnmares, microcode updates) is important.

 

[Deleted member 81054]

dont add a desktop like gnome or kde to the installer whatever you do

To be clear: are you suggesting the installer not be BUILT on a GUI? Or, that it shouldn't INSTALL a GUI on the target?

 

[astyle]

To be clear: are you suggesting the installer not be BUILT on a GUI? Or, that it shouldn't INSTALL a GUI on the target?

It's definitely the latter.

And the reasoning is plenty obvious: it would add a gigabyte or more to the installer's size for no good reason - the GUI can be installed later, over the Internet connection.