[K12OSN] More feedback on Fedora 10 + LTSP

Wed Apr 22 01:39:36 UTC 2009

On Tue, 2009-04-21 at 15:01 -0700, Robert Arkiletian wrote:
> On Tue, Apr 21, 2009 at 1:54 PM, James P. Kinney III
> <jkinney at localnetsolutions.com> wrote:
> ...
> > Note also that CentOS kernels are by default tuned more for big
> > installation stuff than is the Fedora kernel.
> >
> > Again, I strongly suspect you are having a serious kernel issue and
> > recommend compiling your own.
> 
> I recommend against that. There are MANY settings in configuring and
> compiling a kernel. You could end up making things worse and spend a
> lot of time doing it. I think (for the most part) the default settings
> should be fine.

I mostly agree as the process is very "admin-y". It requires the kernel
builder to know what they are doing. I've built many a clunker :-) and
quite a few that didn't boot (learned about mkinitrd). The upside of
learning the process is the admin can tune a kernel to provide exactly
the needed parts and no more so that user space has all the rest of the
system resources. Granted RAM is way less expensive than it used to be
but some process wake up and poll things and that eats clock cycles.
> 
> >
> > 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.
> 
> *****If this is true, then this needs to be fixed******
> Does anyone have any evidence/experience that the virtual bridge
> causes a slowdown?

My tests were with a pre-release version and it was a synthetic network
throughput speed test. My memory of the numbers are probably pretty
close to the final results but I apparently buried the test procedure
and actual data somewhere stupid on my archive system. Grr. 

 I can recall my reason for testing was the idea that a fake interface
requires more system overhead than a raw dump to hardware. So a clock
tick to send data to bridge plus another to make the redirect point to
the physical plus a third to actually send the data. Effectively it's a
chained pipe. So a bridge theoretically should take twice the time to
exit to the NIC as a straight NIC. But I'm not 100% that's how it works.
Virtual interfaces (eth0:1) act exactly like physical ones in terms of
throughput if the real one is not passing data.
> 
> >
> > 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).
> 
> The bios should provide you with an option to turn it off. But I have
> tested HT and I get a slight benefit with ltsp.

It is certainly possible to get a performance gain with HT. It is very
system specific. As long as a kernel task can be run without being
swapped out, HT will show a speedup. Otherwise, loading a cpu task back
to either core will make the HT cpu act like a single cpu. A thrashing
situation under heavy load (2+ with large memory needs) and the process
swap begins to dominate the clock cycles.
> 
> >
> > 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)
> >
> 
> Good point. That's why I use Icewm.

Yep. Gnome is a hog and so is KDE. But when a student loads firefox, the
entire system is now ready to run gnome and it "looks" better. KDE is
lighter than gnome but still hits the same system usage on loading
firefox. My long time ago tests with xfce showed greater system usage
after loading firefox that gnome or kde after loading firefox.
> 
> -- 
> Robert Arkiletian
> Eric Hamber Secondary, Vancouver, Canada
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at 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 at 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.