Robert N. M. Watson wrote:
On 13 Oct 2009, at 14:33, Ivan Voras wrote:
If (1) is highly variable during I/O, it's almost certainly a
property of
the VM technology you're using, and there's nought to be done about
it in
the guest OS.
Here's an example of a ping session with 0.1s resolution during a few
seconds-stall in ssh:
64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms
64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms
64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms
64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms
64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms
64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms
note huge packet loss. It looks like it's VM fault or something like it.
It sounds like the VM is failing to execute the guest during certain
types of I/O. A bit of scheduler tracing in the host OS probably
wouldn't go amiss to confirm that the VM really is suspending the guest
at about the same time ICMP latency goes up. However, given the above I
think I you can reasonable assume that the 4ms jump you're seeing there
is due to global host OS/VM scheduling, and not FreeBSD scheduling.
Btw. it's not a "4 ms jump" - there are 726 lost packets in between.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
