Thread Previous • Date Previous • Date Next • Thread Next |
Hi Julien, Today I tried to test GSE but I got another type of errors. Testbed setup: Return - ATM/AAL, Forward - GSE GW FIFO size 2180 (see attached file TCP_CW_GSE_1_flow_GW_buff_2180) iperf with the option -M 1400 Log from ST:/Jul 26 13:15:17 router st: [encap] [Gse.cpp:deencapPacket():658] ERR: [Gse::Context::deencapPacket] GSE deencapsulation failed (Packet is too long for the deencapsulation buffer: PDU dropped), drop packet// //Jul 26 13:15:22 router st: [dvb_rcs_tal] [bloc_dvb_rcs_tal.cpp:connectToQoSServer():1138] [Tal][BlocDVBRcsTal::connectToQoSServer] service on TCP/12000 is not available/
Log from GW :/Jul 26 13:17:37 router gw: [encap] [Atm.cpp:deencapAtm():384] ERR: [Atm::Context::deencapAtm] AAL5 packet is not valid, drop all of the ATM cells in the desencapsulation context// //Jul 26 13:17:37 router gw: [encap] [Atm.cpp:deencapsulate():164] ERR: [Atm::Context::deencapsulate] ATM desencapsulation failed, drop packet// //Jul 26 13:17:38 router gw: [dvb_rcs] [SatelliteTerminalList.cpp:setList():601] end of simulation file reached, restart at beginning.../
The example of CW with GW FIFO size 2500 is in the file TCP_CW_GSE_1_flow_GW_buff_2500 When I used iperf without option "-M" (file TCP_CW_GSE_1_flow_GW_def_MSS) I got another errors:
/Jul 26 13:51:06 router st: [encap] [Gse.cpp:deencapPacket():658] ERR: [Gse::Context::deencapPacket] GSE deencapsulation failed (CRC32 computed does not match the received one: PDU dropped), drop packet// //Jul 26 13:51:06 router st: [dvb_rcs_tal] [bloc_dvb_rcs_tal.cpp:connectToQoSServer():1138] [Tal][BlocDVBRcsTal::connectToQoSServer] service on TCP/12000 is not available/
Is there any way to avoid encapsulation errors? May be you can recommend iperf (or another traffic generator) parameters, OpenSand parameters which were proved to be stable during your experiments (packet size, ST/GW buffers, encapsulation types)?
Regarding your last question about small ST buffer. When I set up ST buffer equal to 10 I saw the following errors:
/Jul 26 14:12:37 router st: [dvb_rcs] [PhysicStd.cpp:onRcvEncapPacket():84] ERR: FIFO is full: drop packet// //Jul 26 14:12:37 router st: [dvb_rcs_tal] [bloc_dvb_rcs_tal.cpp:onEvent():333] ERR: SF#645: frame 2: unable to store received encapsulation packet (see previous errors)// //Jul 26 14:12:38 router st: [dvb_rcs_tal] [bloc_dvb_rcs_tal.cpp:connectToQoSServer():1138] [Tal][BlocDVBRcsTal::connectToQoSServer] service on TCP/12000 is not available/
What is the preferable way to upgrade OpenSand from version 1.0 to 2.0? I'll need to uninstall all packages of version 1.0 and then install the new ones?
Best regards, Andrei On 26/07/2013 11:09, Julien BERNARD wrote:
Hi Andrei,Yes, that's right. I use the same configuration and send traffic from WS behind the GW to WS behind the ST. And I don't run opensnad-network and opensand-daemon services on both workstations. I found that WS-daemon adds route to the network behind ST or GW. I use static routing instead. Please let me know if it's essential to run WS-daemon services and if they have another functions besides routing.You don't need to use the OpenSAND daemon on the workstation.They can be useful for our automatic tests or for tools deployments but it isn't your case.As I said in previous letters, all machines are virtual machines hosted on one single machine. And may be I should add that I use 1.0 version of OpenSand. The problem itself is random but in my case it can be reproduced on the second-forth experimental try after starting OpenSand. In fact, this problem appeared only when I started testing GW-to-ST direction. In ST-to-GW direction TCP worked fine with BE buffers in the range from 3000 to 30 000. With buffer less than 3000 TCP performance decreases and with very low buffers (don't remember exactly - may be 50-100) iperf refused to establish connection and send traffic.I assumed you were on version 2.0.0 so my tests are not relevant.Do you plan to install the 2.0.0 version ? It may solve your problems, as I said I got some crashes but not so often.For the TCP performances, they are bad with small buffers because the size is in number of packets and the ATM cells or MPEG packets are small compared to your IP packets. So, your queues are full after receiving a small amount of IP packets and you lost packets quickly.For very small buffer it is strange because iperf sends small packets at beginning and with a buffer size of 50-100 even with large packets you should be able to transmit some packets. Does OpenSAND reports errors in this case ?Best regards,
Attachment:
TCP_CW_GSE_1_flow_GW_def_MSS
Description: PNG image
Attachment:
TCP_CW_GSE_1_flow_GW_buff_2180
Description: PNG image
Attachment:
TCP_CW_GSE_1_flow_GW_buff_2500
Description: PNG image
Thread Previous • Date Previous • Date Next • Thread Next |