Morning Fellas,
Was working on some socket progs based on some performance test objectives we had in mind. The objective is to stress the TCPIP stack in the GnuLinux kernel and see the best numbers achiveable over the network.
Am in a bit of a quandry here. We always were taught that the overheads of a tcp session were higher than that of UDP considering the ACK's and FIN's sent across for every packet over the n/w, while TCP guaranteed delivery....blah..blah and UDP didn't.
Should i expect better throughput(Bytes/s) for TCP or UDP over a *Reliable* LAN and *Unreliable* WAN?. I will let you know what results i have achieved but i would like to know your perspective since thats more important. The tests are on my RHEL 3.0 box with the RH hacked 2.4.x kernel.
I will post the connect/send/recv code to those interested. The throughput calculation code is same for both the TCP and UDP programs hence the calculations i am sure about.
What do you think about it gurus???. Has anybody tried out SCTP???.
Trevor
|------|____________________________________|------| ( >- / Scaling FreeSoftware & OpenSource \ -< ) /~\ / In the Enterprise \ /~\ | ) \ | www.fsf.org | www.opensource.org | / (/ | |_|_ ____________________________________/ _|_|
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Should i expect better throughput(Bytes/s) for TCP or UDP over a *Reliable* LAN and *Unreliable* WAN?. I will let you know what results i have achieved but i would like to know your perspective since thats more important. The tests are on my RHEL 3.0 box with the RH hacked 2.4.x kernel.
As a rule of thumb UDP is better for reliable networks and TCP for unreliable ones. Generally LAN are reliable and WANs are unreliable(actually reliability depends on what your backbone is ).
Wanted to know how did you simulate WAN? applied rate-limiting or something?
Chiragz
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi,
On 24 Aug 2005, at 05:58, Trevor Warren wrote:
Morning Fellas,
Was working on some socket progs based on some performance test objectives we had in mind. The objective is to stress the TCPIP stack in the GnuLinux kernel and see the best numbers achiveable over the network.
Am in a bit of a quandry here. We always were taught that the overheads of a tcp session were higher than that of UDP considering the ACK's and FIN's sent across for every packet over the n/w, while TCP guaranteed delivery....blah..blah and UDP didn't.
ACK's aren't necessarily sent for every packet. TCP has the option to ACK a set of packets i.e if the sender ACKs packet with sequence number 4, the sender assumes that the receiver has also received packets 1,2 and 3. A FIN is only sent when the connection is to be closed.
Should i expect better throughput(Bytes/s) for TCP or UDP over a *Reliable* LAN and *Unreliable* WAN?. I will let you know what results i have achieved but i would like to know your perspective since thats more important. The tests are on my RHEL 3.0 box with the RH hacked 2.4.x kernel.
Well, on a reliable network you will probably see that you can send more data over UDP than TCP. UDP packets have lesser checks done on them so you need lesser CPU cycles to process UDP packets. The point to note is (and you probably know this) that the choice of transport shouldn't be based on the raw speed you can achieve but the requirements your application has.
cheers Chandru
Hello there,
--- Chandrashekhar Mullaparthi chandrashekhar.mullaparthi@t-mobile.co.uk wrote:
packets. The point to note is (and you probably know this) that the choice of transport shouldn't be based on the raw speed you can achieve but the requirements your application has.
[snip]
My requirements are very simple. I need to make use of a protocol that is low on cpu cycles and also offers reliability. TCP proves itself on the reliability front but is a high on cpu cycles.
While on the UDP front i have performed some basic tests. The raw througput in terms of bytes/s is almost to an order 1/2 that of TCP for the same message size, for the same no of clients over the same interval. As of now...i need to find the which among TCP-UDP offers the best throughput. Addressing Error handling at the application layer and larger CPU cycle consumption is the next step.
What do you think about this?. Am using simple sendto() and recvfrom() calls for UDP while the normal connect-send-recv calls on TCP.
Trevor
cheers Chandru
|------|____________________________________|------| ( >- / Scaling FreeSoftware & OpenSource \ -< ) /~\ / In the Enterprise \ /~\ | ) \ | www.fsf.org | www.opensource.org | / (/ | |_|_ ____________________________________/ _|_|
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hello there,
--- Chandrashekhar Mullaparthi chandrashekhar.mullaparthi@t-mobile.co.uk wrote:
packets. The point to note is (and you probably know this) that the choice of transport shouldn't be based on the raw speed you can achieve but the requirements your application has.
[snip]
My requirements are very simple. I need to make use of a protocol that is low on cpu cycles and also offers reliability. TCP proves itself on the reliability front but is a high on cpu cycles.
While on the UDP front i have performed some basic tests. The raw througput in terms of bytes/s is almost to an order 1/2 that of TCP for the same message size, for the same no of clients over the same interval. As of now...i need to find the which among TCP-UDP offers the best throughput. Addressing Error handling at the application layer and larger CPU cycle consumption is the next step.
What do you think about this?. Am using simple sendto() and recvfrom() calls for UDP while the normal connect-send-recv calls on TCP.
Trevor
cheers Chandru
|------|____________________________________|------| ( >- / Scaling FreeSoftware & OpenSource \ -< ) /~\ / In the Enterprise \ /~\ | ) \ | www.fsf.org | www.opensource.org | / (/ | |_|_ ____________________________________/ _|_|
____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
--- chirag radhakrishnan chiragrkn@yahoo.com wrote:
As a rule of thumb UDP is better for reliable networks and TCP for unreliable ones. Generally LAN are reliable and WANs are unreliable(actually reliability depends on what your backbone is ).
[snip]
Would just like to know as to whats the basis for your assumption that UDP is a better choice for reliable networks and if its a choice for such networks whats the benefits of doing so?.
Wanted to know how did you simulate WAN? applied rate-limiting or something?
[snip]
We have a large WAN across the globe Chirag. As of now am working on the LAN part of the tests.
Trevor
Chiragz
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- http://mm.ilug-bom.org.in/mailman/listinfo/linuxers
|------|____________________________________|------| ( >- / Scaling FreeSoftware & OpenSource \ -< ) /~\ / In the Enterprise \ /~\ | ) \ | www.fsf.org | www.opensource.org | / (/ | |_|_ ____________________________________/ _|_|
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 24 Aug 2005, at 15:04, Trevor Warren wrote:
--- Chandrashekhar Mullaparthi chandrashekhar.mullaparthi@t-mobile.co.uk wrote:
packets. The point to note is (and you probably know this) that the choice of transport shouldn't be based on the raw speed you can achieve but the requirements your application has.
[snip]
My requirements are very simple. I need to make use of a protocol that is low on cpu cycles and also offers reliability.
You mean like eat your cake and have it too :-) Like someone else pointed out, UDP is quite safe to use on LANs these days. We rarely ever see UDP packets being discarded on a LAN these days. But if you use UDP, you still need some application level protocol to make sure your messages get through.
TCP proves itself on the reliability front but is a high on cpu cycles.
Yes - but what kind of performance are you looking for? Have you prototyped your application using TCP and checked if the thoughput it offers is enough for you? If yes, it will save you the hassle of implementing an application level protocol for ensuring reliability. Remember this: premature optimisation is the root of all evil.
While on the UDP front i have performed some basic tests. The raw througput in terms of bytes/s is almost to an order 1/2 that of TCP for the same message size, for the same no of clients over the same interval. As of now...i need to find the which among TCP-UDP offers the best throughput. Addressing Error handling at the application layer and larger CPU cycle consumption is the next step.
What do you think about this?. Am using simple sendto() and recvfrom() calls for UDP while the normal connect-send-recv calls on TCP.
I have never really compared the throughput between these two transport protocols but I remember getting more throughput out of UDP by increasing the size of the buffers used for receiving messages.
Chandru
On Wednesday 24 August 2005 04:58, Trevor Warren wrote: *snip*
I will post the connect/send/recv code to those interested. The throughput calculation code is same for both the TCP and UDP programs hence the calculations i am sure about.
*snip*
I would love to see the code.
Morning Dear,
--- Chandrashekhar Mullaparthi > You mean like eat your cake and have it too :-) Like
someone else pointed out, UDP is quite safe to use on LANs these days. We rarely ever see UDP packets being discarded on a LAN these days. But if you use UDP, you still need some application level protocol to make sure your messages get through.
[snip]
I agree sir. The overhead of using Application layer functionality to ensure reliable delivery of UDP is something we will look at. But as of now the short term is to figure out that for a given n/w does tcp/udp give better throughput.
Yes - but what kind of performance are you looking for? Have you prototyped your application using TCP and checked if the thoughput it offers is enough for you? If yes, it will save you the hassle of implementing an application level protocol for ensuring reliability. Remember this: premature optimisation is the root of all evil.
[snip]
:D. I love the perspective. Yes and i understand that setting expectations right is very important. At this point before even deciding on which protocol i would like to make use of on my LAN(We will consider the WAN later) we need to perform some very basic tests and look at the Maximum Throughput as available via TCP-UDP sockets.
As of now for 100Bytes Messages i can do about 6L messages/s on a 100Mbit Lan while about 11L Messages/s on a 1000Mbit Lan. While UDP is about hald those numbers.
I have never really compared the throughput between these two transport protocols but I remember getting more throughput out of UDP by increasing the size of the buffers used for receiving messages.
[snip]
Thats a good tip sir. But increase of buffer size at the OS level you mean???. And these were for messages of what sizes and for how many simultaneous users. Its very important for me to figure out the Raw TCP V/s UDP throughput on my LAN-WAN before i make any other decisions.
Any pointers???.
Trevor
Chandru
|------|____________________________________|------| ( >- / Scaling FreeSoftware & OpenSource \ -< ) /~\ / In the Enterprise \ /~\ | ) \ | www.fsf.org | www.opensource.org | / (/ | |_|_ ____________________________________/ _|_|
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 24/08/05 07:04 -0700, Trevor Warren wrote: <snip>
My requirements are very simple. I need to make use of a protocol that is low on cpu cycles and also offers reliability. TCP proves itself on the reliability front but is a high on cpu cycles.
Those who do not understand TCP...
If you need reliability, use TCP. If you need performance, and can sacrifice reliability, use UDP. If you want both, buy more bandwidth, and sign a SLA with your provider for the reliability.
Devdas Bhagat
Morning Sir,
--- Devdas Bhagat devdas@dvb.homelinux.org wrote:
Those who do not understand TCP...
[snip]
Thanks Devdas for having enlightened us.
If you need reliability, use TCP. If you need performance, and can sacrifice reliability, use UDP. If you want both, buy more bandwidth, and sign a SLA with your provider for the reliability.
[snip]
Devdas, the issue is not about SLA's not about B/W and not about reliability atleast for now. We are discussing on getting the max throput thro either TCP-UDP. Post having achieved the same reliability-scalability-redundancy-performance-cpu consumption need to be looked into. We are in a phase where these protocols are being stressed on various OS stacks.
I assume you are smart enough to have gorged enough of TCP/IP through your career. You may not necessarily want to help but please understand the objective before you make such comments. Atleast i do feel you came across in an uncouth manner.
Have a great day Mr. Bhagat.
Trevor
Devdas Bhagat
|------|____________________________________|------| ( >- / Scaling FreeSoftware & OpenSource \ -< ) /~\ / In the Enterprise \ /~\ | ) \ | www.fsf.org | www.opensource.org | / (/ | |_|_ ____________________________________/ _|_|
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 24/08/05 23:44 -0700, Trevor Warren wrote:
Morning Sir,
--- Devdas Bhagat devdas@dvb.homelinux.org wrote:
Those who do not understand TCP...
[snip]
Thanks Devdas for having enlightened us.
If you need reliability, use TCP. If you need performance, and can sacrifice reliability, use UDP. If you want both, buy more bandwidth, and sign a SLA with your provider for the reliability.
[snip]
Devdas, the issue is not about SLA's not about B/W and not about reliability atleast for now. We are discussing on getting the max throput thro either TCP-UDP. Post having achieved the same reliability-scalability-redundancy-performance-cpu consumption need to be looked into. We are in a phase where these protocols are being stressed on various OS stacks.
If you need reliability and choose UDP because it is nominally faster, you will end up reimplementing TCP on top of UDP. Plenty of people have made this mistake, and you should learn from them. Reinventing the wheel is not a good thing in software, or in computer science.
I assume you are smart enough to have gorged enough of TCP/IP through your career. You may not necessarily want to help but please understand the objective before you make such comments. Atleast i do feel you came across in an uncouth manner.
I apologise if I appeared rude, there was no intention to be. The rules above are common protocol design rules, and should be followed.
Devdas Bhagat
--- Devdas Bhagat devdas@dvb.homelinux.org wrote:
I apologise if I appeared rude, there was no intention to be. The rules above are common protocol design rules, and should be followed.
[snip]
Devdas, do remember at times it would be worth building the reliability for UDP since research shows that the reliability of TCP on WAN's can cause deadlocks-delays-inefficiency.
To reach a decision on which protocol to make use of completely depends on the implementation one is looking for. Just taking the basic tenets of TCP-UDP and building from there is a sure disaster....atleast for the implementation we are looking at.
Not sure if i am making my point but my requirements cant be addressed by any off the shelf tcp-udp implementations. Hopefully once SCTP standardises i may look at it.
Take care and have a great day dear.
Trevor
Devdas Bhagat
|------|____________________________________|------| ( >- / Scaling FreeSoftware & OpenSource \ -< ) /~\ / In the Enterprise \ /~\ | ) \ | www.fsf.org | www.opensource.org | / (/ | |_|_ ____________________________________/ _|_|
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 25/08/05 01:22 -0700, Trevor Warren wrote:
--- Devdas Bhagat devdas@dvb.homelinux.org wrote:
I apologise if I appeared rude, there was no intention to be. The rules above are common protocol design rules, and should be followed.
[snip]
Devdas, do remember at times it would be worth building the reliability for UDP since research shows that the reliability of TCP on WAN's can cause deadlocks-delays-inefficiency.
And why would _your_ reliability implementation not face the same issues?
To reach a decision on which protocol to make use of completely depends on the implementation one is
Actually, it depends on the requirement. Implementation is a detail.
looking for. Just taking the basic tenets of TCP-UDP and building from there is a sure disaster....atleast for the implementation we are looking at.
There are tradeoffs to every decision. Feel free to reinvent the wheel :).
Devdas Bhagat
--- Devdas Bhagat devdas@dvb.homelinux.org wrote:
And why would _your_ reliability implementation not face the same issues?
[snip]
It will and who says not. After at times not thinking in the stereotype approach helps..:D
Actually, it depends on the requirement. Implementation is a detail.
[snip]
Whichever way you look at it. Your specs is what you will implement anyways.
There are tradeoffs to every decision. Feel free to reinvent the wheel :).
[snip]
Thanks devdas.
Trevor
Devdas Bhagat
|------|____________________________________|------| ( >- / Scaling FreeSoftware & OpenSource \ -< ) /~\ / In the Enterprise \ /~\ | ) \ | www.fsf.org | www.opensource.org | / (/ | |_|_ ____________________________________/ _|_|
____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Hi Trevor,
Welcome back from hibernation!
On Fri, 2005-08-26 at 09:34, Trevor Warren wrote:
It will and who says not. After at times not thinking in the stereotype approach helps..:D
True... How about just forgetting TCP-UDP altogether and directly building on top of just IP?
Kind of hybrid approach where you look at the strengths and weaknesses of both TCP and UDP and develop something called TTP (Trevor Transport Protocol!).
What say dude. :-) Enjoy!
Afternoon Dear,
--- Dinesh Shah Dinesh@ShahMicro.com wrote:
Kind of hybrid approach where you look at the strengths and weaknesses of both TCP and UDP and develop something called TTP (Trevor Transport Protocol!).
[snip]
Dinesh dear,
As of now we are only progressing on the path towards evaluation of the off the shelf protocols. At this juncture i am sure i aint smart enough to design me own protocols. Just aiding teams here come up with specs for the same!!!.
Trevor
What say dude. :-) Enjoy! -- --Dinesh Shah :-)
|------|____________________________________|------| ( >- / Scaling FreeSoftware & OpenSource \ -< ) /~\ / In the Enterprise \ /~\ | ) \ | www.fsf.org | www.opensource.org | / (/ | |_|_ ____________________________________/ _|_|
____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
On 25 Aug 2005, at 05:16, Trevor Warren wrote:
I have never really compared the throughput between these two transport protocols but I remember getting more throughput out of UDP by increasing the size of the buffers used for receiving messages.
[snip]
Thats a good tip sir. But increase of buffer size at the OS level you mean???. And these were for messages of what sizes and for how many simultaneous users. Its very important for me to figure out the Raw TCP V/s UDP throughput on my LAN-WAN before i make any other decisions.
Any pointers???.
I mean, specify the buffer size when you create your UDP socket. We implemented a RADIUS (uses UDP) server and when we increased the buffer size to about 64K, we were able to receive and process 900 RADIUS packets a second. Ofcourse if you are just testing to see how fast you can send/receive, you will be able to get much more. And my implementation wasn't in C either as speed wasn't the most important factor - reliability was. I sed erlang - http://www.erlang.org
cheers Chandru
-
Chandrashekhar Mullaparthi -
chirag radhakrishnan -
Devdas Bhagat -
Dinesh Joshi -
Dinesh Shah -
Trevor Warren