Impact of ISP data caps on feed providers

[MTS2000des]

As someone who ran a feed on the old Scan America (and later Radio Reference) sites, I can say as a feed provider this would concern me.

Almost all WIRELINE (DSL and cable) now are implementing data bandwidth caps on their service, for both upload and download data used each monthly period. AT&T now limits DSL users to 150GB per month, and U-Verse to 250GB per month. Additional charges apply if a person exceeds those allotments on a regular basis.

the problem is the way streaming works, data is constantly being sent out REGARDLESS of whether any audio is present. It works out to several GB a month uploaded, more if you run multiple feeds on a single internet connection. While this alone may not seem much, combined with regular family internet usage (Netflix streaming, YouTube, etc) it is easy for a streamer to push over that limit in a month, and thus incur additional charges.

Does RadioReference plan to implement a new streaming method that uses less data or compensate feed providers for overages that are incurred as a result of these high amounts of data on part of the streaming? Keeping in mind that RadioReference makes a profit of the feeds voluntarily provided, I don't think this would be out of line.

I'm not trying to start a flame war. It's a real issue that many feed providers will soon face as a result of ISP's such as AT&T now essentially going to metered rates like the majority of the wireless companies have done.

There has to be a better method of "on demand" streaming encoding that will slash data use on part of feed providers so they don't get rammed with these overage situations. Have any of you feed providers been hit with overage or warning letters from your ISP? I'm specifically looking for AT&T DSL users since this policy went into effect this April.

 

[rdale]

The stream is a VERY low bandwidth system already. It won't push anyone near any data limits that refer to "GB"!

 

[jackj]

You have a legitimate concern, MST2000des. Those ISPs that are throttling back speed after a certain data limit or charging more to heavy users are cheating their customers. Instead of investing in increasing their bandwidth to the Internet they are taking away what their customers have already paid for. They reduce their costs by not providing what they sell but when was the last time your bill from your ISP went down?

There are only two options open for us to use, change providers or complain to your congress critter. Unfortunately neither option will fix the problem. The criminals in congress don't care about you or your country, witness the budget mess. And if all of the providers go to the same data plans, who do you switch to?

 

[Confuzzled]

the problem is the way streaming works, data is constantly being sent out REGARDLESS of whether any audio is present. It works out to several GB a month uploaded, more if you run multiple feeds on a single internet connection. While this alone may not seem much, combined with regular family internet usage (Netflix streaming, YouTube, etc) it is easy for a streamer to push over that limit in a month, and thus incur additional charges.

So it wouldn't be the multiple GBs of videos and other recreational use that would put you over, it would be the few hundred MBs of audio?

Does RadioReference plan to implement a new streaming method that uses less data or compensate feed providers for overages that are incurred as a result of these high amounts of data on part of the streaming? Keeping in mind that RadioReference makes a profit of the feeds voluntarily provided, I don't think this would be out of line.

You want RR to PAY you for a feed? And then incur the costs of sending out 1099s every year? :roll:

 

[Confuzzled]

Those ISPs that are throttling back speed after a certain data limit or charging more to heavy users are cheating their customers.

I wouldn't say that. There are users who abuse the system with traffic out of proportion related to the typical user. Those people should pay more, but the question is -- what is a reasonable threshold? 150Gb is too low and 250Gb is probably too low also. Maybe 500Gb/mo?

People that drive more miles using more fuel pay more per month, don't they?

or complain to your congress critter.

The criminals in congress don't care about you or your country, witness the budget mess.

The FCC needs some teeth in this matter. They COULD deal with the situation if the special interest groups couldn't buy influence.

 

[jackj]

Confused, why should I (or anyone else) conform to what our ISP considers the "Typical User"? Currently I have unlimited, 6 mb DSL service. Are you saying that I shouldn't watch video on-line because it is data intensive? That's why I'm paying for 6 mb service, if all I can do is send and receive e-mail and read the Drudge report then why should I pay a premium for high speed DSL?

Your comparison to high mileage drivers doesn't hold up. A more accurate comparison would be auto finance payments. If you are a high mileage driver, why should your car payments go up.

 

[MTS2000des]

So it wouldn't be the multiple GBs of videos and other recreational use that would put you over, it would be the few hundred MBs of audio?



You want RR to PAY you for a feed? And then incur the costs of sending out 1099s every year? :roll:

You're missing the point. Many feed providers are now (by no choice of their own) subject to a change in their ISP's terms of service which implement a cap on their combined upload and download use every month.

The bottom line is running a feed, in it's current iteration, places a continuous data use, which actually works out to several GB a month of upstream data (depending on bitrate of encoding selected) per feed provided. There is a now a measurable cost of service on the feed providers' end to this since their service is no longer unlimited.

If you stay at my house and my utilities go up, you don't think you should compensate for the cost going up? This situation is no different. RR benefits from the feeds monetarily, the benefit of getting a premium membership may no longer offset the cost. And I was just talking bandwidth, not counting the cost of electricity (a computer must be kept powered up and out of sleep state, ranges from $85-$200 per year, according to the US DOE, if it's left on 24/7, assuming a 250-300 watt power supply desktop).

You staying at my house impacts my bills, and RR use of another persons' internet and electrical service can affect theirs, now a little more, because of the ISP's change in policy. The way feeds are encoded could be changed to an on-demand model, no one listens, nothing encoded. No audio is sent, nothing encoded. This would save a tremendous amount of utilized bandwidth.

All I am saying, it costs real money to provide a feed. And if it becomes too expensive, those who do so may cease to do so.

 

[rdale]

If no one is listening to your feed - why are you doing it?

 

[burner50]

