home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!news.univie.ac.at!blekul11!frmop11!dearn!esoc!rhunter
- Organisation: European Space Operation Centre (E.S.O.C)
- Date: Wednesday, 2 Sep 1992 08:30:32 CET
- From: <RHUNTER@ESOC.BITNET>
- Message-ID: <92246.083033RHUNTER@ESOC.BITNET>
- Newsgroups: comp.dcom.sys.cisco
- Subject: Re: speed capabilities of cisco terminal servers
- References: <Sep.1.22.12.11.1992.23056@athos.rutgers.edu>
- Lines: 24
-
- I don't know whether it is relevant here on the Cisco bulletin board but...
-
- I have done a fair amount of testing of XRemote over SLIP (from NCD X-terminals
- to Cisco MGS). This involved satellite as well as terrestrial (tropo-scatter)
- radio. The main outcome of this is that X-remote functions best on LOW DELAY
- rather than HIGH bandwidth. e.g. a link at 9k6 with no delay could outperform
- an error-corrected/compressed link at 19k2 with 20msec delay. Don't be misled
- by claims of 4 fold compression using v42bis. The data in X-remote is already
- heavily compressed by the X-remote satck. It is also error protected by TCP.
- The explanation for the heavy dependence on delay is that although it's running
- over TCP with a large window size, X11 has a window size of 1 higher up.
- You can run it a 2Mbit over a satellite & it will never use more than 16k.
- It is actually then better to run raw X over tcp/ip!
-
- I think the main problem you are going to have is memory hogging, rather than
- processor speed. Each user will need approx 100k once they start multi-windows
-
- I await the resulting flaming with bated breath.
-
- Ray Hunter. Comms Engineer
-
- This work was done for a previous employer: since I no longer have the pleasure
- of working for them I can't possibly speak for them!
-
-