perfSONAR User Q&A and Other Discussion

[Laurie Zirkle <>]

Thanks Andrew.  That is what I suspected but I wanted to verify so I could share it with the rest of the team here.

--
Laurie

On Thu, Apr 6, 2017 at 9:51 AM, Andrew Lake <> wrote:

Yes, as long as we support 3.5.1 we will provide web100 kernels, which will be for 6 months after the 4.0 release. We will be sharing this timeline again in the coming days.

Also on the topic of the new kernel with 6.9, we will be preparing it soon but for this round especially we’ll need a bit of patience as we are also in the midst of preparing for the final 4.0 release. Expect the usual round of web100 announcements over the course of the next few days. 

Thanks,

Andy

On April 6, 2017 at 9:07:52 AM, Laurie Zirkle () wrote:

Since 3.5.1 is supposed to be supported for 6 months after the release of 4.0, and since CentOS-6.9 became available this morning, will web100 kernels still be provided for that period of time?

--
Laurie

On Mon, Apr 3, 2017 at 3:02 PM, Andrew Lake <> wrote:

All,

On April 17th we will be releasing the final version perfSONAR 4.0. Last week we released the third release candidate, and thanks to those that have provided feedback so far. Based on that feedback and our own testing, we are comfortable setting the date for the final release two weeks from the timestamp of this email. 

As a reminder, the final release in two weeks will be made available as an auto-update. The auto-update process we have in place will preserve all your existing data and measurements. It will also still allow you to test with people running versions of the code before 4.0 and vice versa. Our goal is that for most of you this should be a seamless transition in spite of the large changes “under-the-hood". 

One area we want to highlight though is that hardware requirements have shifted slightly in this release, especially pertaining to CPU, so for some disabling auto-updates of the perfSONAR packages may be the best course of action. We recommend you keep auto-updates of any non-perfSONAR packages enabled so you can still get important security updates. See http://docs.perfsonar.net/release_candidates/4.0rc3/manage_update.html#disabling-automatic-updates-for-perfsonar-packages for instructions on how to diable perfSONAR auto-updates. Our recommendations for deciding how to approach auto-updates are as follows:

 

- If you have a single-core CPU, we recommend disabling auto-updates. Our testing shows that the combination of running CPU intensive throughput tests and/or OWAMP tests with high write activity to the measurement archive on top of the new scheduling system does not perform as desired beyond more than a few tests. Such a setup may be fine if you plan to use it as an ad-hoc tester as opposed to for use with dedicated measurements.  It is worth noting here that this is below the minimum recommendations for 3.5.

- If your host has a CPU with two cores but the clock speed is below 2GHz or less than 4 GB of RAM, we recommend using your best judgement. If you are running a couple dozen tests or less you are likely fine with regards to CPU. 4GB has been the memory recommendation for many years on the toolkit, and if you are below that and running a bundle without the measurement archive you may be fine as well. If you are running on less than 4GB with a local measurement archive, we encourage you to add memory or disable auto-updates (and we would have recommended this the last few releases as well).

- If your host has a CPU with at least 2 cores, a clock speed of at least 2 GHz and 4GB memory, you should be good, no action is needed. We recommend keeping auto-updates on in this case.

 

If your hardware is up to specification, but you would be more comfortable disabling auto-updates for the time-being you are free to do so as well. We will be sending this reminder a few more times between now and April 17th. Please feel free send us any questions in the meantime.

Thank you!

The perfSONAR Development Team