Completely Portable Wireless System(PXE, etc)

[Virucyde]

A search of past posts makes it look like the general agreement is that wifi is simply too slow to use for LinuxMCE. Now, with 802.11ac coming out I figure it's time to revisit that assumption. The reason I'm interested is because I'm still apartment-hopping fairly regularly, and would like to create a system that's entirely portable from one place to another. I shouldn't have to modify any existing infrastructure to install my systems.

I asked over on iPXE's forums how capable iPXE is of booting over Wifi. PXE booting is preferred for a more centralized system, and iPXE is ideal, wifi or not, due to the fact that it allows you to send the boot images over HTTP, rather than the horrendously slow TFTP. My experience with installing it in a computer shop tells me it boosts speeds by well over 10x. Unfortunately, it appears it has very small wireless device support, so I was hoping you guys could recommend a small, convenient wireless bridge/switch I could use for PXE booting. While this switch could also act as my Internet Connection, I'm guessing it'll be cheaper for me to go with an 802.11ac adapter, since 802.11ac switches are likely to be quite expensive, and I really only need it for PXE booting.

Next up is lighting. I'm wondering if there is any planned support(or current support) for LIFX(when it comes out) or the Philips Hue(Already out). I'd also like to combine my sound system with my lighting for portability sake, so if anyone knows of any projects intending to merge the wireless speaker light bulbs(AudioBulb) idea, with wifi/API controllable LED bulbs like the ones above, please post it Something like NEC Lighting's speaker light bulb, but ideally one that would fit better into a normal bulb's space.

I think wireless cameras are already well-supported, so I don't see that being an issue, and wireless thermostats have been out for a while. If you can think of anything that'd go well with a fully portable LinuxMCE setup, please post it, or if you can answer any of the above questions, thanks!

[l3mce]

Ever wonder why wireless routers don't have a collision light? Because they would stay lit.

The end result will appear to be slow speed, constant lost and regained connections. Ever had a movie stop in the middle and throw up the generic DVD not readable error?

Would be very bad with wireless. So, like with cars, it is not so much how fast you go... it is the collisions which matter. At least this is my understanding of the situation.

[Virucyde]

Ever wonder why wireless routers don't have a collision light? Because they would stay lit.

The end result will appear to be slow speed, constant lost and regained connections. Ever had a movie stop in the middle and throw up the generic DVD not readable error?

Would be very bad with wireless. So, like with cars, it is not so much how fast you go... it is the collisions which matter. At least this is my understanding of the situation.

I suppose I'm confused why it had such an issue with old wireless, considering I'm able to stream 1080p videos(albeit compressed ones) over 802.11g wifi in my home.

Also, with beamforming I think collision issues will be a lot less of a problem.

[l3mce]

Because LMCE is unlike anything else. We open and close connections based on need/availability. We create a transparent data universe, which is then made visible by type. We DO media, but we are not a media player. How the architecture "works" is based on polling and queries... and our little post office sending messages around.

Collisions are disruptive to our system.

Again, this is just what I have gleaned from conversations. If collisions die down, then it may be a viable alternative. You are certainly free to experiment if you have the equipment and post your results, or problems. I would be happy to help you test.

[Virucyde]

So if we continue, assuming that 802.11ac resolves media speed issues, what about the other components of the setup?

[l3mce]

Again... it isn't actually a speed issue. The result will appear to be poor speed.

You just have to be able to pxeboot from wireless.

[Virucyde]

Did I not make it clear that I'm fairly certain beamforming will result in less collisions? Less collisions, by your information, is greater speed. I'm really confused how "collisions" could possibly be the problem though, considering LinuxMCE shouldn't be concerned with how the data is traveling, since the hardware will handle that.

With iPXE, PXE booting shouldn't be a problem. I can understand that it was problematic using TFTP, since the protocol is so slow already, but I've used iPXE with HTTP in the past and PXE booted entire OSs through a wireless bridge no problem.

[hari]

hey if you know it better just go for it. I've done some tests in the past with 802.11g and that was too slow. nfsroot puts a lot of traffic on the line. I'm not sure how much beam forming shall help.. it is not like the AP is rotating a uni-directional dish antenna with a small motor :-) And even then you have a shared medium where send and receive can collide, even with a single node. But maybe current 802.11n speeds are sufficient, I did never try. If you want to go that route, please report back if it works.

regarding the bulbs, it is not practical to just replace the bulb as you would lose ability to control them with the existing switches. If it is switched off with the switch, you can't switch it on over wireless.

[sambuca]

Often it is a question about latency and not bandwidth. I don't know if the 802.11n or newer standards improve on latency, but afaik radio will never have the same low latency as wired networks.

But as hari said, please try it and let us know - we are interested in learning if it works.

best regards,
sambuca

[bwhitson]

Virucyde,

I think what the others are trying to get at is the basic way in which wireless networks preform as a result of their inherent structure.
One of the greatest improvements in speed, other than faster radios and protocols, was the ability to MIMO.
In a classic wireless network, other than with multi in multi out, one has to assume a token ring architecture. This often results in massive bottle necks.

