TCP dropped packets

Post Reply
jmcarp
Posts: 1
Joined: Thu Jul 24, 2008 1:08 am
Location: University of Michigan

TCP dropped packets

Post by jmcarp »

I'm sending data through the ActiView TCP server to a Matlab program running on the same machine. It looks like about one packet in ten is lost. This isn't changed at different sampling rates or with different numbers of channels. How can I prevent packet loss and/or diagnose this problem?

Thanks--

Coen
Site Admin
Posts: 1124
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen »

TCP/IP is a handshaked protocol, packages cannot be lost without an error warning. ActiView can be checked with the LabVIEW client available from http://www.biosemi.com/download/ActiveTwoClient_8.zip . Testing shows that no packages are lost. There must be a bug in your Matlab client.

Best regards, Coen (BioSEmi)

Chanel
Posts: 17
Joined: Thu Dec 08, 2005 11:03 am

Post by Chanel »

Dear all,

I am using the Actiview TCP sever and get the data using sockets implemented in pythons. I am sending over the network the 32 EEG channel + EX1-8 + Aux. In this configuration I obtain a total buffer size of 564 (has written in the Actiview "Bytes in TCP array").

However it sometimes happened that the received data size was different than 564 (always lower since I read a maximum of 564 bytes at a time). I thus started to sniff the connexion for more information (with a professional tool not one of mine of course). Here is the result, 778 is of course the server:

[img]http://cvml.unige.ch/~chanel/BiosemiTraffic.jpg[/img]

As you can see the size of the packets sent are not always 564 and they are sometimes not a multiple of this value. Could you explain that ? I guess the solution is simply to read any data that comes and concatenate everything ?

I also sometimes get a ring buffer error when using the TCP Actiview connexion, any idea ?

Coen
Site Admin
Posts: 1124
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen »

It looks like your client cannot keep up with the incoming data stream. Because the TCP/IP link is handshaked, ActiView waits for the sent packets to be processed by the client. If the client is too slow, the buffer will overflow. This will cause an error and ActiView and lost packages in the client. Please test with the LabVIEW client as suggested in my earlier post.

Best regards, Coen (BioSemi)

Chanel
Posts: 17
Joined: Thu Dec 08, 2005 11:03 am

Post by Chanel »

Thank you for your fast answer Coen, as always,

You will find the result with the Actiview client here:
http://cvml.unige.ch/~chanel/BiosemiToBiosemi.jpg

Yes I was quite sure that the buffer errors came from the fact that the client was not getting the data fast enough (it actually occurs when my machine is slowed by tons of parallel processes). This is thus a confirmation.

Concerning the length of the data packets you will see from the picture that the problem is the same with the Biosemi client (packet length are different). So I ask my question again: should I just consider when a packet is not of the expected size, that it still contains my data continuously and that I can just concatenate it with the previous one.

Another side question, you will see that the client does not acknowledge each packet but approximately 1/3 packets, is it normal ?

Thanks in advance for your help,

Guillaume

Coen
Site Admin
Posts: 1124
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen »

The packets are always of the same size, I have never seen lost packages, lost packages have never been reported to us. The ActiView client will inevitable go out of sync when packets size is not constant (channels meshed up). You should incorporate buffering and priority for the TCP/IP client, to ensure that your client does not cause buffer errors in the ActiView server. When buffers error occur, then ActiView will always stop with an error message. Again: I have never seen or heard of lost packages without a stop and error pop up in ActiView.

Best regards, Coen (BioSemi)

Chanel
Posts: 17
Joined: Thu Dec 08, 2005 11:03 am

Post by Chanel »

I never mentioned that some packets were lost, just that the size of the packets can be different as shown by the sniffer (and the client) I used. I am not trying to accuse you of any mistake I just try to understand why the length of the packet I get are different and if I can still use them. I guess that by buffering you mean that I should concatenate the data I receive in a buffer, which partly answers my message. Still no idea about the ACK message send only 1/3 times ?

Chanel
Posts: 17
Joined: Thu Dec 08, 2005 11:03 am

Post by Chanel »

It seems that adding a buffer did solve the problem. I am now not far from having a python module for Biosemi Actiview acquisition. If you think it can be useful to someone else, I would be happy to give it to you.

rivasd
Posts: 3
Joined: Tue Aug 22, 2017 12:42 am

Re: TCP dropped packets

Post by rivasd »

I would be interested in your Python client! Mine, copied from this single hit on google drops out after a few seconds of reading data...

Post Reply