Efficient methods
in [Embedded]
|
From: karthikbalaguru on 20 Feb 2010 08:10 On Feb 9, 1:30 pm, "Boudewijn Dijkstra" <sp4mtr4p.boudew...(a)indes.com> wrote: > Op Mon, 08 Feb 2010 19:16:15 +0100 schreef karthikbalaguru > <karthikbalagur...(a)gmail.com>: > > > > > > > On Jan 30, 9:12 pm, "Boudewijn Dijkstra" > > <sp4mtr4p.boudew...(a)indes.com> wrote: > >> Op Sat, 30 Jan 2010 14:55:18 +0100 schreef karthikbalaguru > >> <karthikbalagur...(a)gmail.com>: > >> > On Jan 29, 8:35 pm, karthikbalaguru <karthikbalagur...(a)gmail.com> > >> > wrote: > >> >> On Jan 26, 2:11 pm, FreeRTOS info <noem...(a)given.com> wrote: > >> >> > karthikbalaguru wrote: > >> >> > > Hi, > > >> >> > > Need to know some efficient > >> >> > > methods for reception, > >> >> > > processing and transmission > >> >> > > of the high speed messages. > > >> >> > > Should i need to go in for > >> >> > > a method of having a > >> >> > > transmitter thread, queue > >> >> > > and receiver thread concept ? > > >> >> > > Are there alternative efficient > >> >> > > methods for processing of > >> >> > > High Speed Messages ? > > >> >> > > Thx in advans, > >> >> > > Karthik Balaguru > > >> >> > That would depend on a lot of things, details of which you > >> helpfully > >> >> > avoid giving in your post (like what "high speed" means, and how > >> long > >> >> > the messages are). > > >> >> Many messages are around > >> >> 700 bytes and few are around > >> >> 1200 bytes. The speed would > >> >> be around 80 Mbit/s. > > >> > I understand that this depends > >> > on lot of factors. But in general, > >> > Is the method of creation of thread > >> > for every message to be processed > >> > better than the message queue based > >> > method ? Any ideas ? > > >> Creating and killing threads in rapid succession is often regarded as > >> expensive. Web servers, for example usually need a thread for every > >> socket. Many performance-optimized (non-embedded) web servers employ a > >> pool of worker threads that slowly grows or shrinks depending on > >> average load. This has the advantage that a thread can be allocated to > >> a socket almost immediately but the disadvantage that some threads will > >> be idle. > > >> From my experience I would say that creating and destroying a thread > >> every 70 microseconds is probably a bad idea. In a single-core system, > >> it will be more efficient to process the messages sequentially anyway. > > > I too think that the method of creation and destruction of thread > > in rapid phase not only increases the amount of resource consumed, > > thereby reducing the processing capability of the processor. > > I think, it may also heat up the processor ! > > > Which OS is good for the design of creating & destruction of > > threadds for every message that arrives at high speeed . > > None, hopefully. > > > Many messages are around 700 bytes and few are around > > 1200 bytes. The speed would be around 80 Mbit/s. > > > I have been thinking about this ! > > I wonder, How you were able to arrive at the value of 70 > > microseconds ? > > 70 [µs] = 700 [bytes] / 80 [Mbit/s] > Okay :-) While reading about the various designs, interestingly i came across an info that the design of TCP servers is mostly such that whenever it accepts a connection, a new process is invoked to handle it . But, it seems that in the case of UDP servers design, there is only a single process that handles all client requests. Why such a difference in design of TCP and UDP servers ? How is TCP server able to handle large number of very rapid near-simultaneous connections ? Any ideas ? Thx in advans, Karthik Balaguru
From: Paul Keinanen on 20 Feb 2010 09:12 On Sat, 20 Feb 2010 05:10:54 -0800 (PST), karthikbalaguru <karthikbalaguru79(a)gmail.com> wrote: >While reading about the various designs, interestingly i >came across an info that the design of TCP servers is >mostly such that whenever it accepts a connection, >a new process is invoked to handle it . >But, it seems that in the case of UDP servers design, >there is only a single process that handles all client >requests. Why such a difference in design of TCP and >UDP servers ? How is TCP server able to handle >large number of very rapid near-simultaneous connections ? >Any ideas ? While I understand that some lazy programmers might use TCP/IP for some minor ad hoc applications. I still do not understand why anybody would use TCP/IP for any critical 24x7 applications.
From: Mark Hobley on 20 Feb 2010 10:08 karthikbalaguru <karthikbalaguru79(a)gmail.com> wrote: > While reading about the various designs, interestingly i > came across an info that the design of TCP servers is > mostly such that whenever it accepts a connection, > a new process is invoked to handle it . TCP is a "reliable" connection, whereas UDP is "unreliable". If you understand the difference between these two types of connections, it should be clear why this is so, and you would know which connection type best suits your application. I would go down to the book store, and look for a load of books with "TCP/IP" in the title, then sit and read a couple of chapters to decide which one to buy. > How is TCP server able to handle large number of very rapid > near-simultaneous connections ? The datagrams carry identification numbers that enable them to be related to the controlling processes, enabling them to be easily managed. You could implement a large number of "connections" over UDP too, if you so wished to do so. Mark. -- Mark Hobley Linux User: #370818 http://markhobley.yi.org/
From: Jorgen Grahn on 20 Feb 2010 10:56 ["Followup-To:" header set to comp.protocols.tcp-ip.] On Sat, 2010-02-20, karthikbalaguru wrote: > On Feb 9, 1:30�pm, "Boudewijn Dijkstra" <sp4mtr4p.boudew...(a)indes.com> > wrote: [long discussion held elsewhere than in comp.protocols.tcp-ip] >> >> 70 [�s] = 700 [bytes] / 80 [Mbit/s] >> > > Okay :-) > > While reading about the various designs, interestingly i > came across an info that the design of TCP servers is > mostly such that whenever it accepts a connection .... Ugh. Please don't crosspost that widely, and especially don't include additional groups in mid-thread without saying so in your posting. It makes me reluctant to answer your question, because I don't know if the comp.arch.embedded and comp.os.linux.networking crowds want to hear me, or if they'd rather not see the rest of the thread. I don't know what's on topic there, because I don't read those groups. See the problem? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
From: karthikbalaguru on 20 Feb 2010 11:15
On Feb 20, 8:08 pm, markhob...(a)hotpop.donottypethisbit.com (Mark Hobley) wrote: > karthikbalaguru <karthikbalagur...(a)gmail.com> wrote: > > While reading about the various designs, interestingly i > > came across an info that the design of TCP servers is > > mostly such that whenever it accepts a connection, > > a new process is invoked to handle it . > > TCP is a "reliable" connection, whereas UDP is "unreliable". If you understand > the difference between these two types of connections, it should be clear why > this is so, and you would know which connection type best suits your > application. > Agreed, but the query is about the design of the TCP server and the UDP server. In TCP server whenever a new connection arrives, it accepts the connection and invokes a new process to handle the new connection request. The main point here is that 'a new process is created to handle every new connection that arrives at the server' . In the case of UDP server, it seems that most of the the server design is such that there is only one process to handle various clients. Will the TCP server get overloaded if it creates a new process for every new connection ? How is it being managed ? > > > How is TCP server able to handle large number of very rapid > > near-simultaneous connections ? > > The datagrams carry identification numbers that enable them to be related > to the controlling processes, enabling them to be easily managed. > The point here is, consider a scenario that there are multiple connection requests are arriving while the TCP server is busy in the process of creation of a new process for the earlier connection request. How does TCP handle those multiple connection requests during that scenario ? > You could implement a large number of "connections" over UDP too, if you so > wished to do so. > Thx in advans, Karthik Balaguru |