| 
	
 | 
 Posted by William Gill on 09/28/07 18:42 
cwdjrxyz wrote: 
 
>  
> I get up to a  maximum number of GB of bandwidth per month. If that is 
> exceeded, I will get charged for the excess bandwidth at the end of 
> the month. ... 
 
Bandwidth is an old analog term.  In general it refers to how much  
spectrum is used/available, and thus the capacity.  The term did not  
port well to the digital world, because its use introduced too much  
ambiguity.  i.e. 1000 Khz means 1,000,000 full cycles every second.  
Seconds are the agreed to standard interval or period.  You won't see  
cycles per week, cycles per hour, or anything else.  When a hosting  
service uses "bandwidth" to mean how many gigabits per month, he/she may  
be using a "pipe" that only works at 45 megabits per second to connect  
to the internet at large.  That "pipe" is shared by all his/her  
customers.  When he/she tries to feed more bits than that, the excess is  
queued or dropped. 
 
> ... They download part of the data at a time, The time between 
> download "spurts" becomes longer and longer as more and more people 
> are using the server. 
 
Well... Sometimes the "spurts" are the result of requests being queued  
or the bursty "packet" nature of TCP/IP ("data" is broken up; put into  
packets numbered; sent; received; resequenced if necessary; and  
reassembled). 
 
> ... This situation will not do for a busy streaming media 
> site, such as a web radio or TV station. A certain minimum download 
> rate is required to keep the media streaming. Thus a special media 
> server often is set up to limit the number of people viewing it at one 
> time. When that limit is exceeded, no one else can get on until some 
> people sign out. Typically when too busy, you get a message that the 
> service is too busy to use. 
>  
 
The media is always streaming.  The question is; is it streaming  
efficiently enough. 
 
To prevent the interval between packets in any source/destination stream  
from being intolerable to a specific "service", it is necessary to have  
faster "pipes", faster "pumps" (servers), and/or fewer recipients.  Also  
keep in mind that the "last mile" (the part between the net and the  
recipient) is probably the biggest choke point (the slowest).  In the  
old telephone world echo was not a problem on shorter connections,  
because even if the echo was "relatively loud", it was happening almost  
in sync with what it was echoing, so the brain didn't notice.  On longer  
calls the delay made the echo separate itself in time from the original  
  (delay).  We couldn't fix the time delay, but we could suppress the  
volume of the echo in an effort to keep the brain happy.  A  
non-technical example is a Casino.  The dealer(server) can only deal  
cards (packets) so fast, the table can only be so small (faster  
delivery), but some players won't be happy if they are losing their  
money too slowly.  So we limit the number of seats at the table (limit  
the delay between cards/packets) so that the dealer can get that unhappy  
player his/her next card faster. 
 
<disclaimer> all of this may not hold up to intense technical scrutiny,  
but it's close enough for government work. Anyway, I think it's way  
beyond the scope of this group</disclaimer>
 
[Back to original message] 
 |