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
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...............
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!
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
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!
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.
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 ?
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/
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
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.