| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 648.1 | Is customer using X terminals? | UNXA::PARLOCK | | Wed May 14 1997 16:04 | 2 |
|
|
| 648.2 | more info | ODIXIE::SCOTT | | Thu May 15 1997 16:51 | 6 |
| oops ... customer is using VGA / UNIX 4.0b / ALPHASERVER 400
this is the console....remote access seems ok via TELNET...
Just the local graphics access is extremely slow at launch time.
Dan
|
| 648.3 | 32 MB?? | GERUND::WOLFE | I'm going to huff, and puff, and blow your house down | Fri May 16 1997 01:26 | 14 |
| Why are we selling AlphaServer anythings with 32 MB of memory? If you
were a customer would you buy such a system? CDE is substantially
larger than XDM. While it clearly runs in such an environment its
not a pretty thing. I doubt the average customer would ever be satisfied
with CDE on such system.
>I checked out note 469, and it seems I am not the only site having this
>problem/feature/bug.
Have you compared the 5 minute login time to equivalently config'd systems?
How much memory does the customer's primary system have? I'm guessing this is
strictly a memory issue and the other system has more memory.
Pete
|
| 648.4 | small suggestions | UNXA::DERZINSKI | | Fri May 16 1997 15:36 | 34 |
| Hi,
To work around the lack of memory problem, you may, for kicks,
try defining "DTNONETWORK=TRUE" in /etc/rc.config
This may help minimize some of the networking overhead.
(It may short circuit the protocol stack traversal)
Your mileage may vary.
I would be interested to know if this made a difference.
Another trick (officially not recommended) is to comment out
the rpc.ttdbserverd entry in /etc/inetd.conf. This should not
have any noticeable effect to a standard CDE configuration.
If you notice any problems or have special appliations that
make use of rpc.ttdbserverd, you will need to turn on the
daemon again.
To do this:
Send the HUP signal to the init process to force the init
process to re-read the /etc/inetd.conf file.
kill the rpc.ttdbserverd process.
Or just reboot.
This should free the memory with the daemon and
will eliminate ttsession's talking to rpc.ttdbserverd via local
RPC. This would reduce the need for process swapping and thrashing
if that is the case.
Good luck.
John D.
|
| 648.5 | time will tell | ODIXIE::SCOTT | | Tue May 20 1997 19:08 | 11 |
| The other system is a ALPHASERVER 4100 with 512MB , so this would be
a comparison of apples and oranges. He was sold on the ALPHASERVER 400
as a failover cheapy way out. The customer has calculated that the
actual hits on the server would be well within the ballpark of the 400
and not be a concern - my opinion is : why did he buy a 4100 if the 400
can handle the load ?? I don't think I am getting the full picture.
I will try the hints in .4 , customer permitting.
thanks,
Dan
|
| 648.6 | Also check your resource files just in case | AOSG::MASINICK | Brian Masinick, DTN 381-0013 | Thu May 22 1997 14:55 | 21 |
| One other potential problem (I'm not sure whether you are seeing this
or not) is the following: the stock AlphaServers come with cheap VGA
graphics cards. We have two AlphaStation 1000 systems. Each of them
have a nice 21" color display monitor, but only a REAL BASIC VGA
graphics card (not sure of the exact name/type, but it's the STD. one).
I found that everything displays in a size MUCH larger than it does on
the same monitor with a SVGA or better graphics card. Scrolling
performance in terminal windows is painfully slow (and both of our
systems have either 256 or 512 MB, so memory is NOT a problem in our
case. If we display to another system with a good graphics card,
performance is excellent.
I found that fiddling around with the number of lines in scrolling
history and related parameters for each type of terminal emulator I run
(xterm, dxterm, dtterm) got around the problem.
Like I said, I'm not sure if this is also biting you or not, but it's
another data point to check out. I've got resource files that work
nice, should you need them.
Brian 22-MAY-1997 13:58:44
|