casey@gauss.llnl.gov (Casey Leedom) (10/24/90)
| From: ibekhaus@athena.mit.edu (Ira B. Ekhaus) | | 1: how well does this scheme/product work? Very well. I'm using one right now. I like it a lot. The only down side is that it only 14" 800x600 pixels. They've just come out with a new 21" 1240x1024 (approximately -- I don't have my notes with me.) We're scheduled to take a demo of it, but haven't seen it yet. They've also come out with a new compression scheme that supposed to be even better. | 2: The hardware that graphon uses is comparable to a PC, is there | a comparable scheme/product that is essentially terminal emulation | software? No. Unfortunately. I've been hitting on GraphOn extremely hard on this issue. Give them a call at 800-GRAPHON and hit on them too. The more people they have asking for it the sooner they'll do it. Casey
mouse@LARRY.MCRCIM.MCGILL.EDU (10/24/90)
> I heard about an Xterminal by graphon corporation that employed a few > unique features. The host creates a compressed output (proprietary > scheme) that allows an xwindow to operate (reasonably) over a serial > line. > 1: how well does this scheme/product work? It works about as well as you can get over a serial line. I used one of these briefly; it was being driven off a Sun-4 over a 19200 bps line. Text-type stuff worked just fine; bitmap-type stuff was a real pig, as one would expect (just ain't no way you're gonna shove more than 19K a second over that wire!). The version I used limited pointer cursors to 16x16; this was an unpleasant surprise (I have grumbled about this before; I'll restrain myself here). I do not know whether this has been fixed since, or whether it is universally true of their products or not. > 2: The hardware that graphon uses is comparable to a PC, is there > a comparable scheme/product that is essentially terminal > emulation software? If you mean, is there terminal emulation software that runs over serial lines, the answer is yes, there are many such. Any terminal qualifies, for example :-) I do not recall whether the box I used supported such a thing directly or not. I think it must have, because I have a hard time seeing how the proxy server would have gotten started otherwise, but that is my only reason for believing so. > 3: if q 1 and 2 are not reality, what is the best way to bring up\ > an xterminal with pc software. This sounds as though you think the display end runs on a PC. Well, except in perhaps a very restricted meaning of "computer" in that phrase, it didn't in the case I saw. The box on the desk in front of me was not a general-purpose computer; you could not use it except as an X terminal (and, presumably as a dumb terminal to start the X session). If you want an X server for your PC, there are many such; I know they exist for IBM DOS machines (and clones) and Macintoshes; I don't know about any other of the machines normally thought of as PCs, though many machines which really are PCs do have X servers (like Sun-3/50s - just try to put multiple users on one and watch it die). der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mikeh@bryant.NCD.COM (Mike Harrigan) (10/26/90)
In article <9010240817.AA15043@Larry.McRCIM.McGill.EDU>, mouse@LARRY.MCRCIM.MCGILL.EDU writes: |> > I heard about an Xterminal by graphon corporation that employed a few |> > unique features. The host creates a compressed output (proprietary |> > scheme) that allows an xwindow to operate (reasonably) over a serial |> > line. |> Another way of getting X over serial lines is with NCD X terminals running XRemote. This is NCD's proprietary protocol that runs reasonably well at 9600 baud (V.32 modems) up to 38.4 Kbaud. Unlike other serial line approaches, NCD terminals have the X server local, so pixmaps can be stored locally and brought up fast. With backing store windows can pop fast, etc. XRemote is available for all various NCD models. For more information contact NCD. phone: (415) 694-0650 email: info@ncd.com Mike Harrigan Network Computing Devices mikeh@ncd.com
casey@gauss.llnl.gov (Casey Leedom) (10/27/90)
| From: mikeh@bryant.NCD.COM (Mike Harrigan) | | > I heard about an Xterminal by GraphOn corporation that employed a few | > unique features. The host creates a compressed output (proprietary | > scheme) that allows an xwindow to operate (reasonably) over a serial | > line. | | Another way of getting X over serial lines is with NCD X terminals | running XRemote. This is NCD's proprietary protocol that runs reasonably | well at 9600 baud (V.32 modems) up to 38.4 Kbaud. Unlike other serial | line approaches, NCD terminals have the X server local, so pixmaps can be | stored locally and brought up fast. With backing store windows can pop | fast, etc. XRemote is available for all various NCD models. For more | information contact NCD. We just ran a head to head comparison of the NCD/XRemote against the GraphOn. The GraphOn outperformed the NCD on almost all operations by very wide margins ranging from %200 to %1000. The NCD/XRemote did outperform the GraphOn on some stippled operations which seem to indicate a failing in the GraphOn graphics protocol. I'm waiting for copies of the new software to reperform our tests. The GraphOn is currently the obvious choice for serial line X11 operation. As I said before, since I have yet to play with GraphOn's Ethernet implementation, I can't say anything about that. My only objections to going with the GraphOn are: 1. The protocol is proprietary. There isn't a publically available sample server and client. 2. It would be trivial to implement the client side software on PCs and GraphOn still hasn't done this. I'm waiting on buying a Macintosh on this issue. 3. They still haven't addressed the color issue. This is especially important when the possibility of PC client software is considered. Casey
lowe@cs.ubc.ca (David Lowe) (10/29/90)
In article <69417@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: > We just ran a head to head comparison of the NCD/XRemote against the >GraphOn. The GraphOn outperformed the NCD on almost all operations by >very wide margins ranging from %200 to %1000. The NCD/XRemote did >outperform the GraphOn on some stippled operations which seem to indicate >a failing in the GraphOn graphics protocol. I'm waiting for copies of >the new software to reperform our tests. > The GraphOn is currently the obvious choice for serial line X11 >operation. [rest deleted] Let me put in a good word for the NCD XRemote. I have been using an NCD 19 with the XRemote PROMs over a 9600 baud modem for the past 2 months. I have found it to be a very good solution for working at home. The best aspect of the NCDs is their excellent displays, with 1280x1024 resolution, 19 inch size, 70 hz non-interlaced, and paper-white phosphors. The display is better in every respect from the SparcStation in my office, and it is completely silent. The last time that I checked out the GraphOn, they only had a tiny fraction of the resolution and it was definitely a lower-end product. There is nothing wrong with that, as their price was also far less than NCD's. However, for those who can afford an NCD 19 (very roughly U.S. $3500 with XRemote plus $1000 for a good modem) it provides a superb display. As for speed, the problems occur mostly on application startup. For programming and most other tasks, the limiting factor is simply shipping ASCII characters over the phone line, and I doubt that there are significant differences in the compression technologies. Presumably Emacs runs at the same speed on any of these systems as it has little interaction with the X protocol. The worst speed problem on the NCD is in loading fonts. It often takes up to a minute to download a font, and then the font is lost as soon as the client requesting it is closed. NCD claimed that they would have general font caching implemented by now, but I haven't heard from them. The workaround is to set up your clients to use only a few standard default fonts. Also, there is a bug in the server software for displaying large bitmaps that causes the client to die, which they have known about for months and haven't fixed. But these problems have all proved relatively minor compared to the value of having a large, high-quality display (and good Unix-style keyboard). > 2. It would be trivial to implement the client side software on PCs > and GraphOn still hasn't done this. I'm waiting on buying a > Macintosh on this issue. > This is something that represents a tremendous market opportunity for GraphOn or anyone else. GraphOn could probably make much more on each copy of this software than its margin on each X terminal, as well as sell to a much larger market. The PC would be an ideal platform for a home X terminal, as it could be used for many other tasks as well. Also, its hard disk could be used to cache fonts and other downloaded information to make it much faster than limited-memory PROM solutions. An intersting question is to think about why the GraphOn protocol is apparently faster than the basic X protocol. The whole idea of the X protocol was supposed to be efficient communication to a display server! If it is better over serial lines, then it should also be good for reducing general network loads and interprocess communication. Best of all, it only needs a fixed amount of memory in the display. This gets around one of the fundamental problems with X, which is that it can fail at random (from the client's point of view) due to a lack of memory. Maybe all X terminals should adopt this solution. -- David Lowe Computer Science Dept. Univ. of British Columbia
dwl@hare.udev.cdc.com (Daren W Latham) (10/29/90)
In article <10257@ubc-cs.UUCP>, lowe@cs.ubc.ca (David Lowe) writes: |> interaction with the X protocol. The worst speed problem on the NCD is in |> loading fonts. It often takes up to a minute to download a font, and then |> the font is lost as soon as the client requesting it is closed. NCD |> claimed that they would have general font caching implemented by now, but |> I haven't heard from them. I believe that NCDs latest release (NCDware2.2) has the font caching you speak of, I'll let NCD make a formal confirmation. |> An intersting question is to think about why the GraphOn protocol is |> apparently faster than the basic X protocol. The whole idea of the X |> protocol was supposed to be efficient communication to a display server! |> If it is better over serial lines, then it should also be good for |> reducing general network loads and interprocess communication. Best of |> all, it only needs a fixed amount of memory in the display. This gets |> around one of the fundamental problems with X, which is that it can fail |> at random (from the client's point of view) due to a lack of memory. |> Maybe all X terminals should adopt this solution. I don't think this is a good idea for "all X terminals". I for one don't want to lose the independence I have by having my X server running on my terminal. With the X server local, I never have to wory about hosts going down, network interrupts, and the like. As for general memory restrictions, the NCD19 will hold up to 8 MBytes of memory. I have never run out of memory since I upgraded to 8 MBytes. -- Daren -- Daren W. Latham, ARH215 | dwl@udev.cdc.com Control Data Corporation | {uunet}!shamash!punjab!hare!dwl 4201 North Lexington Avenue | Arden Hills, MN 55126 | (612)482-3457