No Sound with Flash in Firefox

[Jim Kronebusch]

> That's not entirely true.  32-bit linux can address greater than 4GB RAM
> using PAE (Physical Address Extension).  This feature (as I understand it)
> is compiled into the linux-image-server packages on 32-bit (ed)ubuntu so
> you should be able to address the full available RAM.
> 
> http://kerneltrap.org/node/2450/7217
> 
> There is some performance penalty to using PAE, but I'd be lying if I said
> I understood the details.  A colleague of mine recently said he had used
> PAE on FreeBSD and that depending on what you're doing it can work pretty
> well.  I believe PAE has been fairly widely used in large environments.  As
> you say the cpu performance is less with emulated 32-bit, but they should
> still be pretty quick.  People have run 30-40 users with older dual single
> core xeons, though it's hard to know how that will scale up.

I read about that on some other forums.  It sure is hard to try and track down
performance comparisons for odd ball setups, so I wasn't sure what sort of hit I would
take trying to do this.  I might try a couple other tests with gnash and such on this
sort of gutsy setup and then give the 32-bit edubuntu a try.  I am just running into too
many problems with flash and java to make this usable.  I did get flash running under
64-bit firefox with K12LTSP 6 but there are just too many benefits to running Ubuntu and
LTSP5.

> If you need flash (and java, etc.) to work well, I'd be inclined to try the
> 32-bit.  I believe Java is going to be more freely distributable soon so
> maybe that issue will go away, but you might also need adobe acrobat
> reader, skype, etc.  One assumes they will release 64-bit linux versions at
> some point, but who knows when. You can run 32-bit apps in 64-bit systems
> using these tricks, but it's not a solution I'd like to roll out to 110
> users.  In fairness to the ubuntu developers, it's almost impossible for
> them to support flash at all, with no access to source and when adobe
> haven't even ported it to 64-bit yet.

I have until about mid august to have a stable solution running, which doesn't leave
enough time for Gutsy to fully develop and certainly not a 64-bit flash.  I really want
to stay away from LTSP 4.2 which leaves Ubuntu based distros as my best solution. 


> You're a brave man to do experimental stuff like this with so many users
> =-O

Bravery and desperation can easily be confused :-)

> Does it run okay once it's started?  I suppose you must have:
> 
>  - ldm runs ssh client -> server 
>  - firefox ssh runs server -> client
>  - firefox executes on client
>  - client gets firefox libs & binaries from server over nfs
>  - client executes firefox locally
>  - client gets firefox user profile over nfs
>  - client sends window data back to server over ssh
>  - server sends window data back to client over ldm ssh session

It actually runs fairly decent once started.  My test client is a 500mhz Term150 with
128mb RAM.  I have 110 brand new clients on the way with 800Mhz processors and 128MB
RAM.  Those should be powerful enough to run a few apps locally.  I am running the
modified ldm with the new DIRECTX feature turned on so that X isn't tunneled over ssh
which makes things much faster.  Firefox and flash are loaded into the /opt/ltsp/i386
root and are run by the client and sent to the server I believe in the fashion you
describe above.  

> Off the top of my head.  The startup time could be slowed down by:
> 
>  - plain old slow cpu on the client.  What's the spec?
>  - lack of RAM on the client causing network swap to be used
>  - DNS pausing issues in starting the ssh session (you could test this by
>    running ssh from command line perhaps with no X11, then with xeyes and
>    then firefox).
>  - NFS slowness serving out the binaries.  There's quite a bit you can tune
>    here -- use of NFS, changing block sizes, etc.
> 	http://nfs.sourceforge.net/nfs-howto/ar01s05.html.
>  - overhead of doubled ssh encryption.  I think it should be possible for
>    you to ssh to the client and run "export DISPLAY=localhost:0" so as not
>    to send the window back to the server.  You might have to run something
>    like "xhost +localhost" within ldm to achieve this.  This is what the "no
>    encryption" stuff does.  You could also run ssh with 
>    '-c blowfish-cbc,aes128-cbc,3des-cbc' so as to use a cheaper encryption
>    cipher (the ldm ssh session does this).

I have tried a few of the things you suggest above with the exception of the encryption
mods.  I think I really just don't know enough about this to make things work properly
and be certain it will scale the way I need it to.  I have put this on the back burner,
I already spent two full days working on it.

> The -kiosk option in ltsp-build-client installs firefox for local use.  You
> might get some clues from it as to how best to get firefox installed on the
> clients.

I have the kiosk tree installed under /opt/ltsp/kiosk for the exact reason you describe.
 I tried to pick it apart and understand how it was running, but I just can't get a
handle on it.  The difference between the speed of what I set up and the kiosk tree
might be the extra nfs mounted /home and ldap users plus the ssh tunneling.  So maybe I
do understand it but all the extra stuff is what is making it slow.  

> > I have read success stories all over on running 32-bit Firefox w/Flash under 64-bit 
> > OS, but I just can't get it to work with sound.  I hate flash.
> 
> The difference is they aren't using thin clients.  Until recently flash
> didn't work with sound on thin clients, period.  Only the most recent flash
> plugin with extra pulseaudio support added by the revolutionlinux guys
> solved this.
> 	http://pulseaudio.revolutionlinux.com/PulseAudio

I talked to Gideon Romm about this a little at our Linux conference in Minneapolis last
month, that is when I got the modified ldm from him.  I just have too many on the edge
things going on between 64-bit and LTSP 5 with so many clients to try and get anything
real stable.
 
> I'm not saying that can't work, but I really don't like the sound of it.
> Firefox is I suspect, the _key_ application in most school environments.
> Running it in such a hackish way is probably asking for trouble.  By the
> time you spend all those extra cpu cycles on ssh tunnelling 60 firefox
> sessions from 32-bit to 64-bit machine and then down to the clients, as
> well as sending the sound direct to the client (I'd try and short-cut the
> sound using the environment variable), I'd say your performance might well
> be lower than using PAE and 32-bit ubuntu.  You'll also need a lot of RAM
> on the secondary server if it's going to run firefox for 80 users at a time
> (firefox is one of the big RAM hogs that makes the main server need all
> that RAM in the first place).  If you ran both 32-bit, you might be able to
> use the spare machine to load balance with the main one.
> 
> I hope some of this is helpful and what way you go is of course entirely up
> to you.  These are just my instincts were I in your situation.
> 
> Good luck and let us know how you get on, this is all very interesting
> stuff for the list,

Yeah, firefox with a working flash and java are very important, especially if I want
Linux to look like it is an improvement over our old OSX labs.  My last resort will
probably be the CentOS 5 based K12LTSP, but I am really going to work and try to get the
best Ubuntu based solution I can.

You have been a great help and I hope this discussion helps others in some way.  You
have sold me on testing the 32-bit Edubuntu with PAE, I might start that this afternoon
or on Monday.  I will definitely post my results back to the list.  If it works then my
only hurdle left would be getting Student Control Panel to actually work (x11vnc is
driving my crazy).  I sure wish I had a good way to test usage before waiting for
students to arrive.  But that is the exiting part :-)

-- 
This message has been scanned for viruses and
dangerous content by the Cotter Technology 
Department, and is believed to be clean.