Efficient methods
in [Embedded]
|
From: karthikbalaguru on 30 Jan 2010 08:55 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 ? Thx in advans, Karthik Balaguru
From: karthikbalaguru on 30 Jan 2010 08:57 On Jan 30, 6:55 pm, karthikbalaguru <karthikbalagur...(a)gmail.com> wrote: > 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 ? > To be more clear - That is, single thread will be created for every message that arrives in. That thread will process that particular message and will get killed. But is this method better than the message queue based method ? Any thoughts ? Thx in advans, Karthik Balaguru
From: Boudewijn Dijkstra on 30 Jan 2010 11:12 Op Sat, 30 Jan 2010 14:55:18 +0100 schreef karthikbalaguru <karthikbalaguru79(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. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (remove the obvious prefix to reply by mail)
From: karthikbalaguru on 8 Feb 2010 13:16 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 . 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 ? Just eager to know that. Can you provide with the info of Processor, OS and kernel version based on which 70 microseconds threshold has been achieved ? Thx in advans, Karthik Balaguru
From: Boudewijn Dijkstra on 9 Feb 2010 03:30
Op Mon, 08 Feb 2010 19:16:15 +0100 schreef karthikbalaguru <karthikbalaguru79(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] -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (remove the obvious prefix to reply by mail) |