Hello All,
There were some queries about the idea which I hope to answer.
The system of high speed serial data dumping that I wrote about will not replace the existing internet. It will only provide an extra ultra high speed channel for downloading heavy files for each one and everyone without the bother of bandwidth sharing and at a very affordable price. As a rule or plan, all files above 5 or 10 Mb can be considered eligible for this system. Entire web sites can be downloaded as a single arcihve file. The ones lower than that, can be downloaded using the normal internet. All peer-peer, VPN, chat, email, online registration, payments, shopping etc. will be done using *regular internet only*.
This high speed channel will not only be usefull as an infotainment channel for music, news and video but also for normal software and other heavy file downloads.
Suppose you need to download 4 CDs of Linux, totalling 4 x 700 Mb = 2800 Mb or 2.8 Gb in your home. Even at a speed of 512 Kbits per second, your speed in bytes will be 512 / 8 = 64 Kbytes per second. So 2800 Mb will take (2,800,000 Kb / 64) seconds = 43750 seconds. This translates to more than 12 Hours. So it takes approx. 3 hours per CD to download even at 512 Kbps which everyone still cannot afford yet or their locality does not have this facility. You also got to treat your cablewala as God.
Instead of that, in the system suggested, the waiting time would be max. half an hour or one hour but 4 CDs would be downloaded in less than 3 seconds. Imagine the time saved for people who need to download CDs regularly and in large numbers. A single DVD of 4.3 Gb would be downloaded in 4.3 seconds. On the regular 512 Kbps it would take 18.66 Hours. All you would need to do is mark all the files to be downloaded from a pilot list and within their rotation cycle of half or one hour, they would all be dowloaded one by one and be ready in your hard disk in one cycle itself. The maximum you can download within this rotation cycle will only be limitted to the maximum capacity of your hdd. The same data would take days or weeks to download under normal net circumstances. 120 Gb takes more than 21 full days to download at 512 Kbps. In this case, half or one hour. Take your pick.
Frankly I don't know what is latency in a satellite but if Philip could elaborate more and provide points on why it has a problem in sat transmission, it would help a lot in making improvements to this system. Since the repeat cycle of data broadcast is every hour or half, problems due to bad weather or earth's rotation will be temporary. Any modifications and suggestions are welcome too.
The example I gave is for a 1 Gbytes per second speed having a capacity of 86.4 Terabytes per rotation cycle of half or one hour. This should suffice for all the heavy files that currently exist everywhere on the internet. If it is technologically possible, we can use much higher speeds like 2 to 5 GBytes per second and that will pack in multiples of 86.4 Terrabytes per cycle or reduce the cycle time for the same amount of data.
Regards,
Rony.
Sometime Today, Rony Bill assembled some asciibets to say:
This high speed channel will not only be usefull as an infotainment channel for music, news and video but also for normal software and other heavy file downloads.
So, again, how is it different from television, which we already have?
Frankly I don't know what is latency in a satellite but if Philip could elaborate more and provide points on why it has a problem in sat transmission, it would help a lot in making improvements to this system.
geostationary satellites are at an altitude of 36000Km. Speed of light is 300000Km/s. That's approx. 200 ms round trip time to send a packet via a satellite.
Given this base delay, you need to have a large window for tcp acknowledgements to be sent. That means that a transmission error could go unnoticed for a much longer period of time.
I may be wrong, so someone correct me.
On Wed, 8 Sep 2004 17:18:17 +0530 (IST), Philip Tellis philip.tellis@gmx.net wrote:
Sometime Today, Rony Bill assembled some asciibets to say:
Frankly I don't know what is latency in a satellite but if Philip could elaborate more and provide points on why it has a problem in sat transmission, it would help a lot in making improvements to this system.
geostationary satellites are at an altitude of 36000Km. Speed of light is 300000Km/s. That's approx. 200 ms round trip time to send a packet via a satellite.
Given this base delay, you need to have a large window for tcp acknowledgements to be sent. That means that a transmission error could go unnoticed for a much longer period of time.
I may be wrong, so someone correct me.
Yes you are right. High delay and high bandwidth networks such as satellite networks need some changes(patches or using sysctl) in the TCP/IP stack of the host operating system. This has been there in FreeBSD since version 4.4. This has also been described in the book "TCP/IP Illustrated volume 2" by the venerable Richard Stevens. Just look up the index for "long fat pipe". a quick look at the sources also reveals that Linux also has this support. You might have to turn on window scaling using proc fs. echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
Window scaling means a 32 bit field is used in the TCP header for window size instead of the usual 16-bit field.
You may also have to change tcp send and receive buffer sizes using the following variables. /proc/sys/net/core/wmem_max /proc/sys/net/core/rmem_max /proc/sys/net/ipv4/tcp_rmem /proc/sys/net/ipv4/tcp_wmem
Also some other safeguards such as PAWS (Protection against wrapped sequence numbers) also have to be in the kernel. Long fat pipe support is described in RFC 1323. http://www.faqs.org/rfcs/rfc1323.html
--> Vinayak Hegde
----- Original Message ----- From: "Philip Tellis" philip.tellis@gmx.net
So, again, how is it different from television, which we already have?
Television is dedicated only to live information and entertainment through video and audio signals. The system suggested will not be limitted to audio and video but any file under any category, subject to it being large in size to justify its high speed broadcast.
geostationary satellites are at an altitude of 36000Km. Speed of light is 300000Km/s. That's approx. 200 ms round trip time to send a packet via a satellite.
Given this base delay, you need to have a large window for tcp acknowledgements to be sent. That means that a transmission error could go unnoticed for a much longer period of time.
The system suggested is a one way broadcast system and will be different from existing 2 way tcp one on the internet. If the new system does not exist, it will have to be created by the techies. That is why I made this idea open to anyone who wants to implement it as and how they want to. It will be very much similar to receiving a television broadcast but will differ in speed, content and file mapping. This mapping will look just like a web page, however the links will not point to server locations but the corresponding transponder, its time of broadcast for that particular file and the actual file identity in the satellite's data base.
There is one major problem that I did not think of before and has gone unnoticed here. Since there are multiple transponders transmitting different files at the same time to reduce cycle time, if the user wants to download files located on different ransponders and if their times clash with each other, then he has to wait for an entire cycle to complete before downloading the next file. A simple work around for this is to group files in transponders according to their categories so that similar category of files exist in each transponder (txpd) and it is less likely that when a user is downloading files of one category, he may jump to another one at the same time. A better but costly solution is to have only one file transmitted by all txpds at the same time. The file will be split into parts equal to the number of txpds. It will be assembled at the receiving end. This will however require a more expensive receiver. The lnb unit will have to be a collection of equal number of lnbs in the same dish, that simultaneously receive the signals from all txpds and these signals are assembled in the receiver before passing it on to the computer. This will require rf circuits equal to the number of lnbs. With integrated circuits made for such a purpose, this should not be a major hassle in size and mass production. One txpd channel can be reserved for sync signals to ensure accurate decoding of the received signals.
Any thoughts on that?
Rony.
--- Rony Bill ronbilly@hotpop.com wrote: <a whole lotta things>
a> Satellite bandwidth is expensive and slow and satellites themselves have a short life - making them a financially unviable option. b> All BIG internet pipes are implemented using submarine cables which are long life. c> If you have a scheduled download system, you will a humungous amount of transponders to pump all the crazy number of files that people all over the world are interested in. d> as an Aside - television is not just 'live' feeds - its simply digital information...which incidentally we use a TV to decode as audio/video..
kishor
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
-
kishor bhagwat -
Philip Tellis -
Rony Bill -
Vinayak Hegde