How much bandwidth...

The problem with all of that will be, of course, will people spend extra money to get that feature. Personally, I wouldn't.

I would not spend even $50 more to have a wireless computer over a tower.

First reason is simple: it's like a laptop for the home, but you can't take it with you. Yes, I realize that it's being run by the tower, but it's function is still the same; just not as good because you can't take it out of the range of the tower.

Second reason is debatable, sort of. This proposed LCD... what if I want a bigger one? Or just a newer one? I'd probably have to buy a new enclosure for it which would be expensive.

Third reason: all of the peripherals, etc. of that computer would be stationary (in or near the tower). To access them you'd have to be at the tower anyway.

Too many disadvantages in return for slightly increased mobility. If they did it for no cost, fine, I'd set up the monitor right where I'd put my desktop monitor anyway.

I just don't see the advantage.

-Ender

Hmm... I wouldn't want to pay extra for it either, unless it could double as a tablet PC you could carry around. But to answer your question, here's what I think:

1024x768 = 786,432 pixels. x 60Hz (that's low) = 41,785,920. That's in bits/sec. /8 = 5,223,240 Bytes/sec. So /1024 and it's 5100.82KB/sec. /1024 = 4.98127MB/sec. That's about 1/2 the theoretical bandwidth of 802.11b, or 1/10 of the bandwidth of 802.11a. Do you really want to take all that up JUST with the screen?

Someone please correct my math if I'm wrong.

[quote]Originally posted by KD5MDK:
<strong>1024x768 = 786,432 pixels. x 60Hz (that's low) = 41,785,920. That's in bits/sec. /8 = 5,223,240 Bytes/sec. So /1024 and it's 5100.82KB/sec. /1024 = 4.98127MB/sec. That's about 1/2 the theoretical bandwidth of 802.11b, or 1/10 of the bandwidth of 802.11a. Do you really want to take all that up JUST with the screen?
Someone please correct my math if I'm wrong.</strong><hr></blockquote>

Well, you asked for it
The calculation goes as follows:
1024 * 768 pixels/screen * 4 bytes/pixel * 60 screens/second = 188743680 bytes/second = 180 megabytes/second
This is way more than even the theoretical max. bandwidth of GBit-Ethernet.
Besides, 802.3b can handle 11 mega*bits* per second, not mega*bytes* - obviously, wireless displays aren't really likely to appear soon

Bye,
RazzFazz

KD5MDK,

You are forgetting color (thousands - 16, million - 32?)...and there goes your bandwidth. If you've ever run VNC, the redisplay is not realtime on 100 Base-T ethernet connection, but almost. Wireless is not even close, yet.

-Banshee-

Dammit, I knew I was forgetting something. Yes, I had thought of 32bit color (your 4Bytes), and passed over it. Same with the wireless bandwidth.

However, by going up to 10Ghz or more you can get bigger portions of the spectrum in exchange for greatly reduced range.

Plus I believe DVI is said to use 1.6Gbps/sec

[quote]Originally posted by Banshee:
<strong>If you've ever run VNC, the redisplay is not realtime on 100 Base-T ethernet connection, but almost.</strong><hr></blockquote>

Actually, it's not even near realtime, the refresh rate is *much* slower vie VNC.
Sure, for most stuff this won't make any difference, but try playing a 3D game or watching full-screen video through through VNC...

Bye,
RazzFazz

RazzFazz, you are correct about VNC and I run mine at 256 colors. Decent for word processing type stuff but woefully inadequate for anything demanding.

KD5MDK, the 10 GHz band is currently taken by military (and other) radar. Besides, there aren't too many solid state transmitters in that band.

-Banshee-

Probably because DVI doesn't go very far without a whole bunch of extenders and stuff.

As for 10Ghz, it was just for example. If I wanted, I could stick Ham gear there, but it would be too much trouble. I'm sure there's some unliscensed bands available in the microwave range that could be used for this if it was worth it.

I kind of like the idea, and actually had thought a bit about it in the past. Assuming you can address the video bandwidth issue, it would be nice to have your fire-breathing, supercomputing, storage-monster, online enabled tower somewhere in the house while being able to access it from your remote terminal from any room in the house (in the living room while watching TV, in the bathroom???, while sitting in bed, out on the deck/patio). I think it is a very logical extension of where home computing may head in the future. As long as laptops continue to favor "skimped" architectures (compared to their tower brethen) while charging heavy premiums, I think the mobile terminal is a good idea.

Perhaps the solution to the video bandwidth issue is on-the-fly video compression. No one ever sends a full DV signal across a bandwidth sensitive medium. It is always compressed on one end, sent as a compressed stream, and decompressed on the receiver end. Maybe some variation of the MPEG2 algorithm? I say MPEG2 and not MPEG4 because MPEG4 would introduce encoding performance issues and possibly expensive chips to do it in realtime. You would still need some dedicated chip to do the realtime encoding in MPEG2 in the tower, and that could still be a deal breaker. Maybe just light, fast compression rates (nothing too aggressive in the search for maximum compression) just enough to let you fit into the wireless bandwidth constraints, and you could get away with conventional encoding hardware w/o needing anything extravagent. It is certainly possible, as dish-based TV services do it everyday already.

Has no one else ever heard of X Windows? I've seen an entire row of X Terminals run at full speed off of one single 10bT connection. Of course, we weren't playing quake on them or anything, but it worked plenty fast for word processing and browsing the internet. I've pointed this out several times, both here and at the MacNN forums. How come nobody will believe me?

[quote]Originally posted by cdhostage:
<strong>Rrg. I wonder why networking transfers are so much slower than monitor transfers. Whywhywhy!</strong><hr></blockquote>

Cabling issues. DVI can only move the signal a couple of meters at most (i.e. from your monitor to your 'puter) - obviously, this wouldn't really be appropriate for networking purposes.
Besides, DVI is point-to-point only, whereas in a networking environment, you usually have more stations involved, plus switches / hubs / etc.

Bye,
RazzFazz

[quote]Originally posted by Randycat99:
<strong>Perhaps the solution to the video bandwidth issue is on-the-fly video compression. No one ever sends a full DV signal across a bandwidth sensitive medium. It is always compressed on one end, sent as a compressed stream, and decompressed on the receiver end. Maybe some variation of the MPEG2 algorithm?</strong><hr></blockquote>

MPEG is fine for video, but inappropriate for high-contrast stuff (like your typical 2D application), much in the same way that JPEG is excellent for photos, but try saving a screen capture of an excel sheet as JPEG, and you'll see what I mean.
Thus, you'd have to have 2 forms of compression (MPEG-like for video, photos and stuff, and GIF-like for "other" stuff), and a way to automatically select which one works best with the current screen contents, which kinda sounds non-trivial (and probably pretty expensive) to me.

Bye,
RazzFazz

[quote]Originally posted by Whisper:
<strong>Has no one else ever heard of X Windows? I've seen an entire row of X Terminals run at full speed off of one single 10bT connection. Of course, we weren't playing quake on them or anything, but it worked plenty fast for word processing and browsing the internet. I've pointed this out several times, both here and at the MacNN forums. How come nobody will believe me?</strong><hr></blockquote>

Sure, XWindow across a network is a good choice if you primarily work with non-graphics-intensive apps (i.e. office apps, programming, ...), but you can't watch movies over the net, for example (as the decoding takes place inside the computer, not inside the display / terminal).

Bye,
RazzFazz

Don't forget the noise.
As you know, RGB cables will often deliver better image quality on analog displays, than VGA cables, because their shielding is better.
Now if you send you image data over the air, there will be a LOT of noise in the signal when it reaches the screen, and thus there would be some serious problems to come by in order to maintain acceptable image quality.
Also, you'd have to choose between digital transmission and analog waves. The firs brings with it some serious bandwidth problems, as noted above, while the second would require very expensive parts, and broad bands, surely interering with some FCC rules or whatever. Then again, you'd also have to use some kind of protocol and encoding to avoid your neighbor to see your screen content on his "AirScreen"...I think there are far too many issues involved to even think about this for the next 10 years or so.
More interesting it might get with ionized rays of air conducting the current etc...That stuff already works for tasers, so in the future it might be done. Of course this would require visual contact between the emitter and the receiver.

Interesting idea, yet at least 10 years too early

G-News

[quote]The calculation goes as follows:
1024 * 768 pixels/screen * 4 bytes/pixel * 60 screens/second = 188743680 bytes/second = 180 megabytes/second
This is way more than even the theoretical max. bandwidth of GBit-Ethernet.
Besides, 802.3b can handle 11 mega*bits* per second, not mega*bytes* - obviously, wireless displays aren't really likely to appear soon <hr></blockquote>

That's all well and good, but that assumes no compression. Obviously we're not going to want to use anything that's lossy. How big is a 1024x768 PNG, for reference?

Compression efficiency varies depending on the nature of the data. I'm guessing that PNG could compress a simple image (black square on white background) down to almost nothing, but it would have trouble compressing a complex picture of a cityscape, with lots of detail and variance in contrast, etc. The problem is that you can make no assumptions about the nature of the images that a computer screen will display, so you'd have to design for the worst case to get consistently acceptable performance. Lossless compression tends to have a worse worst case (no compression at all) than lossy compression does.

Assuming that you do find the bandwidth, the CPU has to be capable of compressing the signal in real time with negligible latency, and the monitor has to be capable of decompressing the signal in real time with negligible latency. Furthermore, it should wrap the signal in some form of encoding that allows for error checking and correction, since wireless signals run into interference problems all the time. Furthermore, you'd want to encrypt the signal, unless you want everyone within 150 feet to see what you're doing. All in real time, all with negligible latency. Everything the CPU has to do, the monitor has to undo, so both will require DSPs, raising the cost of both units.

I don't think we'll see this for some years, if ever. I think it's more likely that the displays themselves will become lighter and less fragile until they can be used more or less like books and paper are now.

[quote]Originally posted by RazzFazz:
<strong>

Sure, XWindow across a network is a good choice if you primarily work with non-graphics-intensive apps (i.e. office apps, programming, ...), but you can't watch movies over the net, for example (as the decoding takes place inside the computer, not inside the display / terminal).

Bye,
RazzFazz</strong><hr></blockquote>

So why can't we use our little wireless, quartzified xterms for the non-graphics-intensive apps and then go sit down at the actual computer when we need to use a non-non-graphics-intensive app? And I'm still not convinced that caching couldn't resolve most of the bandwidth issues for the "non-non-graphics-intensive apps" (except for watching movies and maybe playing 3D games). I'm pretty sure that an X Windowsish scheme will work for just about everything else.

[quote]Originally posted by Whisper:
<strong>So why can't we use our little wireless, quartzified xterms for the non-graphics-intensive apps and then go sit down at the actual computer when we need to use a non-non-graphics-intensive app?</strong><hr></blockquote>

Nobody said you can't, but I don't get the point of doing so, if it's not supposed to replace current computers. For word processing, you'd probably have to carry around a keyboard and a mouse too, so there goes your mobility vs. a laptop. In situations where you don't need keys and mouse, you could probably just use one of those e-book readers.


[quote]<strong>And I'm still not convinced that caching couldn't resolve most of the bandwidth issues for the "non-non-graphics-intensive apps" (except for watching movies and maybe playing 3D games).</strong><hr></blockquote>

Well, actually those two were the key "non-non-graphics-intensive apps" I was referring to. What else would need full-screen refreshing at a constant, high rate?

Bye,
RazzFazz

[quote]Originally posted by RazzFazz:
<strong>Nobody said you can't, but I don't get the point of doing so, if it's not supposed to replace current computers. For word processing, you'd probably have to carry around a keyboard and a mouse too, so there goes your mobility vs. a laptop.</strong><hr></blockquote>
A laptop's HDD is slow and small. With one of these wireless quartzified xterms, you can have Ultra3 SCSI Cheetah Array speed without actually having to lug a bunch of big drives around your house with you. Also, since the HDD isn't in this little "iPad", it's not the end of the world if you drop it, or it gets stolen, etc.
[quote]<strong>In situations where you don't need keys and mouse, you could probably just use one of those e-book readers.</strong><hr></blockquote>
Those gizmos are pretty cool, but as far as I know none of them can display anything other than a few books. If you were using a wireless display, you could access your entire HDD and the internet.

edit: spelling

[ 12-09-2001: Message edited by: Whisper ]</p>