Does RadioReference plan to implement a new streaming method that uses less data or compensate feed providers for overages that are incurred as a result of these high amounts of data on part of the streaming? Keeping in mind that RadioReference makes a profit of the feeds voluntarily provided, I don't think this would be out of line.

Radioreference.com feed providers get a free premium membership as long as their feed is online.

 

[brandon]

The easiest solution to the problem is switch Internet providers if your ISP starts issuing bandwidth caps. I don't understand why so many people put up with this nonsense. Same goes for mobile phone carriers in this country.

 

[OCO]

I know it's a little late in the discussion to ask this, but has it been confirmed with the developers of the streaming software that even when there is no audio from the scanner, that the program continues to send a string of some kind of null character? The actual transmitted data is broken into packets, sent across the network and reassembled anyway (with buffering to allow for out of sequence packets) and with the fact that this is not realtime playback (there's already a delay including buffering of around 30 seconds on some of the feeds I've checked) it would be feasible to actually open and close sessions that timed out after a set period of time.

I am not advocating that RR should do this as it would require extensive rewriting of all the apps involved, but it sure is too bad that streaming standards that were written for use on high capacity local area networks become the defacto standard for use on wide area networks where bandwidth, availability and other issues come into play (definitely long before RR, ScanAmerica or any of the current streaming services came about!). In my previous life it was a daily issue. :roll:

Brandon: You must be in an area where there are multiple providers.... There's no choice in many areas.

 

[talkpair]

The biggest obstacle I see in implementing a different protocol is the detection of silence.

Software solutions might work, but some sort of physical connection to a busy light, PL detect, or carrier detect would probably work better.

Given the wide variety of radios, varying technical skills of feed providers, and availability of the equipment to test, the current icecast protocol is probably best for this point in time.

 

[zl2taw]

I am on a 60GB limit here, but thats only counted towards downloads, and all my uploads are free
FYI, I would average about a 1gig a day in uploads, (thats a total of everything here)

Not bad, with a wife & 2 kids hammering away at the net

 

[MTS2000des]

Radioreference.com feed providers get a free premium membership as long as their feed is online.

Yes, but this is of little value, considering that the costs to provide said feed are material, and RR.com generates revenue from the feeds they are essentially getting for free from volunteers. A free premium subscription doesn't pay the light bill RR uses, nor the now metered gigabytes of internet use RR uses to provide feeds to others for a profit.

 

[MTS2000des]

The easiest solution to the problem is switch Internet providers if your ISP starts issuing bandwidth caps. I don't understand why so many people put up with this nonsense. Same goes for mobile phone carriers in this country.

What choices are those? Broadband internet are only available from a handful of providers. Cable companies have been instituting data caps for quite some time, with some (Comcast) even going so far as to BAN CUSTOMERS for excessive LEGAL use...and now AT&T has caps on their DSL users.

Wireless providers all cap or throttle bandwidth, even Sprint does despite their "unlimited" motto.

That's the playing field most of us have to contend with. I am glad you don't have to. But for how long?

 

[rdale]

Yes, but this is of little value, considering that the costs to provide said feed are material

It costs me exactly $0.00 (+/- 0) to provide a feed to RR. The premium membership is all the value I need...

 

[bezking]

Folks, the data caps that are imposed by the major ISPs are extremely high - we are talking a few hundred GBs (Comcast's is 250GB) every month. It would take an incredible amount of usage to come anywhere close to hitting the cap - we are talking about streaming something like 50 DVDs or excessive, nonstop use of torrent or fileshare clients. Most average customers will never see themselves even come close to moving that kind of volume of data on a monthly basis.

All in all, the data use incurred by streaming to RR is really just a drop in the bucket of bandwidth that your ISPs are providing yo.

 

[kendrik578]

Your always welcome to feed on your own server. No one said you have to feed to RR.

Volunteers feed as part of the hobby and the joy of providing their feed so everyone else can listen.

I really don't see what the fuss is all about. How is 5gb (running 24/7) a month going to put you in the hole?

 

[OCO]

bezking and kendrik578:
I joined in on more of a interest in the statement that the monthly data usage for a feed would be based on (encoding rate)x60x60x24x30 for a 30 day month.. I don't have a protocol monitor available anymore, but after several hours of reading, I believe that the protocol in use ( I think its Shoutcast, which uses HTTP streaming) actually goes into a "long polling" cycle to keep the port open. This would generate less data on the connection when the encoder has nothing to send.. Was the 5 GB per month based on actual measurement or the above example? I agree with the several statements here providing streams is a choice that needs to be measured against one's personal resources, regardless of the eventual use by someone else. I view it as very similar to contributing to an open source software project, which can result in the use of the product by for-profit companies..

Anyway, the thread resulted in a couple of interesting hours reading about protocols.. I trust that the discussion was allowable...........

 

[kendrik578]

bezking and kendrik578:
I joined in on more of a interest in the statement that the monthly data usage for a feed would be based on (encoding rate)x60x60x24x30 for a 30 day month.. I don't have a protocol monitor available anymore, but after several hours of reading, I believe that the protocol in use ( I think its Shoutcast, which uses HTTP streaming) actually goes into a "long polling" cycle to keep the port open. This would generate less data on the connection when the encoder has nothing to send.. Was the 5 GB per month based on actual measurement or the above example? I agree with the several statements here providing streams is a choice that needs to be measured against one's personal resources, regardless of the eventual use by someone else. I view it as very similar to contributing to an open source software project, which can result in the use of the product by for-profit companies..

Anyway, the thread resulted in a couple of interesting hours reading about protocols.. I trust that the discussion was allowable...........

Yes of course its based on encoding rate, but ether way its around (not an EXACT measurement, but very close) 5gb a month per feed encoding at 16kb (double that for additional feeds and stereo feed). Its definitely not something thats going to put you in the hole for a bandwidth cap.