* PCI-E networking
@ 2006-10-11 6:26 Apparao, Padmashree K
2006-10-11 7:00 ` James Harper
2006-10-11 9:28 ` Ian Pratt
0 siblings, 2 replies; 5+ messages in thread
From: Apparao, Padmashree K @ 2006-10-11 6:26 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 662 bytes --]
Hi,
I see a weird problem with networking under Xen. I am using 2 dual ports
PCI-e nics in my platform and a single PCI-X nic. Each PCI-E nic shares
an irq. Each port is on a different subnet.
In native linux I can get line rate in each port.
In Xen (custome xen-unstable) however, a ping on each subnet is very
slooow. A ping takes about 3000ms or even more.
In fact I downloaded the Xen 3.0.2-3 testing build of xen and I see the
problem there too. Has anyone seen this kind of behavior? Is this
related to the interrupt sharing of the ports?
Suggestions
Thanks
- Padma
[-- Attachment #1.2: Type: text/html, Size: 5152 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: PCI-E networking
2006-10-11 6:26 Apparao, Padmashree K
@ 2006-10-11 7:00 ` James Harper
2006-10-11 9:28 ` Ian Pratt
1 sibling, 0 replies; 5+ messages in thread
From: James Harper @ 2006-10-11 7:00 UTC (permalink / raw)
To: Apparao, Padmashree K, xen-devel
> In Xen (custome xen-unstable) however, a ping on each subnet is very
> slooow. A ping takes about 3000ms or even more.
Is that 3000ms for the first reply or every reply?
Make sure that you ping the IP address and use the -n option to make
sure that DNS is not causing any issues.
Then start a ping and do a tcpdump of icmp and arp packets and send the
results of the first 3 pings or so here. "tcpdump -I eth0 icmp or arp"
should do the trick.
James
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: PCI-E networking
2006-10-11 6:26 Apparao, Padmashree K
2006-10-11 7:00 ` James Harper
@ 2006-10-11 9:28 ` Ian Pratt
1 sibling, 0 replies; 5+ messages in thread
From: Ian Pratt @ 2006-10-11 9:28 UTC (permalink / raw)
To: Apparao, Padmashree K, xen-devel
> I see a weird problem with networking under Xen. I am using 2 dual
ports
> PCI-e nics in my platform and a single PCI-X nic. Each PCI-E nic
shares an
> irq. Each port is on a different subnet.
>
> In native linux I can get line rate in each port.
>
> In Xen (custome xen-unstable) however, a ping on each subnet is very
> slooow. A ping takes about 3000ms or even more.
>
> In fact I downloaded the Xen 3.0.2-3 testing build of xen and I see
the
> problem there too. Has anyone seen this kind of behavior? Is this
related
> to the interrupt sharing of the ports?
Odd. First thing to try is switching to xen-unstable or 3.0.3-testing
there have been some interrupt changes, but still no MSI support, I'm
afraid.
Ian
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: PCI-E networking
@ 2006-10-11 16:56 Apparao, Padmashree K
2006-10-11 18:22 ` Christopher G. Stach II
0 siblings, 1 reply; 5+ messages in thread
From: Apparao, Padmashree K @ 2006-10-11 16:56 UTC (permalink / raw)
To: James Harper, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 4060 bytes --]
Thanks.
Here is the output. BTW these cards are PCI-MSI, if that makes a
difference.
Thanks- Padma
Ping -n Stats
>>>> ping -n 192.168.133.2
PING 192.168.133.2 (192.168.133.2) 56(84) bytes of data.
64 bytes from 192.168.133.2: icmp_seq=0 ttl=64 time=2400 ms
64 bytes from 192.168.133.2: icmp_seq=1 ttl=64 time=1400 ms
64 bytes from 192.168.133.2: icmp_seq=15 ttl=64 time=2410 ms
64 bytes from 192.168.133.2: icmp_seq=16 ttl=64 time=1410 ms
64 bytes from 192.168.133.2: icmp_seq=17 ttl=64 time=410 ms
64 bytes from 192.168.133.2: icmp_seq=18 ttl=64 time=7070 ms
64 bytes from 192.168.133.2: icmp_seq=19 ttl=64 time=6070 ms
Ping with tcpdump with icmp
>>>>ping 192.168.133.2
PING 192.168.133.2 (192.168.133.2) 56(84) bytes of data.
>From 192.168.133.1 icmp_seq=0 Destination Host Unreachable
>From 192.168.133.1 icmp_seq=1 Destination Host Unreachable
>From 192.168.133.1 icmp_seq=2 Destination Host Unreachable
64 bytes from 192.168.133.2: icmp_seq=3 ttl=64 time=1990 ms
64 bytes from 192.168.133.2: icmp_seq=4 ttl=64 time=990 ms
64 bytes from 192.168.133.2: icmp_seq=5 ttl=64 time=15.6 ms
64 bytes from 192.168.133.2: icmp_seq=6 ttl=64 time=4010 ms
64 bytes from 192.168.133.2: icmp_seq=7 ttl=64 time=3010 ms
64 bytes from 192.168.133.2: icmp_seq=8 ttl=64 time=2010 ms
64 bytes from 192.168.133.2: icmp_seq=9 ttl=64 time=1010 ms
64 bytes from 192.168.133.2: icmp_seq=10 ttl=64 time=10.7 ms
--- 192.168.133.2 ping statistics ---
22 packets transmitted, 8 received, +3 errors, 63% packet loss, time
21021ms
rtt min/avg/max/mdev = 10.743/1631.395/4010.772/1316.715 ms, pipe 6
>>> tcpdump -i eth7 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth7, link-type EN10MB (Ethernet), capture size 96 bytes
23:43:32.021469 IP 192.168.133.1 > 192.168.133.2: icmp 64: echo request
seq3
23:43:32.021473 IP 192.168.133.1 > 192.168.133.2: icmp 64: echo request
seq4
23:43:32.021751 IP 192.168.133.2 > 192.168.133.1: icmp 64: echo reply
seq 3
23:43:32.021754 IP 192.168.133.2 > 192.168.133.1: icmp 64: echo reply
seq 4
23:43:32.030887 IP 192.168.133.1 > 192.168.133.2: icmp 64: echo request
seq5
23:43:32.046498 IP 192.168.133.2 > 192.168.133.1: icmp 64: echo reply
seq 5
23:43:33.030840 IP 192.168.133.1 > 192.168.133.2: icmp 64: echo request
seq6
38 packets captured
38 packets received by filter
0 packets dropped by kernel
Ping with tcpdump arp
>>> ping 192.168.133.2
PING 192.168.133.2 (192.168.133.2) 56(84) bytes of data.
64 bytes from 192.168.133.2: icmp_seq=0 ttl=64 time=2896 ms
64 bytes from 192.168.133.2: icmp_seq=1 ttl=64 time=1890 ms
64 bytes from 192.168.133.2: icmp_seq=2 ttl=64 time=890 ms
64 bytes from 192.168.133.2: icmp_seq=3 ttl=64 time=28390 m34 packets
transmitted, 32 received, 5% packet loss, time 33015ms
rtt min/avg/max/mdev = 380.263/13214.810/28390.176/8765.006 ms, pipe 30s
>>> tcpdump -i eth7 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth7, link-type EN10MB (Ethernet), capture size 96 bytes
0 packets captured
8 packets received by filter
0 packets dropped by kernel
-----Original Message-----
From: James Harper [mailto:james.harper@bendigoit.com.au]
Sent: Wednesday, October 11, 2006 12:00 AM
To: Apparao, Padmashree K; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] PCI-E networking
> In Xen (custome xen-unstable) however, a ping on each subnet is very
> slooow. A ping takes about 3000ms or even more.
Is that 3000ms for the first reply or every reply?
Make sure that you ping the IP address and use the -n option to make
sure that DNS is not causing any issues.
Then start a ping and do a tcpdump of icmp and arp packets and send the
results of the first 3 pings or so here. "tcpdump -I eth0 icmp or arp"
should do the trick.
James
[-- Attachment #1.2: Type: text/html, Size: 17489 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PCI-E networking
2006-10-11 16:56 PCI-E networking Apparao, Padmashree K
@ 2006-10-11 18:22 ` Christopher G. Stach II
0 siblings, 0 replies; 5+ messages in thread
From: Christopher G. Stach II @ 2006-10-11 18:22 UTC (permalink / raw)
To: Apparao, Padmashree K; +Cc: James Harper, xen-devel
Apparao, Padmashree K wrote:
>
>
> Thanks.
>
>
> Here is the output. BTW these cards are PCI-MSI, if that makes a difference.
>
> Thanks- Padma
>
> * *
>
1. Try a crossover directly to the other host.
2. Pay attention to ``netstat -s''
3. DNS wouldn't affect a ping RTT calculation
4. Try different cables, network hardware, destination host (with a
different kind of NIC)
--
Christopher G. Stach II
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-10-11 18:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-11 16:56 PCI-E networking Apparao, Padmashree K
2006-10-11 18:22 ` Christopher G. Stach II
-- strict thread matches above, loose matches on Subject: below --
2006-10-11 6:26 Apparao, Padmashree K
2006-10-11 7:00 ` James Harper
2006-10-11 9:28 ` Ian Pratt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.