<p dir="ltr">Sorry for mistake.<br>
For UDP, I mean the sever can receive the packet from client again. </p>
<p dir="ltr">Actually, I have analysis the tcpdump output, in my case, the client try to reconnect to the server again, but can not receive SYN+ACK, so it re-transmission after 1 second according to the client rule, and then try again.</p>
<br><div class="gmail_quote"><div dir="ltr">Pavel Emelyanov <<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>>于2015年7月14日 周二 19:37写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 07/13/2015 03:58 PM, Yanbao Cui wrote:<br>
> Hi,<br>
><br>
> Detail my scenarios as follows:<br>
><br>
> 1. Run a docker container on node A, the applications in it are VNC server and a simple UDP test program.<br>
><br>
> 2. Checkpoint it, and then restore it another node B<br>
><br>
> 3. After restore successful, we found the UDP test program need at least 0.5 seconds (if only this test<br>
> program in the container) to reconnect to peer.<br>
<br>
UDP to reconnect?<br>
<br>
> Also the TCP which is used by VNC, we found it need more time to reconnected from tcpdump.<br>
<br>
Can you check with tcpdump what the packet flow is? For TCP this can also be due to the<br>
window probe packet lost :( This probably should be fixed in the kernel.<br>
<br>
> in this scenario, it need about 1.5 seconds to recovery<br>
><br>
> 4. we ping the container ip with interval 0.1 when checkpoint/restore, and find that it only hang about 20ms during this procedure<br>
><br>
> summarize my test results:<br>
><br>
> the restore need about 0.5 seconds<br>
><br>
> after restore successful, it also need at least 0.5 seconds to recover the established connection which created before checkpoint. for the new created connection, such as ping, it can response immediately.<br>
><br>
> and I think there is no particular system call hangs.<br>
><br>
><br>
> On Mon, Jul 13, 2015 at 8:12 PM, Pavel Emelyanov <<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a> <mailto:<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>>> wrote:<br>
><br>
> On 07/12/2015 11:57 AM, Vasily Averin wrote:<br>
> > Re-addressed to criu mailing list<br>
> ><br>
> > On 12.07.2015 10:48, Yanbao Cui wrote:<br>
> >> Hi,<br>
> >><br>
> >> I am working on the docker checkpoint/restore use CRIU, and the time consuming is the key point we concerned.<br>
> >><br>
> >> I found a strange phenomenon that the created socket need additional at least 0.5 seconds to reconnect after<br>
> >> the docker restore done.<br>
><br>
> Can you shed more light on this -- is there any particular system call that hangs for 0.5<br>
> seconds or is it just a "criu restore" time you observe?<br>
><br>
> >><br>
> >> But if I create a new socket after restoring the docker , it will connect to the peer immediately.<br>
> >><br>
> >> No matter the connection uses TCP or UDP.<br>
> >><br>
> >> From the CRIU source code, I found that it will create a new socket with SO_REUSEADDR, and change the original fd to this new one. but I have no idea that why it need more time to recovery.<br>
> >><br>
> >> Could someone help me to explain it or give me some points?<br>
> >><br>
> >> Thanks very much!<br>
> >><br>
> >> --<br>
> >> Best Regards<br>
> >> Cui Yanbao | 崔言宝<br>
> >> --<br>
> >> 龍生玖天，豈能安於凡塵！<br>
> > _______________________________________________<br>
> > CRIU mailing list<br>
> > <a href="mailto:CRIU@openvz.org" target="_blank">CRIU@openvz.org</a> <mailto:<a href="mailto:CRIU@openvz.org" target="_blank">CRIU@openvz.org</a>><br>
> > <a href="https://lists.openvz.org/mailman/listinfo/criu" rel="noreferrer" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
> ><br>
><br>
><br>
><br>
><br>
> --<br>
> Best Regards<br>
> Cui Yanbao | 崔言宝<br>
> --<br>
> 龍生玖天，豈能安於凡塵！<br>
<br>
</blockquote></div>