re desqview x on a pc and network traffic in article rkloc k picasso cssc syd tansu com au gpatapis boyd tansu com au writes in article qdeck com support qdeck com technical support writes in article qtk rn 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 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 concentrators so you have 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 with plenty of ram and a fast hard disk and network card if you have people running programs off it you re going to see some slowdowns because you re now on effectively a mhz of course dvx will attempt to see if tasks are idle and make sure they give up their time slice but if you have 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 k 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 k line is certainly going to restrict you far more than the mbps 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 xclocks quietly updating every 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 k link with more than 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 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 mb or mb 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 k 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 k 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 x screen with bits per pixel that s bits that has to be sent worst possible case you re looking at about 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 quarterdeck office systems gary rich problem resolution dept anonymous ftp site qdeck com for write to pricing ordering info info qdeck com technical questions support qdeck com quarterdeck bbs
