Re: Strange network behaviour

[Simon Gao <gao-g4dUTk+gKbW4mfPA/iJWtA@public.gmane.org>]

Mike wrote:
> Avi Kivity schrieb:
>   
>> Mike wrote:
>>     
>>> Sure,
>>> here the ping results from the host to the guest atm of the peaks:
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=347 ttl=64 time=10.6 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=348 ttl=64 time=11.6 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=349 ttl=64 time=11.6 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=350 ttl=64 time=465 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=351 ttl=64 time=455 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=352 ttl=64 time=349 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=353 ttl=64 time=314 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=354 ttl=64 time=483 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=355 ttl=64 time=871 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=357 ttl=64 time=1889 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=358 ttl=64 time=1635 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=359 ttl=64 time=1973 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=360 ttl=64 time=1796 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=361 ttl=64 time=1961 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=362 ttl=64 time=2029 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=363 ttl=64 time=1994 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=364 ttl=64 time=1689 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=365 ttl=64 time=932 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=366 ttl=64 time=899 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=367 ttl=64 time=752 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=368 ttl=64 time=860 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=369 ttl=64 time=483 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=370 ttl=64 time=244 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=371 ttl=64 time=7.89 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=372 ttl=64 time=5.98 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=373 ttl=64 time=6.31 ms
>>>
>>> The peaks started @ +/- 14:53:39 and ended @ +/- 14:53:59
>>> You can download the trace file at:
>>> http://www.eliteserver.biz/trace2.tar.gz
>>>
>>>
>>>   
>>>       
>> The traces show that the periods of latency correspond to floods of 
>> broadcast packets on the network
>>
>>     
>>>      10 29895 14:53:25
>>>       9 29895 14:53:26
>>>       9 29895 14:53:27
>>>       9 29895 14:53:28
>>>      16 29895 14:53:29
>>>      19 29895 14:53:30
>>>      19 29895 14:53:31
>>>      14 29895 14:53:32
>>>      13 29895 14:53:33
>>>      12 29895 14:53:34
>>>     205 29895 14:53:35
>>>     203 29895 14:53:36
>>>     276 29895 14:53:37
>>>     234 29895 14:53:38
>>>     234 29895 14:53:39
>>>     243 29895 14:53:40
>>>     234 29895 14:53:41
>>>     259 29895 14:53:42
>>>     228 29895 14:53:43
>>>     325 29895 14:53:44
>>>     242 29895 14:53:45
>>>     271 29895 14:53:46
>>>     251 29895 14:53:47
>>>     227 29895 14:53:48
>>>     178 29895 14:53:49
>>>     166 29895 14:53:50
>>>     271 29895 14:53:51
>>>     244 29895 14:53:52
>>>     287 29895 14:53:53
>>>     196 29895 14:53:54
>>>     215 29895 14:53:55
>>>      83 29895 14:53:56
>>>      65 29895 14:53:57
>>>      10 29895 14:53:58
>>>       9 29895 14:53:59
>>>      10 29895 14:54:00
>>>      14 29895 14:54:01
>>>      14 29895 14:54:02
>>>      12 29895 14:54:03
>>>      13 29895 14:54:04
>>>      16 29895 14:54:05
>>>       
>> The first column is the number of packets delivered at the time in the 
>> third column.  The broadcast packets are clearly visible in the trace 
>> as having \xff in the first 6 bytes of the packet.  The ping packet is 
>> getting queued behind the broadcasts and thus delayed.
>>
>> However, kvm is capable of much more than 200 packets/sec.  I get 
>> about 6500 here with a flood ping.  Can you try this on the host:
>>
>>   ping -f -q guest-ip
>>
>> Hit ctrl-C after a second or two and send the output.
>>
>> You can also try running wireshark on the host to capture the 
>> broadcast packets.  Maybe they cause some processing on the guest and 
>> slow it down.
>>
>>     
> 9066 packets transmitted, 9055 received, 0% packet loss, time 1956ms
> rtt min/avg/max/mdev = 0.078/0.171/16.659/0.181 ms, pipe 2, ipg/ewma 
> 0.215/0.213 ms
>
> The same time a tried a ping over the internet. No peaks.
>
> I also tried over a longer time, no peaks.
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   
I also saw the similar problem. However, it happens with I have several
KVM guests running and sharing the same network bridge. If just one
single KVM guest, then everything works fine.

Simon

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4