Ask HN: What's next big thing in bandwidth?
12 comments
Stuff for 3D printers?
Live streaming? Yeah, we have it now, but let's say a night club give its visitors glasses which broadcast what they're seeing through a website so people can check if it's worth going... live streaming on stereoids. Or on sports matches... televisions would love to have more cameras on stadiums. Just imagine if you can figure out that an spectator, from glasses #44403, looked from seat 34 to ZXY axis, which is where something that you wanted to see happened, but your camera couldn't catch.
Mesh networks? 10 years ago we didn't have mobile internet, so it came and was expensive, now it's everywhere, and getting cheaper. But I think it's inevitable, someday someone will release a cellphone that can mesh and has mile range, and connect to free wifi networks on Starbucks, and managing all these small hubs of bandwidth inteligentlly will be hard.
Video will keep getting bigger, because tvs are getting bigger, encoders are getting better, and all that stuff. Sure more bandwidth helps, it always does, but imagine a movie studio instead of releasing to cinemas, they will, at the same day, release for download "directly" to your TV. So this video will have to be mirrored around the world, on cities, etc... because bandwidth pipe will keep getting larger, but there's always room to save costs.
If you want to go even further into the future, think space tourism, news from the/for a ISS-like hotel... er.. better get back to work.
Live streaming? Yeah, we have it now, but let's say a night club give its visitors glasses which broadcast what they're seeing through a website so people can check if it's worth going... live streaming on stereoids. Or on sports matches... televisions would love to have more cameras on stadiums. Just imagine if you can figure out that an spectator, from glasses #44403, looked from seat 34 to ZXY axis, which is where something that you wanted to see happened, but your camera couldn't catch.
Mesh networks? 10 years ago we didn't have mobile internet, so it came and was expensive, now it's everywhere, and getting cheaper. But I think it's inevitable, someday someone will release a cellphone that can mesh and has mile range, and connect to free wifi networks on Starbucks, and managing all these small hubs of bandwidth inteligentlly will be hard.
Video will keep getting bigger, because tvs are getting bigger, encoders are getting better, and all that stuff. Sure more bandwidth helps, it always does, but imagine a movie studio instead of releasing to cinemas, they will, at the same day, release for download "directly" to your TV. So this video will have to be mirrored around the world, on cities, etc... because bandwidth pipe will keep getting larger, but there's always room to save costs.
If you want to go even further into the future, think space tourism, news from the/for a ISS-like hotel... er.. better get back to work.
Symmetric internet links will be a big deal, if they ever happen - right now most places seem to be 8Mbit downstream and 1Mbit upstream - once symmetric high-bandwidth applications become popular p2p technologies can really start taking off.
What symmetric high bandwidth applications?
I can't think of any consumers that want to upload as much as they download.
I can't think of any consumers that want to upload as much as they download.
I would say Games would be huge, where we play without actually installing 8 or 10GB worth of data. Maybe just playing level by level, where it downloads files needed for that level.
Also HD video would lot more bandwidth, so i am thinking that will be huge too.
Also HD video would lot more bandwidth, so i am thinking that will be huge too.
Other than the obvious P2P file sharing that grows to fill the available space, better responsiveness (less buffering time) for high bit rate streaming video will probably dominate bandwidth needs for the near future.
Remote computing applications will probably also get richer as latency drops and throughput increases.
If we ever get in front of the common user's bandwidth needs, I'd say you might see applications that download speculatively, such as pre-buffering the videos advertised in the youtube player at the end of the selected video, or pre-downloading (pieces of) movies or TV shows that you watch online.
Beyond that there's room to innovate in being clever (video codecs that don't under-run but degrade the bitrate of the video trying to keep things flowing), and there's probably a lot of untapped innovation there that could take advantage of more bits.
Remote computing applications will probably also get richer as latency drops and throughput increases.
If we ever get in front of the common user's bandwidth needs, I'd say you might see applications that download speculatively, such as pre-buffering the videos advertised in the youtube player at the end of the selected video, or pre-downloading (pieces of) movies or TV shows that you watch online.
Beyond that there's room to innovate in being clever (video codecs that don't under-run but degrade the bitrate of the video trying to keep things flowing), and there's probably a lot of untapped innovation there that could take advantage of more bits.
I think people will stop storing their data locally. This will not mean bigger transfer than video, but the number of transfer could be huge. It is doable with the bandwidth we already have, but it will become ubiquitous only when locally or remotely stored will almost feel the same.
To go with this, we need to see a large drop in latency. I think the biggest obstacle will be overcoming the total write/read throughput and speed when placing data over the broader internet versus a local hard drive or SAN/NAS.
I don't see how latency would be a big problem for file storage. Home user file reads and writes are very spatially coherent, right? Keep the first N bytes of each file in a local cache, and when the user starts to read a file, you're pre-buffered. Note that this is just a cache; the whole file is still reliably stored at the remote site.
Users probably use the same small subset of files over and over again, too, so you don't even need to keep the head of all the files to eliminate most latency effects.
Users probably use the same small subset of files over and over again, too, so you don't even need to keep the head of all the files to eliminate most latency effects.
There is one constant we can't beat -- the speed of light. Unless servers are physically closer to the people using them, latency will always be an issue.
I don't think that is the bottleneck:
"If you were a beam of light, then your trip [around the world] would take only 1/10 of a second."
http://www.bigsiteofamazingfacts.com/how-long-does-it-take-t...
"If you were a beam of light, then your trip [around the world] would take only 1/10 of a second."
http://www.bigsiteofamazingfacts.com/how-long-does-it-take-t...
100 ms is still a pretty big latency.
Add to that the slowdown of propagating in a fiber optic cable, and you've just increased the time to 150 ms.
So, for a server 1/4 of the way around the world, you're stuck with a minimum round trip time of 75 ms. This will be increased by switching times in repeaters, for example. And that's only for one data packet.
Add to that the slowdown of propagating in a fiber optic cable, and you've just increased the time to 150 ms.
So, for a server 1/4 of the way around the world, you're stuck with a minimum round trip time of 75 ms. This will be increased by switching times in repeaters, for example. And that's only for one data packet.
> And that's only for one data packet.
A crucial point. A few years back, I had to deal with some rather "chatty" applications that were attempting to span filesets/databases located in both the U.S. and India. Latency on a single data exchange might be annoying; multiply that by hundreds or thousands of exchanges per each human-level interaction with the application, and said application ground to something that would make a "crawl" look high speed.
Partly the vendor's fault, for not accurately representing this situation. Partly the Company's fault for neither anticipating nor investigating it (nor listening to me when I advocated doing so); further, for attempting a non-standard deployment in an attempt to save a few bucks.
I guess I'll blame the vendor again for such an unnecessarily verbose and crap-laden application design. Anyway, the whole thing turned into one giant, festering pool of fail, that the users actively avoided when they could and loathed and sweated over when they couldn't. Eventually, turnover at the pointy haired boss level made it politically feasible to kill more and more of the pieces, and now some years later the Company has supposedly ponied up the money for a solution that actually works (well, the demos look/work better, and the basic design seems capable of allowing it to work).
When I think of the countless hours and frustration wasted on that doomed deployment.
So, anyway, watch your network latency, know your application design, and pay attention to the implications. When testing, test network performance, and inject latency, noise and the like to get a picture of what things will look like in the real world.
Sounds simple; nonetheless, this technologically relatively sophisticated company still managed to completely screw it up.
A crucial point. A few years back, I had to deal with some rather "chatty" applications that were attempting to span filesets/databases located in both the U.S. and India. Latency on a single data exchange might be annoying; multiply that by hundreds or thousands of exchanges per each human-level interaction with the application, and said application ground to something that would make a "crawl" look high speed.
Partly the vendor's fault, for not accurately representing this situation. Partly the Company's fault for neither anticipating nor investigating it (nor listening to me when I advocated doing so); further, for attempting a non-standard deployment in an attempt to save a few bucks.
I guess I'll blame the vendor again for such an unnecessarily verbose and crap-laden application design. Anyway, the whole thing turned into one giant, festering pool of fail, that the users actively avoided when they could and loathed and sweated over when they couldn't. Eventually, turnover at the pointy haired boss level made it politically feasible to kill more and more of the pieces, and now some years later the Company has supposedly ponied up the money for a solution that actually works (well, the demos look/work better, and the basic design seems capable of allowing it to work).
When I think of the countless hours and frustration wasted on that doomed deployment.
So, anyway, watch your network latency, know your application design, and pay attention to the implications. When testing, test network performance, and inject latency, noise and the like to get a picture of what things will look like in the real world.
Sounds simple; nonetheless, this technologically relatively sophisticated company still managed to completely screw it up.
I don't know if this is in the cards or not, but what I hope will be the next big thing in bandwidth is cheap mobile data plans, on par with cable/dsl plans, which (together with cheaper, more powerful phones) would help push mobile computing towards ubiquity.
[deleted]
All your home usual staff on the mobile gadged.
I think 700Mhz Wimax connection across USA from "google" might be huge.
Looks like it might not be wimax.
telecommute
the next stage is mobile computing. your smartphone will become a seamless integration with your home desktop and cloud SaaS products (your desktop will be part of the cloud as well, hell maybe even your mobile will have shared storage and be serving data). Live video telecommunications will become the norm. everyone will be a videoblogger. everyone will live with the internet at their fingertips 24/7.
it's scary isn't it?
it's scary isn't it?
I have to agree here. We already have movies and TV on demand on the web, "life streaming", etc. More bandwidth into the home just means increasing quality, increasing interactivity, broader adoption, etc. But, phones are just now getting broad enough broadband to make it interesting.
I'd wager that everything old will be new again on mobile devices. How many of those are business opportunities for small new companies? I dunno. YouTube has been very effective on mobile, so user-created video content is probably not one of those opportunities.
I'd wager that everything old will be new again on mobile devices. How many of those are business opportunities for small new companies? I dunno. YouTube has been very effective on mobile, so user-created video content is probably not one of those opportunities.
Higher resolution streaming movies will be the most important thing in the next few years to come.
Projecting further into the future, 3D image/hologram transmission could be a probable candidate.
Projecting further into the future, 3D image/hologram transmission could be a probable candidate.
I was wondering: what do you guys think will be big things in a few years time that will require a big bandwidth that's not yet available at the moment? Some years ago, this would probably have been watching movies online. So what will it be in the next few years? Any ideas?