It may very well be possible to send a VLC stream from one side of the apartment to the other with no problems.
But try doing that while both of your kids are watching youtube videos and playing XBOX live over wifi, then throw in streaming Pandora through my XBOX over wifi and you'd soon find your wife yelling at you that she is having problems watching netflix from her iPhone. (Yes I speak from experience)

I have 16meg uverse internet so I am quite certain the bottle neck is not my connection but the wifi.

[Virucyde]

regarding the bulbs, it is not practical to just replace the bulb as you would lose ability to control them with the existing switches. If it is switched off with the switch, you can't switch it on over wireless.

Hmm, this crosses my line about replacing existing infrastructure, but are there such things as cheap wireless switches that let you turn them on remotely, or simply turn them off digitally? I might be okay with replacing wall switches, that's just a couple screws and some surface-level wiring. For example does Z-Wave's HomePro switch work with LinuxMCE?

Often it is a question about latency and not bandwidth. I don't know if the 802.11n or newer standards improve on latency, but afaik radio will never have the same low latency as wired networks.

From what I'm hearing it appears that bandwidth is definitely part of the problem, since more bandwidth means each device has to be signaling for a longer period of time, resulting in an increase in these "collisions," it seems like better bandwidth would allow quicker buffering. And really, I don't mind latency issues when it comes to just sending commands, as long as the commands eventually get there.

Now, is the major issue with getting the Media Directors to PXE boot, or is it mostly with streaming videos?

Other posts on this forum have said that 720p video is sometimes possible with 802.11N. Also, it seems like more powerful Media Directors would allow you to use more compact video encodings. I get the feeling a lot of the videos people are trying to stream are direct rips from DVDs and such with very little compression, resulting in high volumes of data. For example, with H.265 coming out in the near future, I think you could substantially reduce your video sizes, assuming the Media Directors could handle the codec.

Now, I'm talking about future technologies, but as far as I can tell, the wiki seems to think video streaming is doable now:
http://wiki.linuxmce.org/index.php/Wireless_Networking

However, let's say I decide to simply connect the Core to my TV with a wired connection, and then use the wireless functions for everything else in the house, does anyone think that would be a problem? I'd still like to know if anyone has any hardware ideas for what I asked about.

[jamo]

I don't mind latency issues when it comes to just sending commands, as long as the commands eventually get there.

Don't forget, latency will affect all messages, including "commands". So when you push the button on your remote, that sends a message to this device which sends a message to that plugin which forwards two messages to two other devices which then moves "up" one item on your onscreen menu. All of that goes over the network via the DCERouter (core). If you are happy to wait a bit between pressing the button on  your remote and the next menu item to be highlighted, then you know you're happy with latency.

[Marie.O]

[..]I might be okay with replacing wall switches, that's just a couple screws and some surface-level wiring. For example does Z-Wave's HomePro switch work with LinuxMCE?

All regular Z-Wave stuff that does not use encryption (like the locks need), should work. To be sure, order from http://www.lmcecompatible.com. They stock stuff that is compatible.

However, let's say I decide to simply connect the Core to my TV with a wired connection, and then use the wireless functions for everything else in the house, does anyone think that would be a problem? I'd still like to know if anyone has any hardware ideas for what I asked about.

If you use wireless for stuff like Z-Wave, Orbiters etc. there is nothing holding you back.

[Virucyde]

Don't forget, latency will affect all messages, including "commands". So when you push the button on your remote, that sends a message to this device which sends a message to that plugin which forwards two messages to two other devices which then moves "up" one item on your onscreen menu. All of that goes over the network via the DCERouter (core). If you are happy to wait a bit between pressing the button on  your remote and the next menu item to be highlighted, then you know you're happy with latency.

I'd think using the web interface with a smart phone or the new Orbiter app for Android would mitigate this issue somewhat, would it not?

[Virucyde]

I'm not sure how much beam forming shall help.. it is not like the AP is rotating a uni-directional dish antenna with a small motor :-)

I forgot to respond to this, obviously they don't have a mini rotating antenna, that's not how it's done, they have an antenna array that gives a very similar effect. Interestingly enough, this should also make WPA2 more secure since capturing handshakes after sending DEAUTHs should prove more difficult.

So what I've gotten from this thread is that if I were to attempt a setup like that I'm talking about, I'd likely need to write my own interfaces for the devices, since LinuxMCE has fairly limited device support(what else would I expect?). At this point it looks like when it comes to lighting, the simplest solution is to use the software provided for the various solutions currently out, and keep it separate from LinuxMCE. I think once LIFX is released that might be a more reasonable venture, since it'll have an open API and is intended to communicate with network devices.

Audio appears to be in a similar boat, although for apartment purposes I don't think overhead speakers are necessary.

All that being said, I do think that 802.11ac will reduce problems with interference from various connections, for two reasons. First, beam forming should reduce the signal spreading significantly, and second, higher bandwidth means less time is necessary to transfer the same amount of data, so collisions are less common. That along with newer video codecs, such as H.265, should make video streaming over Wifi much more viable.

Of course, not many devices support it yet, so it'll probably be a couple years before I can let you guys know how it worked out.