Efficient methods

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

Reply to
karthikbalaguru
Loading thread data ...

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).

--=20

Regards, Richard.

  • formatting link
    Designed for Microcontrollers. More than 7000 downloads per month.

  • formatting link
    Certified by T=DCV as meeting the requirements for safety related systems= =2E

Reply to
FreeRTOS info

.

I use a satellite link for sending loads of messages, each one about

10 bytes long. In normal speed this is 1 BYTE per second and in high speed mode it transfers the message at 4 bytes per second.

Perhaps answers to the OP could use these values as real world examples.

Ian

Reply to
Ian

The most efficient way to send data is a 747 cargo plane full of DVD ROMS.

Reply to
Jim Stewart

There was a story about a data file being sent by memory stick (encrypted) attached to the leg of a carrier pigeon. The entire file made it to the receivers end by this means before 30% of the same data file had been transmitted over the internet connections. I gather that the file was some

4Gbytes.
--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

It was done in South Africa as a stunt to publicize the slow ADSL service provided by Telkom:

formatting link

The pigeon transported 4GB of data 60 miles between two datacenters in 1 hour 8 minutes. The transfer ADSL was 4% complete 4% in the same amount of time.

Protocols requiring more interaction don't fare so well when using a Pigeon as a physical layer:

formatting link

--
Grant Edwards                   grante             Yow! I threw up on my
                                  at               window!
 Click to see the full signature
Reply to
Grant Edwards

Allow me to contend that nowadays it would be SDHC cards (somewhere in the region of 32GB per gram) over trains.

A quick google calculator with some assumptions (100 km distance, 50 metric tons effective load / train car, 100Km/h average train speed) gives the bandwidth as

(32 gigabytes * 1000 * 1000 * 50) / 1 hour = 434 Terabyte / s.

//Oscar

Reply to
Oscar Almer

=2E..but how long would it take you to copy the data onto the cards then off the cards again at the other end? Or am I taking this too seriously = :o)

--=20

Regards, Richard.

  • formatting link
    Designed for Microcontrollers. More than 7000 downloads per month.

  • formatting link
    Certified by T=DCV as meeting the requirements for safety related systems= =2E

Reply to
FreeRTOS info

The problem with trains is you can't easily handle the redundancy required to ensure *reliable* delivery. Sure, you can send three different trains with different encodings of the data... but, for most places, there is only one track in or out. So, a wreck of "your" train *on* that track not only results in a loss of the data but, also, the means for getting *other* data to the destination.

With planes, this is less of a problem owing to the nature of "plane failures" being self-clearing events -- they intrinsically "fall" out of the way of other planes which might be behind them!

Reply to
D Yuniskis

Depends, d'you have something that'll dread them in parallel? I was actually looking for a wee something (of the integrated variety) that could talk to several of them at once a short while ago, and came up emptyhanded.

Even so, shouldn't be too hard to gang up a pile of (insert bus type here) readers in parallel though, if you already have something to transfer 1.5 exabytes of data _to_.

A physical implementation and speed measurements is left as an exercise for the hobbyists.

//Oscar

(good typomonster!)

Reply to
Oscar Almer

:-) Nice imagination :-) !!

Karthik Balaguru

Reply to
karthikbalaguru

Interesting :-) :-)

Good links ! :-)

Karthik Balaguru

Reply to
karthikbalaguru

A bit more: Change the DVD's to 1 TByte disks.

(Just my EUR 0.02).

--

Tauno Voipio
Reply to
Tauno Voipio

Interestingly QoS RFC is also present for it in the form of RFC 2549 ! Weighted fair queueing & plot of traffic shaping topics appear interesting :-)

Karthik Balaguru

Reply to
karthikbalaguru

Many messages are around

700 bytes and few are around 1200 bytes. The speed would be around 80 Mbit/s.

Thx in advans, Karthik Balaguru

Reply to
karthikbalaguru

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

Reply to
karthikbalaguru

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

Reply to
karthikbalaguru

Op Sat, 30 Jan 2010 14:55:18 +0100 schreef karthikbalaguru :

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/
 Click to see the full signature
Reply to
Boudewijn Dijkstra

g

=A0

=A0

=A0

t =A0

very =A0

ll =A0

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

Reply to
karthikbalaguru

Op Mon, 08 Feb 2010 19:16:15 +0100 schreef karthikbalaguru :

None, hopefully.

70 [µs] = 700 [bytes] / 80 [Mbit/s]
--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
 Click to see the full signature
Reply to
Boudewijn Dijkstra

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.