# TCP throughput



## zzzamir (Jun 7, 2007)

Hello,

I am building an application that connects to a recording device and receives 1 megabit/second continuous over a TCP/IP client connection. During testing the connection looses data over a short period, such as 12 to 24 hours. We need the system running 24/7.

Can anyone suggest how we can achieve this either by hardware or software settings. We are using Borland's Delphi 7 compiler to build the application. The object we are using is the tclientsocket. We are also settting the TCP window size using a WinAPI call 

setsockopt(socket.SocketHandle,SOL_SOCKET,SO_RCVBUF,@socsize,sizeof(socsize));

No matter what we set the TCP window size to we always see data loss over a short time.

Thanks for all your help.

Maria


----------



## JohnWill (Oct 19, 2002)

Well, there's not nearly enough information to offer an opinion. There can be many reasons for this to happen.

Is this device that you're receiving data from on a dedicated connection to the computer, or is it on a network with other contention? Is the connection TCP or UDP? What is the speed of the network link, 10/100/1000?

Of course, some sort of programming error or simply contention in the system by other tasks could cause this issue too.


----------



## JohnWill (Oct 19, 2002)

I moved you over to development, which is a better fit for this issue.


----------



## zzzamir (Jun 7, 2007)

Thanks for your reply John.

It is a dedicated network. We have a DELL laptop connected to a netgear 10/100 megabit ethernet switch and the recording devices are connected to the ethernet switch.

We currently have 4 devices connected. Our delphi appplication is receiving 1 megabits/second from each device. It can run about 24 hours before we start losing data on one the devices. The other 3 keep running fine with no problems. We can tell data loss by opening a terminal window and seeing the data come in. 

Our main objective now is to determine if there is a problem with the recorder or our application or with the settings for the TCP window.

On our last test; after 24 hours one of the devices started to slow down. We closed our application, closing the TCP connection then we reran our app and reconnected to the devices and the one recorder that slowed down was still slow. Can this be an indicator that there is problem with the recorder.

Thanks for all your help.


----------



## O111111O (Aug 27, 2005)

Running on a lan like that you should be able the smallest window possible and still be able to maintain that data rate. 
The big question is how this connection is dropped. Be it via tcp fin or rst.
Can you install wireshark and get a sample of data?

Also, have you looked at simple causes such as duplex mismatch, or something such as a software firewall prematurely closing the connection?

If you get wireshark installed look for late collisions, retransmissions.


----------



## O111111O (Aug 27, 2005)

Sorry for format, typing this on pda. WRT your last paragraph, i would again need to see sniffer, but i would conject that the recorder may be seeing dup acks or retransmissions.


----------



## zzzamir (Jun 7, 2007)

Thanks for the reply.

The funny thing is the connection is not dropped just the data rate the recorder is shipping at slows down which causes loss of data. Someone suggested to get a managed etherent switch instead of an unmanaged switch. They said the etherent switch is requesting that the device slow down it's data rate.

We did get Microsoft's Network Monitor 3.0 app but it recorded everything that was happening on the network. The file it generated was huge and very hard to navigate. Does wireshark have the ability to only record errors and reasons why a data rate is slowed down.


----------



## O111111O (Aug 27, 2005)

Well, that would be flow control or Ethernet back pressure. The linksys does neither. It's a very cheap store & forward switch. 

A managed switch will help you with troubleshooting (create SPAN ports), and will let you force speed/duplex on the switchport (a good idea to do on switch & host.)

Wireshark has some filters. You can filter for collisions, retransmissions, etc. The problem is, you may have to capture gigs of data to find the good stuff. Having said that, you can also capture just the headers - which may help with this.


----------



## JohnWill (Oct 19, 2002)

I can't believe the switch has anything to do with this issue. I'd be looking to see what WireShark sees too, that's probably the best bet right now.


----------



## O111111O (Aug 27, 2005)

My only thought with switch was duplex mismatch. Fairly common, looks close to this issue.

Ton of retransmissions on the host would tell you. Ideally you would span/tap the recorder, but you can't create a SPAN port with an unmanaged switch....


----------



## zzzamir (Jun 7, 2007)

Thank you for your reply.

We downloaded wireshark and we are currently running a capturing session. 

More info:

What we might think is happening is that our client application (built in Delphi 7 - tclientsocket) is not receiving the data fast enough and the TCP window buffers are overflowing causing the recorders to slow down transmission speed. Our Delphi client sockets are nonblocking and our TCP window size for each socket is 1 mega. We are relying on microsoft calling our client read method to receive the data.

Is there anything is wireshark that alerts when the TCP window size is overflowing and who is causing the overflow.

Thanks for all your help it is greatly appreciated.


----------



## zzzamir (Jun 7, 2007)

John and O111111O,

We ran wireshark and after 3 hours into the test wireshark shut down with an out of memory problem. We quickly ran another test from a different directory. Hopefully this one will last. Any reason why they would run out of memory? 

Thanks...


----------



## JohnWill (Oct 19, 2002)

You're collecting a ton of data. Typically, you'd want to filter the collection so you don't have so much data to sift through.


----------



## zzzamir (Jun 7, 2007)

Thanks Jim,

Unfortunatelly we need to analysis all of the data coming in. Each recorder has eight sensors attached and the sensors are monitoring electric wires. We need to detect if a fault happens on the electrical lines, so we need constant monitoring. 

Wireshark seems to be no help since it is taking to much CPU time and bogging down the network. After 2 hours our app lost connection to both recorders and the TCP window size started to shrink to 0. We never encountered a loss of the connection just a slow dow in transmission.

Are there any monitoring tools that just monitor the TCP window for each socket and not everything.

Thanks


----------



## zzzamir (Jun 7, 2007)

Sorry Jim,

I thought you meant filter data in our app. I found an app called Window IP & Socket Monitor hopefully this app won't save so much data. I'll let you know.

Thanks.


----------



## JohnWill (Oct 19, 2002)

I'm not sure who Jim is, but I was referring to having WireShark filter the data so you didn't try to save everything.


----------

