El vie, 18-04-2008 a las 15:52 +0200, RalfGesellensetter escribió: > Hi José, > > thank you for your comprehensive testings. > > Am Mittwoch 16 April 2008 schrieb José L. Redrejo Rodríguez: > > - There was a ¿funny? result: the Xeon machine raised its CPU use to > > 100% when Openoffice started, with the Quad Core the CPU didn't > > raise more than 20%. Because of it, when using the Xeon server some > > of the clients where stalled for several seconds when starting X. > > Anyway, the starting time was about 5" less when using the Xeon for > > the clients that didn't stall. > > Please allow me to throw in two related "issues" > > 1. On a (backports polluted) LTSP (originally based on Sarge), today > I had a 100% CPU load (quadcore!) preventing additional users from > login (KDE login hang). Reason: famd. > Restarting the fam daemon solved the problem. > (I will upgrade that machine soon, anyway. For now I did a downgrade > on fam. ) I'm not using fam nor gamin. > 2. Most heavy load is caused by Java and Flash applets (14 kids gaming > or watching youtube videos). In such moments, additional terminals > boot in slow motion (one line per second). I realised that upstream > traffic was permanent 100 MB/s which is 100%. Here, the bandwith gets > to its limit apparently. > Yes, I've already noticed this. Using 1 Gb link between the ltsp server and the switch (it's a 24 10/100 Mbits ports with 2 1 Gbps port switch) solved it. Anyway, I'm still wondering why nobody has done (or thought, or maybe thought but didn't tell it, or I just didn't look right and haven't found it) in implementing QoS between the server and the clients. That would avoid those situations, where a few clients steal all the bandwith, leaving the rest without a chance to even start up. Cheers.
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente