<div dir="ltr">On Thu, Jul 25, 2019 at 8:16 AM Mark Hahn <<a href="mailto:hahn@mcmaster.ca">hahn@mcmaster.ca</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">how about a timeout from elsewhere?  for instance, when I see a 30s delay,<br>
I normally at least check DNS, which can introduce such quantized delays.<br></blockquote><div><br></div><div>Thanks, it's a good guess, but is very unlikely the case.</div><div><br></div><div>The Google Cloud is quite different from a physical cluster. Speaking of DNS specifically, it is provided by what is called the "metadata service", which is tightly integrated with the rest of the platform. When a VM transitions into the STARTED state (as if "powered on" and begins the bootload sequence), this service immediately starts responding to DNS queries for its name (on other machines in the same "network"). It's kinda magic, as its IP is one and the same across the GCE, has no route to it, responds even if not whitelisted in the firewall, and is in in the link-local RFC3927 <a href="http://169.254.0.0/16">169.254.0.0/16</a> range. I think the VM's own "hardware" network stack IP offloader emulator or maybe the driver responds to these queries without sending any actual DNS packets anywhere. It never fails and responds unmeasurably fast (<1ms). (The same IP also pretends to be a DHCP server, and in addition can return a lot of information about the VM's own configuration over HTTP port 80 with curl. The common theme here is it responds only from inside the VM, and with different data depending what this VM is).</div><div><br></div><div>All the internal communication in the virtual "LAN" is extremely reliable. The only type of hiccups I am aware of is when a VM freezes for give or take 500ms when migrated to a different physical host--and these normally happen 1-2 times a month.<br></div><div><br></div><div>Besides, the logs show the node is talking to the controller during this timeout. I'll post these 3 lines from the node with the "slacking" job start again:<br></div><div><br></div><div>
Jul 24 14:14:27 xa-node-p100-1 slurmd[573]: debug:  _handle_node_reg_resp: slurmctld sent back 8 TRES.<br>Jul 24 14:14:47 xa-node-p100-1 slurmd[573]: debug:  _handle_node_reg_resp: slurmctld sent back 8 TRES.<br>Jul 24 14:14:51 xa-node-p100-1 slurmd[573]: task_p_slurmd_batch_request: 1646 <br></div><div><br></div><div>So in summary, the time sequence looks like:</div><div>
14:14:20 Controller logs that node ...-3 is online</div><div>14:14:21 Node ...-3 starts its task (and logs the 'task_p_slurmd_batch_request:' message)<br></div><div>14:14:22 
Controller logs that node ...-1 is online

</div><div>
14:14:27, 


14:14:47 - some background periodic exchanges happen with the node ...-1 (above snippet)<br></div><div>14:14:51 Exactly in 30s since the other node was given a task, the controller sends a similar request to the node ...-1 (and other nodes that came up during this time)<br></div><div><br></div><div>I never seen a discrepancy on the idle cluster if all nodes allocated to the batch are already up and running. But when they come online at random times over the 10-20 seconds they usually do, I always see the exact 30s difference between bunches of jobs of the same array in the R state (provided there is a difference, but most often than not there is if 5 or more nodes are staged at the same time).<br></div><div><br></div><div> -kkm<br></div></div></div>