Streaming data via TCP/IP using Indy framework 10 in C++Builder XE2, performance issue.

Question

0.00/5 (No votes)

See more:

Hello world,

I want to provide measurement data of an USB-measurement-modul to clients via TCP/IP in my application.
I have to use C++Builder XE2 where Indy 10 is integrated. I use the IdTCPServer class of Indy to establish the server. The measurement data is written into a buffer. The IdTCPServer class provides an execute method that is handled in a separate thread and that is administered by the IdTCPServer-object. I use this method to get data from the buffer and send it to the connected client.

The data forwarding was tested and works, but there is an performance issue.
Sometimes I can send 11264 bytes in 1.5 ms and sometimes the sending time increases to 60 ms. Time was measured when I send the data from the server-application to a ncat-client, both executed on my computer. I did not use the network for anything else in that time (except of outlook-sync maybe).

Does anyone have an idea where I should look for why it is increasing like this?

Thank you.

Posted 3-Dec-15 4:25am

Georg Newton

Add a Solution

Comments

Sergey Alexandrovich Kryukov 3-Dec-15 10:55am

The is nothing wonderful here. All Internet networking is probabilistic by the very nature...
—SA

Albert Holguin 3-Dec-15 22:24pm

Probably buffering due to default MTU size, that amount of data is actually less than the standard 1500 byte MTU size commonly used.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Albert Holguin · Answer 1 · 2015-12-03T16:23:00

Solution 1

That's actually not that much data, so your OS is probably buffering data and waiting to transmit that at a later time (in case there's more to come).

Check your MTU size (likely in the 1500 bytes range) and perhaps try reducing that size to something small (in Linux you can run sudo ifconfig eth# mtu 400 for example). If changing that to some small value helps, well it confirms that your OS is buffering data and holding it for a bit before transmitting it to maximize transmit efficiency "on the wire". That's just the nature of dealing with TCP/IP streams.

Posted 3-Dec-15 16:23pm

Albert Holguin

Comments

Sergey Alexandrovich Kryukov 3-Dec-15 23:09pm

Makes sense, a 5.
—SA

Georg Newton 4-Dec-15 2:41am

Did I get you right, that you mean the OS is waiting till the MTU size is reached?
But 11264 bytes is much more than 1500 byes?

Albert Holguin 4-Dec-15 8:38am

I must have read your number wrong, I was thinking 1126... In that case, the MTU size should have been reached and the OS should have sent out a handful of packets. Try checking your MTU size anyway, its possible that it's set to a really large number which would cause this behavior.

Albert Holguin 4-Dec-15 9:17am

If you have Wireshark, another thing to look for is retransmissions. They should be pretty easy to spot with Wireshark, they're colored with a different color than a regular packet transfer. If retransmissions are occurring for whatever reason you'll also see this type of lag.