I'm testing connection with flash client and cloud server(boost::asio for software) over TCP connection. My connection with server already is really poor - 120 ms ping in average. I found when i start to send packets with 2 bytes size (without tcp header) with speed 30 packets/s - ping grow to 170-200 average. I think that it's really bad and my bad connection and bad cloud provider is reason for this high ping without any load. What do you think? (I tested my software - it can compute about 50k small packets/s so software is not a problem).

I measure my ping through flash client - send packet with timestamp and immediatly send from server to client.

  • 1
    Note that when he says "ping", he actually means application response time measured over TCP. (He mentions this in his last paragraph, but it's easy to miss it.) – David Schwartz Oct 21 '12 at 16:38
  • Did you actually measure 30 small packets per second on the network? Or are you assuming that you're getting 30 small packets per second because you're doing 30 small writes per second? – David Schwartz Oct 21 '12 at 16:44
  • Yes i do 30 small writes with simple data structure without disconnecting and i call it packet – Denis Ermolin Oct 21 '12 at 16:46
  • Learn a valuable lesson and never do that again. If you start confusing application-level TCP concepts with network-level TCP concepts, you'll never get TCP right. :) – David Schwartz Oct 21 '12 at 16:48
  • I'd like to use UDP for transfering small chunks of data but web flash player doesn't support it – Denis Ermolin Oct 21 '12 at 16:49

My connection with server already is really poor - 120 ms ping in average.

I did a similar test to www.google.com, testing response time over TCP, and got 160 milliseconds. Does Google have poor connectivity? TCP was not designed for quick response times.

I measure my ping through flash client - send packet with timestamp and immediatly send from server to client.

TCP, by design, delays up to 200 milliseconds to provide more effective network utilization. You are not measuring anything except TCP specifically doing what it is designed to do. If you look closely at the network traffic, you'll see that most of the TCP packets actually contain much more than two bytes of data.

You are expecting horribly inefficient behavior. Sending 30 packets per second each containing only two bytes of data is incredibly dumb and TCP isn't stupid enough to do that.

Two suggestions:

Don't call this "ping". That makes people think it's a network round-trip measurement rather than a measurement of response time over TCP.

Don't say "30 packets/s" unless you actually measured the network traffic. When you write some bytes to a TCP connection, there is no reason to expect that will correspond to a packet. Packets are network things. Writes to a TCP connection are application things. Confusing application and network level concepts will really mess you up when you deal with TCP.

Also, why are you doing so many small writes? Gather the data into larger writes. Yes, TCP will do this for you, but it's still much more efficient if you do this in your application.

If you're just doing these horrible small writes to test performance, just stop doing it. It won't give you useful data. If these horrible small writes replicate your actual usage scenario and response time is important, then you need to work on fixing your protocol so that it makes some kind of sense.

  • I have turned of Nagle's algorithm on server side, but i dont sure that flash application flushes buffer without delay – Denis Ermolin Oct 21 '12 at 16:45
  • That's very bad. You're intentionally giving TCP a horrible situation and then you're disabling the mechanism it uses to cope with precisely that horrible situation! The only time you disable Nagle is when you have an application that wasn't designed with TCP in mind. – David Schwartz Oct 21 '12 at 16:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.