Skip to content

SCITAS blog#

Annual SCITAS maintenance

This communication is of significant importance and may affect your work. We strongly recommend dedicating time to thoroughly read its content.

We are approaching our forthcoming annual maintenance period, scheduled from February 5 to February 19, 2024. This maintenance is essential for enhancing our services and includes the following key upgrades:

End of year retrospective

As 2023 comes to an end, we wanted to share with you this short message summarizing this (almost) past year. From the computational point of view, 2023 was outstanding! The service was used by 1200 unique users coming from 135 labs. Around 131 million core-hours and 236'000 GPU-hours were used on the machines. Among them, 7.2 million core-hours and 19'000 GPU-hours were dedicated to students and the 19 courses that used our infrastructures.

Downfall vulnerability

The downfall vulnerability, identified as CVE-2022-40982, enables a user to access and steal data from other users who share the same computer. It is found in most Intel CPUs starting from the 6th generation (Skylake) up to the 11th generation (Tiger Lake) included. For instance, a malicious app obtained from an app store could use the Downfall attack to steal sensitive information like passwords, encryption keys, and private data such as banking details, personal emails, and messages.

Jed frontend has to be rebooted due to a power issue

This morning, around 6h30, the Jed frontend was turned off due to an unexpected power issue on the direct power line. Because of this, we had to reboot the frontend, which may have caused some loss of connections.

All the running jobs as well as the ones in the queue were not affected.

We are currently investigating the cause of this problem. We apologize for the inconvenience it may have caused you.

New billing scheme and usage capping

Introducing RAM memory billing: A fairer approach to compute node usage

Historically, SCITAS has only billed for the fraction of the CPU that is allocated to a simulation. While this metric often provides valuable insights into the processing power required by a user, it does not fully capture the complete picture of resource consumption. For example, some simulations may require a lot of memory, while performing their task serially, i.e. using only one CPU core. This leads to situations where a certain fraction of the node is allocated for this particular job, while it is billed only based on one CPU core. This created an unfair situation between the users as the billing did not take into account the actual fraction of the compute node that is utilized.