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.
Robert
_______________________________________________
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"
