[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] More feedback on Fedora 10 + LTSP



On Wed, 2009-04-22 at 08:48 -0400, David Hopkins wrote:
> On Tue, Apr 21, 2009 at 4:54 PM, James P. Kinney III
> <jkinney localnetsolutions com> wrote:
> > The KERNEL is radically different, however. The CentOS version has a
> > totally different scheduler than the F10 version. Plus a bazillion other
> > changes that have a huge effect on LTSP kernel usage. Due to sound
> > changes, it may be challenge to get the CentOS kernel src.rpm and
> > compile it for the F10 OS environment but it is certainly worth a try.
> 
> I would probably lose what hair I have left if I tried this right now.
>  I have 'spare' 8 processor and dual processor Dell servers that the
> state was throwing away that I can learn on for this but that won't be
> till summer (it is amazing what is sometimes considered obsolete).

Cheat! Get the kernel src.rpm from the CentOS updates collection for 5.3
and just rpmbuild -ba the thing. I'm not 100% but I think it will
compile fine on an F10 system. Install and reboot.
> 
> > Note also that CentOS kernels are by default tuned more for big
> > installation stuff than is the Fedora kernel.
> 
> yep, there is a reason that CentOS/RHEL exists.  I would prefer to
> stay with CentOS but I have to resolve sound (talk about beating a
> dead horse issue) and with LTSP5 I have to admit that sound 'just
> works' in all the apps I have to have (except for Audacity but I've
> found some documentation that implies it can be made to work).

Load up the EPEL repo and install pulsaudio. That will let flash sound
work again with flash > v9 . That change clobbered everybody.

> >
> > Again, I strongly suspect you are having a serious kernel issue and
> > recommend compiling your own.
> 
> It is possible that this is the case. I do know that I have to run
> mkinitrd to get the kernel to boot properly since I have an Adaptec
> 2010s controller. (I20 block device).  There is an outstanding bug wrt
> this raid card which will hopefully be resolved 'soon'.  I have to
> manually apply a patch/fix.  I'll look at how mkinitrd really works
> and see if that patch to make the raid card work isn't causing an
> issue. However, I've tested disk I/O and I don't see any issues with
> throughput.
> 
> > The bridge interface is also a serious slowdown hog. It doesn't seem to
> > support gigabit traffic at all. More like 230-400 Mbps. So the idea of
> > ditching the bridge and going straight, physical nic is the best,
> > fastest route to a speed up. Dig on the Brandon elementary pta site for
> > a write up by William Fragakis on how to turn of the bridge process.
> 
> I'll look for the notes on how to do this.  The teacher's lesson plan
> for the next few sessions involves using OpenOffice/StarOffice and
> this works without any issues so I can flip the prior server back into
> service if I break anything.  That gives me a weekend in the worst
> case to rebuild from scratch.  I'll also say that I've tested
> throughput on the external network-facing NIC and it is what I would
> expect (it is the same as my systems using CentOS).  I have tested the
> bridge though.
> 
> > Lastly: you mentioned hyperthreading cpu's. If they are _really_
> > hyperthreaded and not full multi-core, turn _off_ the hyperthreading.
> > The F10 kernel threading will thrash royally doing stupid task swapping
> > as it seems to not understand that the second cpu is a fake one. There
> > is a kernel /proc flag to help this but I can't find it right now
> > (again).
> 
> They are hyperthreaded Xeons.  They have performed very well until
> recently. Though, how would I detect thrashing?

A thumbnail check is to run top with details on the processors on (press
"1" to see details on each cpu). If you see the load swapping from one
to another cpu, you are looking at a poor performer. However to really
get the details you need to run sysstat tools. psact will help to trace
how things are being used within the system. But it takes some work to
grok it all.  
> 
> > Also be sure to turn off EVERY process not actively used. Some are more
> > of a drain on cpu throughput (avahi, a zillion python applets running
> > desktop applets for notification - system monitor should be removed!! so
> > students won't load it up - it's a HOG)
> 
> I've chkconfig'ed to off everything I thought I could but I'll recheck
> since I know I didn't turn off avahi.  Is there a list of essential
> services somewhere?  Things like bluetooth and the like I know I don't
> need on a production system but a nice list would be wonderful.

That is very system dependent. Are you running NFSv4? They you need the
myriad of rpc* daemons. If only v3, then the *gssd and rpcidmapd can be
offed.
> 
> Sincerely,
> Dave Hopkins
> Newark Charter School
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN redhat com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
> 
-- 
James P. Kinney III          
CEO & Director of Engineering 
Local Net Solutions,LLC                           
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney localnetsolutions com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]