From: kanakis@hsi.com (Tony Kanakis)
Subject: Re: Maximize For Remote Use of DVX display on X-terms
Organization: 3M Health Information Systems, Wallingford CT
Date: Wed, 12 Aug 1992 13:10:11 GMT

In article <1992Aug11.000449.23191@qdeck.com> docw@qdeck.com (Doc Williamson) writes:
>you say>My own best guess would be a faster pc.  We are using a Unisys 366/16 SX.you say>I would imagine a 486/50 DX would improve performance greatly
>
>Frankly that's about the best advice I could give too.
>In terms of speed and number of windows you've got this Unisys 386/16 
>configured about as well as you can (there are faster and smaller caches
>than smartdrv, and you probably could live without share f you don't run
>multiple copies of single programs) (fat chance of that, right?) :-)

Right!

>But when you consider that 6 windows plus the four basic processes under
>DVX is 10 processes running on a 386/16, and that's taxing it to the limit
>as far as I'm concerned.  (Not that this math is exactly valid, but just
>consider that 16mHz/10 = 1.6 mHz).  
>We here in QOS support use my machine as a "process server" (of sorts)
>and I typically have 4 - 6 users rsh'ing from it, while I myself have another 
>6 or 8 windows open , though only one window .actually doing much of anything
>and the support processes of server, window manager, net manager and DV pretty
>busy.  This gives fairly acceptable performanbce for all concerned acceptable performanbce for all concerned.  The remote users are running 386/20s while mine
>(the "process server" ) is a 486/33.
>

That's great but you sound like your using communicating btw all desqview
machines.  Won't communicating btw a DVX machine and a Xterminal be slower?
 
>This is the kind of configuration that could make DV/X a major success in 
>the DOS world, since all of the 386/20s are undersupplied with RAM and
>processing cycles to accomplish this , yet at a much lower cost than 
>providing all these users with 486s.  
>
>However, using a 386/16 to service several users is asking a LOT of a modest
>machine.  The fact that you ARE DOING THIS speaks well of both you and DVX.
>
>-- Doc Williamson <support@qdeck.com>
>

Thanks for complement and right back at you.  However there is on last question I'd like to ask.

I was locking up the system when trying to login to a netware server after
loading DVX.

If I login before DVX is called it will wait til I run 'map' a few times and 
then hang.

Any comments on how I can communicate to my netware server with DVX on a
Xterm?   I've this explanation but I don't think it's the answer I was looking
for.  I may have asked the question wrong but here is the response.

In article <BsMnKF.4Gt@hsi.com> kanakis@hsi.com (Tony Kanakis) writes:
>
>
>I'm sure there is a reason but why can't  DVX allow TCP/IP and IPX to both
>run at the same time?   Lan Workplace allows for both.
>
>======= 3M Health Information Systems                kanakis@hsi.com =======
>======= Wallingford, Connecticut  06492                 203 949-6355 =======
>

DV/X network manager has to "build" a Berkely socket interface for inside
of DVX even with IPX which does not know from UCB.  While the TCPIP network
manager talks Berkely straight to the TCPIP layer.  Resolving whether
to build or not to build based on a particular socket and decoding on the
recieving end, sounds like a nightmare to me. (I don't write them - only
support them.)  The IPX layer on the LWP is only needed to talk to the Novell
server and DVX is not too interested in that (at a networking level).  If
your IPX boxes are getting it from LWP they can all talk to EACH OTHER by
TCPIP.  It is superior to IPX for remote computing.  The problem is that
we are using IPX to do something it was not really intended to do, and this
hampers our ability to make it do ALL the stuff a well rounded remote
computing environment like TCPIP can do.


Bill     burge@qdeck.com

Thanks,
-- 
======= Tony Kanakis                        {uunet,yale}!hsi!kanakis =======
======= 3M Health Information Systems                kanakis@hsi.com =======
======= Wallingford, Connecticut  06492                 203 949-6355 =======

Newsgroups: comp.os.msdos.desqview