At 7:10 AM -0400 4/9/10, James Carlson wrote:
On 04/09/10 04:41, Min Miles Xu wrote:
Maurice Volaski wrote:
64 bytes from thevaultinternal (172.16.1.2): icmp_seq=7955.
time=1545415.344 ms
On the Windows side, I see the pings being received and replied to.
This suggests to me it's the same problem described in the other
thread. And if you are right about that, it implies that even if I
could try a different NIC, it might still exhibit this behavior.
What's puzzling is why I can't seem to trigger it by running multiple
rsh threads and why many other users aren't experiencing it. It's not
a new problem. I've seen in way earlier builds, possibly b110!
Hmm, according to the dtrace output, it takes no more than 1799 ms for a
kernel's ICMP round-trip. But the ping output showed approaching 100
times longer. It seems to be something wrong inside the VM. Does
somebody else have any ideas?
Yes -- as I seem to say at least once a day: "try using 'ping -n'
instead; the symptoms you're reporting are consistent with name
resolution problems."
Are you trying to explain why after the network failure has occurred
why ping would suddenly start "working" again, but continually
misreport mildly delayed replies of 1500 ms in the millions? I'm not
sure that's significant to anything relating to the failure. When I
tried pinging with ping -n, the failure occurred as before, but I
didn't keep it running long enough to see ping start to work again
and report reply times. It's possible that it would have never
started working again.
--
Maurice Volaski, [email protected]
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University
_______________________________________________
networking-discuss mailing list
[email protected]
