>>You should look at the physical network to see where the packets are getting lost or delayed, since it is possible that it could be happening in any of a number of places. I did a primary debugging and saw that time taken between eth0(saw using tcpdump) and vport_receive is ~ 40 ms. I will see this in more detail.
>>Do you see retransmissions in the control connection (which could account for delays)? I dont see any retransmission in the control connection level, as the delay is not that much significant. >>As an aside, it's not a very good idea to tunnel your data plane Ethernet traffic over a TCP connection like this, due to the mismatch in service that each provides. It will probably result in needless overhead, unusual delays, etc. The controller is in primary stage, so I am tunneling all my traffic for now. thanks Vishal On Fri, Jan 7, 2011 at 12:45 AM, Jesse Gross <[email protected]> wrote: > I think you'll need to do some more debugging in order to get useful > help on this. You should look at the physical network to see where > the packets are getting lost or delayed, since it is possible that it > could be happening in any of a number of places. Do you see > retransmissions in the control connection (which could account for > delays)? > > As an aside, it's not a very good idea to tunnel your data plane > Ethernet traffic over a TCP connection like this, due to the mismatch > in service that each provides. It will probably result in needless > overhead, unusual delays, etc. > > On Fri, Dec 24, 2010 at 11:20 AM, Vishal Swarankar > <[email protected]> wrote: > > Just to add ~ > > > > When I make same setup over TCP, instead of SSL, then I don't see any > > difference for a packet size > PMTU or < PMTU. > > > > thnx > > > > On Fri, Dec 24, 2010 at 9:44 PM, Vishal Swarankar > > <[email protected]> wrote: > >> > >> Hi, > >> > >> I am doing a basic test of OVS for OVS to NOX connection over SSL. > >> > >> Setup > >> ======== > >> > >> Machine 1 ( OVS, 10.2.0.111 ) -- connected to NOX over SSL ( NOX > installs > >> a flow : forward all packets to CONTROLLER ) > >> > >> NOX : Whenever a packet comes forward it to all connected DPID. > >> > >> Machine 2 ( OVS, 10.2.0.121 ) -- connected to NOX over SSL ( NOX > installs > >> a flow : forward all packets to CONTROLLER ) > >> > >> > >> Tests > >> ========== > >> ping 10.2.0.121 > >> 9 packets transmitted, 9 received, 0% packet loss, time 8077ms > >> rtt min/avg/max/mdev = 1.897/4.439/22.558/6.409 ms > >> > >> ping -s 1450 10.2.0.121 -c 10 > >> 10 packets transmitted, 10 received, 0% packet loss, time 9087ms > >> rtt min/avg/max/mdev = 1.962/2.272/2.668/0.253 ms > >> > >> ping -s 1460 10.2.0.121 -c 10 > >> 10 packets transmitted, 8 received, 20% packet loss, time 9087ms > >> rtt min/avg/max/mdev = 2.128/2.855/5.691/1.104 ms > >> > >> ping -s 1472 10.2.0.121 -c 10 > >> 10 packets transmitted, 8 received, 20% packet loss, time 9098ms > >> rtt min/avg/max/mdev = 1.995/2.332/2.684/0.225 ms > >> > >> ping -s 1473 10.2.0.121 -c 10 --- CROSSED the MTU size ( PMTU > discovery > >> results in 1500 ) > >> 10 packets transmitted, 8 received, 20% packet loss, time 9088ms > >> rtt min/avg/max/mdev = 40.655/40.749/40.900/0.258 ms > >> > >> ========================= > >> I have tried this experiment 50000 times with the same results. After a > >> packet size of ~1450, I can see packet loss and the moment packet size > >> crosses PMTU, the response time jumps 20 times ( from 2 ms to 40 ms ). > >> > >> I tried to simulate same behavior with a simple tcp client/server. > Please > >> see the dump of a packet reception and its response from server. The > dump > >> was taken at eth0 of tcp server. > >> > >> 10.2.0.201 ( client ) sends a packet of size of 1448 to 10.2.0.121( > server > >> ). > >> =========================== > >> 14:10:14.234892 IP 10.2.0.201.5005 > 10.2.0.121.5001: Flags [P.], seq > >> 744272:745720, ack 16449, win 30720, options [nop,nop,TS val 2180291 ecr > >> 2141105], length 1448 > >> Immediate ACK from Server Machine for 1448 byte packet -->> > >> 14:10:14.234912 IP 10.2.0.121.5001 > 10.2.0.201.5005: Flags [P.], seq > >> 16449:16481, ack 745720, win 32, options [nop,nop,TS val 2141106 ecr > >> 2180291], length 32 > >> > >> > >> > >> 10.2.0.201 ( client ) sends a packet of size of 1548 to 10.2.0.121( > server > >> ). > >> =========================== > >> 14:12:20.400152 IP 10.2.0.201.5005 > 10.2.0.121.5001: Flags [.], seq > >> 29513:30961, ack 640, win 30720, options [nop,nop,TS val 2192911 ecr > >> 2153722], length 1448 > >> A delayed ACK from Server Machine for 1448 byte packet -->> > >> 14:12:20.439894 IP 10.2.0.121.5001 > 10.2.0.201.5005: Flags [.], ack > >> 30961, win 32, options [nop,nop,TS val 2153730 ecr 2192911], length 0 > >> > >> Rest of the packet (100 bytes) > >> 14:12:20.440539 IP 10.2.0.201.5005 > 10.2.0.121.5001: Flags [P.], seq > >> 30961:31061, ack 640, win 30720, options [nop,nop,TS val 2192911 ecr > >> 2153722], length 100 > >> Immediate ACK from Server Machine for 100 byte packet -->> > >> 14:12:20.440563 IP 10.2.0.121.5001 > 10.2.0.201.5005: Flags [.], ack > >> 31061, win 32, options [nop,nop,TS val 2153730 ecr 2192911], length 0 > >> > >> > >> > >> thanks > >> Vishal > > > > > > _______________________________________________ > > dev mailing list > > [email protected] > > http://openvswitch.org/mailman/listinfo/dev_openvswitch.org > > > > >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
