OSCER Users, Today's maintenance has been completed. If you should find any supercomputer related issues please let us know. Thanks, The OSCER team On Tue, Dec 10, 2024 at 7:50 AM Neeman, Henry J. <[log in to unmask]> wrote: > > > OSCER users, > > > REMINDER: > > Scheduled maintenance outage Tue Dec 10 6am through midnight > Central Time > > The Nov 26 outage reconfigured Side A; > the Dec 10 outage will reconfigure Side B. > > This will affect the supercomputer, but not OURdisk, OURcloud, > nor OURRstore. > > > ------------------------------ > *From:* Neeman, Henry J. <[log in to unmask]> > *Sent:* Monday, December 9, 2024 10:06 AM > *To:* OSCER users <[log in to unmask]> > *Subject:* Re: Scheduled maintenance outage Tue Dec 10 6am through > midnight CT > > > > OSCER users, > > > **IMPORTANT IMPORTANT IMPORTANT IMPORTANT!!!** > > Before the scheduled maintenance outage starts > **TOMORROW** (Tue Dec 10) at 6:00am: > > Jobs that wouldn't finish before the scheduled maintenance > outage starts won't be able to start at all, until after > the scheduled maintenance outage has ended (planned for > Tue night at midnight). > > Because, by this approach, such jobs can run for > the full wall clock time limit that they've requested. > > So, if you want a job to run before the scheduled > maintenance outage begins, then in your batch scripts, > you might need to reduce the amount of wall clock > time limit you request. > > (Once the maintenance period ends, this won't apply > any more.) > > If you have jobs that you've already submitted that are > pending in the queue, then you might want to reduce > their requested wall clock time limit, to give them > a chance to start before the scheduled maintenance > outage begins. > > The command is: > > scontrol update JobId=######## TimeLimit=DD-HH:MM:SS > > except REPLACE ######## with the job ID number, and > REPLACE DD-HH:MM:SS with 2-digit number of days, > 2-digit number of hours (beyond the number of days), > 2-digit number of minutes (beyond the days and hours) > and 2-digit number of seconds (beyond the days, hours > and minutes). > > You have to pick a wall clock time limit short enough that > the job can run to its time limit before the start of the > scheduled maintenance outage. > > For example, suppose job 123456 had requested 48 hours of > wall clock time limit, but now there are less than 48 hours > before the start of the scheduled maintenance outage. > > So job 123456 won't be able to run until > after the scheduled maintenance outage ends. > > But, we could change the requested wall clock time limit > for job 123456 to, for example, 30 hours, like this: > > scontrol update JobId=123456 TimeLimit=01-06:00:00 > > In that case, job 123456 would have a **CHANCE** > (but **NOT A GUARANTEE**) to run before the outage starts. > > Henry > > > > > > ------------------------------ > *From:* Neeman, Henry J. <[log in to unmask]> > *Sent:* Thursday, December 5, 2024 12:26 PM > *To:* OSCER users <[log in to unmask]> > *Subject:* Scheduled maintenance outage Tue Dec 10 6am through midnight CT > > > > OSCER users, > > REMINDER: > > Scheduled maintenance outage Tue Dec 10 6am through midnight > Central Time > > The Nov 26 outage reconfigured Side A; > the Dec 10 outage will reconfigure Side B. > > This will affect the supercomputer, but not OURdisk, OURcloud, > nor OURRstore. > > Planned maintenance tasks: > > OU Facilities Management will be finishing the reconfiguration > of the power systems that feed electricity to the rows > inside of the Four Partners Place Datacenter. This work is > expected to take all of Tuesday next week. As such we are > scheduling a downtime of our systems to accommodate the > electricians to complete the work described. > > The work for the project "16-25 4PP Computing Center Busbar > Feed reconfiguration" allows us to better distribute the > electrical load across the full breadth of the datacenter's > power distribution panels. This gives OSCER the ability to > have even more evenly distributed power utilization, which > gives us more available power per rack of servers. > > We expect the work to start by 7am Central Time on Tuesday. > Also, we expect the work to be finished by 11:59pm Central > Time on Tuesday, that same day. > > Time permitting, we'll also move a subset of scratch users from > older scratch server(s) to a new larger scratch system. > The user data will be copied to the new scratch system > in advance, so the transition is expected to be smooth. > > As always, we apologize for the inconvenience -- our goal > is to make OSCER resources even better! > > If you have any questions or concerns, please email us at: > > [log in to unmask] > > The OSCER Team >