Differences

This shows you the differences between two versions of the page.

--- quick:loadshedding [2022/07/15 12:04]
wikiadmin
+++ quick:loadshedding [2022/07/15 13:31] (current)
wikiadmin
@@ Line 1: / Line 1: @@
 ======Electrical Power and Load Shedding======
-Unfortunately, the CHPC is subject to load-shedding (under the City of Cape Town) when Eskom has reduced generation capacity.
+Unfortunately, the CHPC is subject to load-shedding (under the City of Cape Town schedule) when Eskom has reduced generation capacity.
-While the CHPC has a 1000 kVA generator this is not sufficient to power the entire cluster during blackouts and only 10 of the compute racks will be available.
+While the CHPC has a 1000 kVA generator, this is not sufficient to power the entire cluster during blackouts and only 10 of the compute racks will be available.
 **Please plan accordingly.**
@@ Line 11: / Line 11: @@
 There are steps you can take to make more effective use of the cluster when it is operating at reduced capacity. Many of these are also useful outside of load-shedding events as well.
-**The following actions will allow your job to start running sooner and remain queued for a shorter time:**
+**The following actions will help your job to start running sooner and remain queued for a shorter time:**
-====1. Please check whether each of your jobs is very necessary.====
+====1. Prioritise your most urgent jobs.====
-Please plan your work so that only the needed jobs are run.  Making your workflow more efficient will help you make more effective use of the cluster.
+Please plan your work so that only the most urgently needed jobs are submitted.  Making your workflow more efficient will help you make more effective use of the cluster. Please be cautious and check you've set up your job correctly.
 ====2. Choose as short a walltime as appropriate.====
-Select the walltime such that your job will have passed and written checkpoint files, so that you can then submit subsequent jobs to continue your calculation. It will help if you increase the frequency of checkpoint file outputs when possible. You can also choose the walltimes according to your working hours and schedule.
+Select the walltime such that your job will have passed and written checkpoint files, so that you can then submit subsequent jobs to continue your calculation. It will help if you increase the frequency of checkpoint file outputs when possible. You can also choose the walltimes according to your working hours and schedule.  **Please** put extra effort into estimating walltimes.  Scheduling becomes more efficient when walltime estimates are more accurate.
 ====3. Select fewer nodes for your job.====
@@ Line 37: / Line 37: @@
 When there are a surplus of nodes on the cluster, one might choose to use 6 nodes (8 nodes would be a very poor choice as it's inefficient and wasteful). During load-shedding when the cluster is oversubscribed, choosing 2 nodes (or even 1 node) would be a good idea.
-====4. Make sure to be using checkpoints as well as possible.====
+====4. Use efficient checkpoints.====
-It will help if you increase the frequency of checkpoint file outputs when possible, to submit shorter jobs.
+Breaking a very long running job into shorter job runs using checkpoints will help with queuing times. If you already use checkpoints, it will help if you increase the frequency of checkpoint file outputs when possible, to submit shorter jobs.
-====5. Testing of a new type of job/calculation====
+====5. Testing of a new type of job/calculation. ====
+When testing a new job script, either use an [[quick:start#example_interactive_job_request| interactive job]], on a single node, or a very very short job (maybe 15 mins). This way you will know your job will work, and then you can submit your actual longer job thereafter. You can thus avoid waiting hours or even days to find your job failed, due to perhaps a small error in your input file. Most importantly, **test!**  Please read our section on [[howto:tipsandtricks#please_slow_down_and_work_methodically|working methodically]].
+====6. Check how well your job is running. ====
+Always check to see if your job is working correctly:
+  - Is it producing the expected output at the expected rate?
+  - Are you fully using all the compute cores that you requested?
+You can ssh into your assigned nodes once your job has started running and monitor activity with ''top'' or ''htop''.
+So to determine which node number/s your job is using:
+  qstat -u yourusername -n
+Then ssh into this node/s, for example
+  ssh cnode0123
+  htop
-When testing a new job script, either use an interactive job, on a single node, or a very very short job (maybe 15 mins). This way you will know your job will work, and then you can submit your actual longer job thereafter. You can thus avoid waiting hours or even days to find your job failed, due to perhaps a small error in your input file.

wiki.chpc.ac.za

User Tools

Site Tools

Differences

Page Tools