Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sysctl and non-toolkit bundles #1370

Open
bltierney opened this issue Oct 25, 2023 · 1 comment
Open

sysctl and non-toolkit bundles #1370

bltierney opened this issue Oct 25, 2023 · 1 comment

Comments

@bltierney
Copy link

It has been observed that many perfSONAR hosts are not running with the recommended TCP buffer sizes.

Here is an email discussion on ways to address this (read bottom up):


Those concerns are valid.

I like the idea of installing the package, but not actually running the script.

Maybe also display a message that shows how to run the script when a bundle is installed, and some instructions in bold on these pages:

On Wed, Oct 25, 2023 at 10:28 AM Andrew Lake <andy@es.net> wrote:
Hi,

The perfsolnar-testpoint and below does not install this packages by design. I agree that everyone needs to tune their host, but the reason we did it that way is to give people the flexibility to manage their own tunings without fear of that package blasting things. For example, on ESnet we manage our own tunings with Ansible. The separate package still gives people the ability to opt-in and have our package manage those tunings.

I still think what we have is the cleanest but I also respect the fact that most people need considerable hand-holding with this stuff and if they actually have to type a second package name or read the documentation it just won’t happen. Maybe there is a middle-ground that installs the package but we re-evaluate at when and how it is applied? I think there is still merit in saying “get out of my way, I’ll handle the tunings on my own” and the easiest is to just not include the package to begin with, but maybe there is some other logic we can add to do things differently. Probably worth creating an issue on and a subgroup can discuss.

Thanks,
Andy

On October 25, 2023 at 10:24:56 AM, Tim Chown (perfsonar-developer@internet2.edu) wrote:

I think any perfSONAR node that is making measurements should have the tuning applied.

There is more on tuning in the docs at https://docs.perfsonar.net/manage_tuning.html, which looks a little dated now. Perhaps a more direct pointer to the very latest FasterData page(s) is a better way to keep it up to date?

Also, I recommend removing 'htcp' from that bundle, as it's no longer faster than cubic.

I would agree with that.

Tim

From: Brian Tierney bltierney@es.net
Date: Sun, Oct 22, 2023 at 12:00 PM
Subject: default sysctl.conf on perfSONAR hosts
To: perfsonar-developer@internet2.edu

I noticed that the package 'perfsonar-toolkit-sysctl' is not installed by default,
and hence a lot of perfSONAR installations are using really small TCP buffers, like 32MB.

I see in the docs mention of the optional bundles:
e.g.: https://docs.perfsonar.net/install_debian.html

But I really think that bundle is not 'optional', and should be installed as part of the 'tools' and 'testpoint' bundles.

@timchown
Copy link

The thing I find odd is that the tuning is applied for a toolkit installation, but not a testpoint installation. Once you have a node that is essentially a dedicated perfSONAR node, it should have recommended perfSONAR tuning applied. I can understand the basic tools package maybe shouldn't tune, because the node is not a dedicated perfSONAR server (most likely).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ready
Development

No branches or pull requests

2 participants