Skip to content

Cray MPICH tips

Remarks from the November 2023 hackathon

  • Using hugepages can improve intra-node performance (or performance overall?)

  • Intra-node performance can improve by setting

    export MPICH_SMP_SINGLE_COPY_MODE=NONE
    

    at least for large message sizes.

    (Partly) documented in the intro_mpi man page.

OFI error messages and potential workarounds

  • PLTE_NOT_FOUND

    Error message:

    MPIDI_OFI_handle_cq_error(1062): OFI poll failed (ofi_events.c:1064:MPIDI_OFI_handle_cq_error:Input/output error - PTLTE_NOT_FOUND)
    

    HPE Cray recommendation:

    export FI_CXI_MSG_OFFLOAD=0
    export FI_CXI_REQ_BUF_COUNT=200
    

    These are undocumented environment variables.

  • UNDELIVERABLE

    Error message:

    MPIDI_OFI_handle_cq_error(1067): OFI poll failed (ofi_events.c:1069:MPIDI_OFI_handle_cq_error:Input/output error - UNDELIVERABLE)
    

    One possible cause is a broken switch so that messages can no longer be delivered.

    • Symptoms on the GPU nodes: A pattern of a number of subsequent either even-numbered or odd-numbered nodes.

Other MPI error messages

  • xpmem_attache failed on

    Error message:

    MPIDI_CRAY_XPMEM_do_attach(482)...........: xpmem_attach failed on rank 5 (src_rank 20, vaddr 0x3abf5b20, len 2400)
    

    It is a memory registration cache bug. The default MR monitor is known to be buggy. The memory registration cache keeps track of what memory regions have been pinned and mapped to the network interface. A bug in the registration cache monitor can have some unexpected side effects, like memory regions deallocated by the code might not be correctly unregistered, which can result in future buffers that share the same virtual addresses being mapped incorrectly or thrown back. Steve Abbott (HPE Frontier support) thinks memhooks is better but hasn't gotten much testing yet, and long term (towards the end of 2023) HPE intends to implement a solution that makes it irrelevant and is better all around.

    Solutions:

    • Preferred:

      export FI_MR_CACHE_MONITOR=memhooks
      

      to use the memhooks memory monitor.

      Undocumented (or has this become irrelevant in the current versions)?

    • Alternative:

      export FI_MR_CACHE_MAX_COUNT=0
      

      which turns off the memory registration cache all together but mibht be pretty punishing on performance (code-dependent).

      Documented in the intro_mpi man page.

Investigating crashes

Based on tips from Juha Jaykka.

  • Use sacct to figure out what nodes a job is using and in what time interval it ran:

    sacct --job=$jobid --format=JobID,JobName,State,ExitCode,Start,End,NodeList%1000
    
  • Now use sacctmgr to list events on those nodes during the time window. You can copy-paste date/times and the nodelist from the previous command:

    sacctmgr list event Start=<starttime> End=<endtimne> Nodes=<nodelist> format=NodeName,TimeStart,Reason%150
    
  • Sometimes you can get more information about a specific node with a fault via scontrol show node. So for a faulty node from the previous command, you can run:

    scontrol show node <nodename or nodelist>
    

Note that after many node failures, a node goes automatically into drain mode, so it does not make sense to manually exclude them in your job scripts.