Hi,
On Wed, 15 Aug 2007, Philipp Hanselmann wrote:
> I tried that (LDM_DIRECTX=True), but I am not sure if is really working
> under Feisty:
>
> On a thin client I noticed that ssh is still running with encryption!
>
> # ps aux | grep ssh
> ssh -v -c blowfish-cbc,aes128-cbc,3des-cbc -M -S /tmp/.ltspfs-socket user11 at 192.168.0.254 /bin/bash --login -c ' env LTSP_CLIENT="demo" PULSE_SERVER=tcp:192.168.0.244:4713 ESPEAKER=192.168.0.244:16001 DISPLAY=192.168.0.244:6 /etc/X11/Xsession && ltspfsmounter all cleanup ' ; kill -1 $PPID
ssh will be using encryption, as it should. However, the X conversation
will be had in the clear. You can verify this by typing:
echo $DISPLAY
in a session on a thin client. If the X data is being encrypted, you'll
get an answer like "localhost:12.0", whereas if LDM_DIRECTX is working
you'll get "192.168.0.244:6" or whatever's in the "DISPLAY=" above.
> Independently, to bypass the encryption, I tried to active XDMCP like this:
I would suggest going back and making LDM_DIRECTX work. It will, for
example, stop people from sniffing logins passwords off the wire which
XDMCP allows. It's also better tested and more commonly used. Once you
are no longer encrypting X traffic, the load caused by the ssh session will
be minimal.
> SchoolNet has about 300 customers with a thin client solutions provided
> from us. All this costumers have between 5 to 20 clients (400 MHz, 96-
> 128 MB) connected on a server (Pentium 4, 3GHz, 2 - 4 Gbyte). The
> testing which we have done up to know with Edubuntu Feisty, shows that
> with our actual hardware (Pentium 4,3GHz, 2 - 4 Gbyte) , Edubuntu Feisty
> can't support not more than 10 thin clients.
You need to establish what bottleneck you're hitting here. It could be:
- running out of RAM (and then swapping)
- disk access bottlenecks
- cpu overload (ssh encryption could contribute to this)
If you have a Pentium 4, this may not be server hardware which means the
machine and in particular the disks may be desktop-oriented IDE or S-ATA.
Disk access might very well be a bottleneck in this configuration.
> I assume we can reach again 20 thin clients, if the encryption is
> switched off! Like our server is protected by a firewall (Shorewall) we
> don't need the encryption!
When you say "reach again 20 thin clients", you apparently had 20 before?
What sort of setup was this? Were you using edubuntu dapper or K12LTSP or
something else?
You can't assume LDM_DIRECTX will fix the problem unless you know X
encryption is the problem but you can try it out of course. You need to
find out more directly what the problem is.
Try looking at performance monitoring tools to diagnose what is slowing the
machine down. You can start off by
1. Looking at "top". Are there rogue processes using up the CPU? There's
only one CPU so it doesn't take much to cause problems. You can press
'M' to sort processes by memory usage.
2. Looking at the load average
gavinmc at boing:~$ uptime
09:08:45 up 11 days, 19:43, 2 users, load average: 0.21, 0.21, 0.08
3. Looking at the output of free
gavinmc at boing:~$ free
total used free shared buffers cached
Mem: 2059656 2014164 45492 0 383708 1053664
-/+ buffers/cache: 576792 1482864
Swap: 1951888 548 1951340
paying particular attention to the amount of swap used (548 in this
case). If that's large, you're running out of memory and swapping.
4. Set up a proper monitoring tool like munin to get more detailed
information on your system performance.
http://www.debianadmin.com/monitor-servers-and-clients-using-munin-in-ubuntu.html
> In our actual solution (getopenlab) we using a KDE desktop, so I think
> Gnome should have a slightly better performance! I hope I am note forced
> to implement a other light weight desktop, like XFCE for example.
I don't think GNOME is known to be any lighter than KDE. Probably the
opposite in fact. If you're really running out of RAM (which seems
unlikely with 10 people), it's possible GNOME is a contributor.
It's possible you're uncovering some bug here which could be fixed.
Gavin