In article <1rkloc$k49@picasso.cssc-syd.tansu.com.au> gpatapis@boyd.tansu.com.au writes: > >In article 1369@qdeck.com, support@qdeck.com (Technical Support) writes: >>In article <1qtk84$rn5@picasso.cssc-syd.tansu.com.au> gpatapis@boyd.tansu.com.au writes: >> >>>What sort of traffic is generated with the X-calls?  I am curious to find >>>out the required bandwidth that a link must have  if one machine running >>>DV/X is supporting multiple users (clients) and we require adequate response >>>time.  Anyone have any ideas ??   >> >>I expect the limiting factor will be your server machine, not the network >>itself. To give you a real-world example, here at Quarterdeck we have >>roughly 100 people using DVX to talk to a bunch of unix boxes, novell >>file servers, and each other. It's not _too_ much of a load on our >>Ethernet (with maybe 4 concentrators, so you have 20-30 people on each >>segment). If you had a badly loaded net, or the apps you wanted to run >>were very network intensive, you could run into some slowdowns. >> >>But the biggest problem would be the machine itself. Say you have a 486 >>33 with plenty of ram and a fast hard disk and network card. If you have >>10 people running programs off it, you're going to see some slowdowns >>because you're now on (effectively) a 3.3 MHz 486. Of course, DVX will >>attempt to see if tasks are idle and make sure they give up their time >>slice, but if you have 10 working programs running, you'll know it. >> > >Well I can buy a bigger and more powerful server machine because of the  >significant drop in price year after year.  The link I want to use  >though (ISDN 64K) is costly and the bandwidth limited.  That's why my >interest lies in seeing if such a link can be used and see what traffic  >goes through it.  Since I don't think Tom always gets time to read this group, I'll take the liberty of responding to some of this.  If you really want Tom to reply you should send mail to support@qdeck.com.  A 64k line is certainly going to restrict you far more than the 10mbps ethernet that we typically run.  How restrictive it will be depends on  what you run and how you run it.  I would think that a couple of instances of some really nasty program like "Smoking Clover" would make the link  useless for anyone else.  On the other hand, probably 50 xclocks quietly updating every 10 seconds or so wouldn't impact it too much.  In the real world, you will be somewhere in between these two extremes.  Going by the way I personally use X on a daily basis, I wouldn't want to have to share that 64k link with more than 3-4 other people.  >>Having said that, if you can tweak the programs being run (by adding >>in calls to give up time slices when idle and that sort of >>thing), you could probably run 15-20 people on a given machine before >>you started seeing slowdowns again (this time from network bandwidth). > >Hmmm.  Has anyone at your centre monitored the traffic at all?  Are you >running any standard MS-Windows programs like Word ?  What sort of  >packets go blazing through? What size link do you have (2Mb or 10Mb ?). >What is the average traffic flow going through your network or do you >have few high peaks and then many low points?  Our corporate WAN is as unique as any other.  The usage patterns are not very good predictors of how yours will behave.  The only one of our low bandwidth links that normally get used in this way is a 56k link to Ireland that they often use to run a DOS text based client end of a client-server database  remotely from the DVX machine behind me. Since the server end is (or was) always at this end (California) it is faster to remotely run the client via DESQview X and have a short hop to the server than running the client locally and having a long hop to the server.  As I warned you, this tells us very little about how you usage pattern will fill a 64k ISDN link.  Running Word for Windows remotely is going to itself be very usage dependent. Let's break it into pieces and look at it.  Tracking the mouse pointer is easy and efficient to translate from Windows calls into X. Popping up a menu is a little more involved and will generate some traffic.  Restoring the screen that was covered by that menu may be easy and may not be.  Does the server that it's displaying on have backing store?  If so and the server had enough memory the display can be updated locally and will generate little network traffic. If no backing store, then what was being covered up?  If it was a  solid colored rectangle of space we can tell your xserver to draw that quite easily.  If it was a full color backdrop of Ren & Stimpy we may have to send it back to the X server bit by bit.  DVX will do its level best to only redraw that small area, but in some unusual cases the entire screen may need to be  repainted.  Assuning a 1024x768 screen with 4 bits per pixel that's 3145728 bits that has to be sent.  Worst possible case you're looking at about 50 seconds. In reality it would never be this bad since the screen will always have parts  that will be tranlatable into higher level X calls.  > > >>It all really depends on what the programs are doing (ie. you're going >>to see a slowdown from X-bandwidth a lot sooner if your apps are all >>doing network things also...) >>--  > >What do you mean by network things?  I vision using MS Windows and other >Windows applications over the network were the processes are running on >the server and all I am getting are the displays.  I am wondering how  >good is the X and subsequently DV/X protocol in transferring these  >images with X-calls and displaying them on a client's machine.  X was designed from the ground up to be efficient across a network.  It's  pretty good for this.  X programs are best, DOS text programs are almost as good (since we conert them to X easily).  Something like WinX is a hybrid. We intercept the calls Windows makes to it's graphics driver/ mouse driver keyboard driver and convert them to X.  The calls Windows is making are in no way designed to be efficient on a packet switched network.  We go to a  lot of trouble to convert them to the highes level Xlib calls we can, but we are somewhat limited because we only know what Windows and its applications tell us.