Hi Doug, I uploaded the tcptrace results on http://groups.google.com/group/hypertable-dev/files.
The bigbuf.tar.gz and smallbuf.tar.gz include the tcptrace results on each node in the case of 40*32768 and 4*32768, respectively. Because both files exceed over 10MB, I split these files by split command. You can get the original tar.gz files cat bigbuf.tar.gz.a* > bigbuf.tar.gz The Hypertable.Master, Hyperspace.Master and DfsBroker processes were in the node named by mario01.dq.isl.ntt.co.jp. The Hypertable.RangeServer and DfsBroker processes were in the other nodes. >Oh I see. So the socket SO_SNDBUF, SO_RCVBUF increase was for the datagram >socket inside the method >Comm::create_datagram_receive_socket()? Yes. >If that's the case, then I suspect that Hyperspace is getting bombarded with >keepalive packets and dropping them >because it's socket buffer has filled up. I think so. >Another thing for you to try is to set the random startup delay factor to >something higher than 5 seconds in the Capfile. Try something like this: Ok, I will try later. Regards. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Hypertable Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hypertable-dev?hl=en -~----------~----~----~----~------~----~------~--~---
