Friday Afternoon Brain Storming - TCP/IP vs UDP
Discussion
Question is which to use?
Scenario:
A Client Sends event information to a server for parsing and insertion into database.
Each event string sent from the client to the server is typically 250 bytes but could be upto 1024 bytes in length.
The client end is written in C++, the server side is written in Java.
Currently we are pushing about 1900 events per second with the client running flat out 99%cpu.
Now, which transport to use for getting the event strings over to the server? TCP/IP or UDP?
The overhead with TCP acking etc, would lead us to believe that UDP should be faster.
However, our tests indicate that using UDP is slower than using TCP/IP, to the tune of about 400 events/sec.
The machines are on the same LAN, and we've also tried running both client and server software on the same host - not much difference.
So this leads me to believe that the application overhead in preparing a UDP packet at the client, getting it onto the network, then receiving and decoding it at the server is greater than running a TCP socket and just print-lining down the socket at one end and read-lining from it at the other.
My guess is that if we moved the client and server apart in terms of network latency then we would see udp over take tcp/ip in terms of through-put as the latency for the acks starts to become measurable.
Thoughts?
Scenario:
A Client Sends event information to a server for parsing and insertion into database.
Each event string sent from the client to the server is typically 250 bytes but could be upto 1024 bytes in length.
The client end is written in C++, the server side is written in Java.
Currently we are pushing about 1900 events per second with the client running flat out 99%cpu.
Now, which transport to use for getting the event strings over to the server? TCP/IP or UDP?
The overhead with TCP acking etc, would lead us to believe that UDP should be faster.
However, our tests indicate that using UDP is slower than using TCP/IP, to the tune of about 400 events/sec.
The machines are on the same LAN, and we've also tried running both client and server software on the same host - not much difference.
So this leads me to believe that the application overhead in preparing a UDP packet at the client, getting it onto the network, then receiving and decoding it at the server is greater than running a TCP socket and just print-lining down the socket at one end and read-lining from it at the other.
My guess is that if we moved the client and server apart in terms of network latency then we would see udp over take tcp/ip in terms of through-put as the latency for the acks starts to become measurable.
Thoughts?
Assuming you're doing any arbitration and retry stuff yourself, it's probably just that your code isn't as optimal as that of the driver. The IP stack is so well defined, I'd not be at all surprised if some of it is implemented in hardware, even on common NIC's. If that is so you're going to have one heck of a time trying to beat it in software.
There are a raft of intangible costs associated with using UDP, so why bother? Surely it's just better to use TCP, and increase your bandwidth to suit the application. I suppose the time that you move away from TCP, is when the hardware you choose doesn't support it.
There are a raft of intangible costs associated with using UDP, so why bother? Surely it's just better to use TCP, and increase your bandwidth to suit the application. I suppose the time that you move away from TCP, is when the hardware you choose doesn't support it.
Edited by dilbert on Friday 20th July 16:22
Interesting thoughts....
I'm still having a hard time convincing one of my developers that TCP can in fact run faster than UDP, but as said, if alot of it (the stack) is done in hardware then no way is the OS/Application layer going to keep up on a LAN/Same Host.
My guess as I mentioned is that UPD won't (under these assumptions) run faster than TCP/IP untill there is a sufficient latency (RTT) between the two hosts such that providing you are not dropping packets, the overhead of waiting for the TCP Ack can be out performed by a straight forward burst/streaming protocol like UDP.
I'm still having a hard time convincing one of my developers that TCP can in fact run faster than UDP, but as said, if alot of it (the stack) is done in hardware then no way is the OS/Application layer going to keep up on a LAN/Same Host.
My guess as I mentioned is that UPD won't (under these assumptions) run faster than TCP/IP untill there is a sufficient latency (RTT) between the two hosts such that providing you are not dropping packets, the overhead of waiting for the TCP Ack can be out performed by a straight forward burst/streaming protocol like UDP.
That’s intriguing. I’ve written my own UDP TCP/IP stack on an 8-bit micro. Running the TCP sequencer hammered the MCU wen compared to UDP which flew. Its got to be as others have said (sequenncer implemented in hardware). What actually is your app? I would have thought for your app, its better off with TCP becuase rolling your own confirmation routine in UDP doesnt really seem like the best way in such a platform as Windows - just seems like overcomplicating things. Why is it so data intensive? Is it a banking app updating the status of stocks and shares?
Edited by polus on Friday 20th July 22:58
udp is the wrong protocol for a database application. upd is fire and forget, the application doesn't care if it hits the other end or not, so unless you are willing to accept data loss (unliely for a db application), then the protocol won't be what you want - regardless of how fast it goes.
any developer seriously considering using udp for such an application needs to be given a P45.
any developer seriously considering using udp for such an application needs to be given a P45.
tinman0 said:
udp is the wrong protocol for a database application. upd is fire and forget, the application doesn't care if it hits the other end or not, so unless you are willing to accept data loss (unliely for a db application), then the protocol won't be what you want - regardless of how fast it goes.
any developer seriously considering using udp for such an application needs to be given a P45.
... for the aforementioned application. I agree any developer seriously considering using udp for such an application needs to be given a P45.
For embedded apps, UDP with checksums enabled and a confirmation mechanism can be benifical but I cant imagine that is the same on a Windows platform.
OP: Have you profiled the communications, server and client apps to find out if any part of the chain is letting you down?
Edited by polus on Saturday 21st July 00:28
Another thought on this, is that you *might* be able to achieve better performance on a point to point UDP link (where losses *may* be negligable) by increasing the UDP packet length over and above a normal TCP packet.
You cant expect this to work over a large network, but if youre using 2 NICS with large buffers, and you want to use UDP, crank the packet size to the maximum that the hardware buffers support, and if it's considerably more than a standard TCP packet, you may begin to see a return on your investment.
Maybe!
You cant expect this to work over a large network, but if youre using 2 NICS with large buffers, and you want to use UDP, crank the packet size to the maximum that the hardware buffers support, and if it's considerably more than a standard TCP packet, you may begin to see a return on your investment.
Maybe!
You might want to have a peek here :-
http://www.psc.edu/networking/projects/tcptune/
and then here (if Windows) :-
http://www.dslreports.com/drtcp
http://www.psc.edu/networking/projects/tcptune/
and then here (if Windows) :-
http://www.dslreports.com/drtcp
tinman0 said:
any developer seriously considering using udp for such an application needs to be given a P45.
Steady on old chap! The goal here is performance, if a few records get lost due to UDP I can live with that.What is surprising is that TCP is outperforming UDP by some margin. We looked at UDP expecting it to be far better than TCP, but that's not the result we found.
)mystomachehurts said:
What is surprising is that TCP is outperforming UDP by some margin. We looked at UDP expecting it to be far better than TCP, but that's not the result we found.
Not sure if this is any help http://www.intel.com/technology/ioacceleration/306...
ThePassenger said:
I'd suspect that myself, almost everything is TCP these days (from the point of a consumer I mean) web, games, VoIP and so on.
Good lord no. Your VOIP connection will run in an RTP protocol, fired over something. RTP will certainly run over TCP, but if it's a real time packet - if it's lost, what's the point of asking TCP to retransmit it? So RTP over UDP is normal.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff