From: josh@cqs.washington.edu (Josh Hayes)
Subject: Mac as Xterm: summary of responses (LONG) 
Date: 17 Mar 93 17:05:57 GMT 

A little while ago I asked for information about setting up my mac
at home as an Xterminal; here is the summary I mailed out to those
who mailed me asking for a summary....

Sorry I have not summarized earlier. I did not get much information
>From the net - in fact, I got about ten posts asking me to keep 
the author posted on what I found, for every post I got from someone
who already knew something!

But the trickle of info has dried up completely, so I'll send you
what I have, which isn't much. What follows are extracts from the
mail people sent me; I'll try to provide a quick summary at the
bottom of this mail, so skip to that if you just want the punchline.

---------begin included text-----------
From: Samuel Herschbein <SAM@CHEVAX.CHEME.WASHINGTON.EDU>
Subject: MacX over serial

	MacX (any X-windowing system) is a pig and will be as slow as
molasses over a serial line.  Running it on a LocalTalk net is supposed
to be painfully slow.  We run it on Ethernet only.  If you want, you
can come over to my office and try it over Localtalk to see if its
too painfully slow.

[I have not yet visited Sam, and I feel like a real ingrate, too. -JAH]
-----

From: Michael Cummings <cummings@u.washington.edu>
>In short, what do I need to make my mac into an X terminal?

	MacX runs under the MacOS, so you don't need to be running AU/X to
emulate an X terminal.
-----

From: Chuck Delaney <cdelaney@u.washington.edu>
I can only speak from limited experience, but I'll tell you what I know.
I have run MacX on a IIx and on a IIfx.  The IIfx's response was much better;
the IIx was slow but bearable.  Both of these were Ethernet'd, communicating
with the X client over a backbone.

Software wise, MacX requires MacTCP, which should be included.  A/UX is not
required to run MacX.

I don't know much about networking protocols, but assuming you can run TCP/IP
over your 14.4K line, you should be in business.  I've heard that this is
possible, but I don't know how easy it is to set up MacTCP to talk through
something other than the Ethernet port.
-----

From: David Fetrow <fetrow@biostat.washington.edu>
 There may be better protocols than SLIP for that, but OK. For example:
NCD has a proprietary scheme that is optimized for X and their PC X server
has a local screen manager which MUCHO cuts down on the number of packets
flying back and forth. If you can get mapping of Xfonts into the fonts
available on your Mac: that's extremely helpful. It's probably standard
with the serial version of MacX.

 Suns have mediocre serial lines by the way, they usually top out around
19,200.
-----

From: Samuel Herschbein <SAM@CHEVAX.CHEME.WASHINGTON.EDU>
    When I first set up MacX, I monitored our network for traffic statistics.
It took about 100K of packets to log in and open the main window in our
MacX process simulation package.  The amount of data going over the network
is humungous (sp?).

    Translate this to modem  speeds:  100K bytes @9600 baud:  9600 baud is
about 960 characters a second (1 start bit, 8 data, 1 stop).  So it would take
a minimum of 100 seconds of ideal network xfers to open the window at 9600.

    I'm at 2400 with error correction and compression, it took over 5 minutes
to open a window that normally appears over the ethernet in about 20 secs.
When I held the mouse down on a menu item, it took about 4-5 seconds for the
packets to get to the host and back before I saw the X-window begin to respond.
It took even longer before the menu responded to the drag...

    My conclusion:  If you have the patience of a yogi or swami, it may work
tolerably at 14.4.  It will be excrutiating to wait for mouse responses.  From
my experience using our package, it would not be a workable situation:  I would
rather spend the time commuting to work than concentrating on holding the
mouse down waiting for responses...
-----

From: guy@odi.com
I am typing this using xemacs from my powerbook at home.  I'm using a
PPP link via v.32bis to my sparcstation at work.  The X server package
is eXodus, by White Pine software.  I haven't used MacX, so I can't
compare the two.  The performance is not bad.  Using Fetch, the ftp
client, I see download rates of near 3000 bytes per second.

MacPPP and the PPP faq are available at merit.edu.  You really have to
be a hacker to set up the software on both sides.
-----

From: Richard Weier <weier@twolf4.EE.WASHINGTON.EDU>
The slip version of NCSA telnet, macTCP, and MacX should be sufficient
to get an xterminal at home.

I have successfully connected a Mac running A/UX at home to a DecStation
running Ultrix using slip.  Rumor has it that the UW compute services
group will be adding slip capabilities this summer. [see below. -JAH]
-----

From: "Erik A. Johnson" <johnsone@uxh.cso.uiuc.edu>
I've done what you've suggested above, and it is quite slow.  Bearable for
simple xterm but any graphics are incredibly slow, even with a 14.4kb modem
with compression.  Hardware required is a modem.  Software:  MacSLIP, MacTCP,
MacX.

I do most of my remote work over a simple terminal-emulation/modem program
... and I get file transfers using zmodem about twice the speed as if I use
an FTP program over the SLIP/TCP/modem line.
-----

And for you people local to the UW in Seattle, here's some info
that is relevant to the question, that I got after asking the help
desk over at CAC. They write:

> Still running with 2400, but planning to upgrade to 9600 or
> 14.4K; are there any 14.4 dialups? How about 9600? What are
> the numbers?

685-7796 supports v.32 (9.6Kbps) and V.32bis (14.4Kbps).

> I am experimenting with setting up a SLIP protocol on the
> modem hooked to our network over here but being a UNIX 
> weenie it's not going particularly well...how about PPP; 
> do you support that?

Not yet.  A project has been initiated to investigate the problems of dial
IP (SLIP, CSLIP, PPP), with the goal of announcing a small, experimental
pool 2Q93. 
-----

So. There are some conflicting answers, but here's what I can sort
out so far.

1) MacX runs under the native Mac OS and does NOT require A/UX.

2) It DOES require either direct ethernet connection (or a gateway
to such, e.g. a GatorBox) or a SLIP connection over a serial line.

3) It appears to be a real dog with respect to speed. If you want
rapid response, this isn't your beastie.

4) It may be that using PPP rather than SLIP will improve the 
performance; similarly, EXodus (White Pine) may be superior to
MacX in that regard, but the sample size is far too small to know
for sure.

5) Doing everything you can to reduce X-packet number and size is
A Good Thing. This might include obtaining an optimized client-server
package: these exist for the PC side but I know of no such package
for the Mac. If you have a PC card in your mac, it may be possible
to use the existing PC packages and/or existing PC X-terminal
software (e.g. Linux), but I shudder to think what doing an emulation
on an emulation would do to your computer's psyche, let alone to its
performance. Another option is to write your own client software to
utilize non-TCP protocols; if you're a hacker you may be able to 
write clients that use, for example, a UDP stream rather than a TCP
stream. This will reduce the number of packets per unit time quite
a bit, which should improve performance.

6) It may simply not be feasible to do this right now. Modems may
be too slow, and data streams too large, to fit comfortably within
available relatively inexpensive technology. I see a need for a
package that DOES perform well within those constraints (say, using
PPP over a 9600 or 14.4 line), but it does not appear to exist at
this writing.

7) Finally, there ARE FAQ lists that address these questions, most
notably the A/UX FAQ and the comp.sys.mac.comm FAQ; both are posted
regularly in news.answers and are also available for anonymous ftp
>From rascal.ics.utexas.edu and also (I think) the sumex archive.

I hope this helps. If anyone out there has more information, it
might be nice to just send it to everyone in the address list of
this mailing - this represents all the people who wrote to me and
asked me to keep them posted.

Again, thanks for your help. We'll get that connectivity one of
these days.

Cheers,

Josh Hayes, josh@pogo.cqs.washington.edu
Center for Quantitative Sciences, HR-20
University of Washington, Seattle, WA 98195  USA

--
   Josh Hayes, Quantitative Sciences HR-20 U of Washington
    josh@pogo.cqs.washington.edu             206 543-5004
On Old Olympus' Towering Top, A Finn And German Viewed A Hop.