Multicore Machines in URCS


Introduction

There are some powerful servers with N cores (N>=4) in the department. Not all of them are in the NFS file system with the desktops, so you may need to do file transfers. However, you can do some privileged experiments on the machines such as replacing linux kernel or changing physical memory size. To prevent conflicts, it's better to check running tasks with their owner before launching yours.

For ordinary user-space experimentation on staff-administered machines, just run 'who' or 'uptime' to see if anybody else is around. If you discover that someone else is often on the machine, send a note (or better, drop by his or her office) to coordinate, so you don't mess up each other's performance experiments. If this sort of informal coordination doesn't seem to be working, talk to your advisor to have something more formal set up (this has been done a few times in the past - e.g. around crunch time for a looming conference deadline).

If you need a machine for a big/long-running user-space job, you may be best off reserving a node from the torque cluster. The specifications for these vary somewhat; you can specify constraints such as # of CPUs, memory, etc. when requesting a machine, e.g. if you need one of the more powerful machines or a lot of memory. All of the machines in the torque cluster are in the NFS file system.

Naming scheme

The machines generally follow a naming scheme which reveals their computational capacity. They are generally named as follows:

node [NUMBER OF DIES] x [NUMBER OF CORES PER DIE] x [NUMBER OF HYPER-THREADS PER CORE] x [a-z]

Since the hyper-threading was mostly introduced for naming our Nehalem processors, it might not appear in the convention.

Active Machines

Node name CPU(s) Details Memory NFS CS login* OS Primary Use
node1x4b 1 Intel Xeon E3-1220 Ivy Bridge, 3.1GHz 4GB N Y Fedora 13, custom kernel (3.14.29-zchen+)