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).
--=20
Regards, Richard.
.
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
The most efficient way to send data is a 747 cargo plane full of DVD ROMS.
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.
It was done in South Africa as a stunt to publicize the slow ADSL service provided by Telkom:
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:
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
=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.
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.
//Oscar
(good typomonster!)
:-) Nice imagination :-) !!
Karthik Balaguru
Interesting :-) :-)
Good links ! :-)
Karthik Balaguru
A bit more: Change the DVD's to 1 TByte disks.
(Just my EUR 0.02).
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
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
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
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
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.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
Op Mon, 08 Feb 2010 19:16:15 +0100 schreef karthikbalaguru :
None, hopefully.
70 [µs] = 700 [bytes] / 80 [Mbit/s]Have something to add? Share your thoughts — no account required.
Ask the community — no account required