The network switch was replaced on January 15. Since then, we have not observed any outages.
We confirm that the problems of access to the bora [001-040] and devel [01-02] nodes are solved.
Please do not hesitate to contact us if you need further information.
Many of you are reporting connection problems related to changing the fingerprint of development servers when connecting to SSH.
To make sure you can accept this change, you will find below the new fingerprint of these servers :
Do not hesitate if you need more information.
As indicated in the message of November 8th, the migration is ongoing.
Currently, as a reminder:
1. when you connect to PlaFRIM, you arrive on the devel01 or
devel02 front nodes, which are latest generation Skylake machines.
2. you can still connect to the old front node by typing ‘ssh
plafrim2’; this part of the platform (miriel, breeze, mouse, arm01,
sirocco…) will be migrated quickly to the new version of the platform
3. quickly, you will find on PlaFRIM:
* the machines you have been working on until now
* the new bora machines (dual-socket Skylake 36 cores and 192 GB of memory)
* modules with default modules dedicated to the target architecture you are working on
* a /dev space for modules where all users can provide their
own software stacks available to other users; it will be necessary to
redo all previous dev modules, the old ones being no longer functional
for this new version of the platform
* a single slurm partition
(routing) that allows you to address all machines; to choose a
particular category of machines, you can specify the associated
“feature” (to know the “features” associated with a node: sinfo -Nel)
using the -C option of slurm (salloc -C Bora, for example)
* guix to manage your experimental environments
Finally, if at the first connection on this new platform you have a message containing: > ssh-keygen -f “~/.ssh/known_hosts” -R “plafrim-ext”
type the given command and everything should work
We remind you that from next Tuesday, disruptions are to be expected on PlaFRIM.
When you connect to PlaFRIM, you will be connected to the new nodes available (devel01 and devel02). You will then be able to submit jobs on the new bora001 to bora040 nodes.
As long as PlaFRIM2 nodes are not migrated to PlaFRIM3, you can still connect to the old development nodes (devel11 to devel13) via the “ssh plafrim2” command from the new devel nodes (devel01 or devel02).
The planned schedule remains the same, migrate as many nodes as possible to PlaFRIM3 over the next week.
We still have some configurations to make so that everything is fully operational on PlaFRIM3. Feel free to test it next Tuesday and give us feedback via firstname.lastname@example.org
Feel free to contact us for any information you may need about this migration.
Following the policy update of the partition usage, defq is no longer
available. You need to use the parameter -p of srun & co to specify a
partition. Calling sinfo will show you all the available partitions.
This solution is temporary until Nov, 12th, when the new platform will
The server room of the Talence building will be undergoing refurbishment work on the cooling system and will require a total shutdown of PlaFRIM from 1st August starting at 12.00 with a restart during the 6th of August.
Thank you for your understanding.
The Luster filesystem “/lustre” is close to be saturated (in terms of inodes). If the system reaches the saturation, creation of new files on /lustre will no longer be possible.
It is therefore necessary for each user to clean up his personal directory /lustre/<LOGIN>.
We remind you that the storage space /lustre is a temporary work area and is not saved.
To store your non-temporary and big data, it is also possible to use the iRODS service. Information on it is available here
We will implement a quota in terms of number of file per user (~ 400 000).
Thank you for your understanding,
The development nodes (devel1[1-3]) will be restarted on Friday 24st March 2017, at noon.
This will allow the updating of these machines.
It will take 01h00
A KNL based cluster (Knights Landing (KNL) ) has been installed in February 2017.
The cluster consists of 4 KNL interconnected by OmniPath.
Knights Landing (7230) is a highly configurable architecture. Memory bandwidth is one of the common bottlenecks for performance in computational applications. KNL offers a solution to this problem.
To do so, the 2nd generation of Intel Xeon Phi (KNL) has on-package high-bandwidth memory (HBM) based on the multi-channel dynamic random access memory (MCDRAM). This memory is capable of delivering up to 5x performance (≥400 GB/s) compared to DDR4 memory on the same platform (≥90 GB/s).
The on-package HBM (labeled “MCDRAM” in the figure) resides on the CPU chip, next to the processing cores. KNL may have up to 16 GB of HBM. It’s hyghly configurable. The modes (which can only be modified through the BIOS) are the following:
More information is available in this Intel tutorial.
KNL have 64 cores (7230 version) and are organized on a grid as follows:
- 32 tiles of 2 cores each with a L1 cache, and 1 shared L2 cache.
- all shared L2 cache are interconnected by the grid. MESIF protocol is in charge to keep all the caches coherent
- all links are bidirectionnal
- KNL has a distributed tag directory (DTD), organized as a set of per-tile TD (tag directories), which identify the state and the location on the chip of any cache line. It is in the developer’s interests to maintain locality of these messages to achieve the lowest latency and greatest bandwidth of communication with caches. KNL supports the following cache clustering modes:
- quadrant / hemisphere
- SNC-4 / SNC-2
More information is available in the colfax documentation.
To allow users to test the different configurations, the 4 nodes of the cluster have all been configured with different parameters. Information on the different configurations is available in the PlaFRIM hardware page.