That might be OK if People didn't run so much different Stuff on the Clients. The Gnome/KDE factor would be a major part of that.
I bet if people ran WM < ask Scott Balneaves> There would be none of these issues. mslicker wrote: > Honestly, > > We need a scaling algorythm to calculate CPU power, RAM, HD > performance, > and HD size requirements per number of workstations just running X on the > clients and StarOffice/Netscape on the server. > > Any mathematicians out there? This one is likely not so complex. > Unfortunately, I am very bad at math. > > let c = Mhz of Athlon CPU of Server > let p = initial Mhz used including first client instance > let q = Mhz used by one client instance > let m = MB of RAM on Server > let r = rpms of disks on disk array > let s = number of disks striped on array > let n = number of X clients > let i = initial MB of RAM usage of RAM including first user instance > let u = MB of RAM usage by one user instance > let d = Mhz of CPU degredation per MB of swap disk space required > > Therefore: > let D = (r*s) general performance of disk R/W access > let M = m-i+((n-1)*u) total memory usage in MB > let C = c-p+((n-1)*q) Total CPU usage discounting swap file effect > > if M < m then C = C - (M*d) > > In the end, C gives us how much CPU is left on the server. > > Of course, I did not calculate system bus performance or memory > performance. > And some of these values will have to be averages. Obviously, getting > those > numbers will take a scientific experiment requiring lab facilities--but it > would be fun. Are there any other noticeable errors in the algorythm > above? > If we have these numbers, it would be simple enough to make a web-based > calculation utility for estimation of hardware requirements. The system > hardware would be subjective, being based on the system used as a server > in > the experiment and it also would not take into effect other overhead used > in > the case of Beowolf clusters, but nonetheless it would give a practical, > working level of knowledge for future deployment planning purposes. We > readilly know the rough differences of performance characteristics between > CPU types and memory types. Perhaps only system bus performance could > make a > difference unpredictable enough that it should be added into the > algorythm. > > --Matthew > > > > On Mon, 21 Jan 2002, Julius Szelagiewicz wrote: > > >>Juan Carlos, >> how is the load with 60? how much memory do you have in the >>server, how many processors, how fast? the real load now will tell you how >>much more memory / power you'll need for additional 140. good rule is to >>max out on memory in the server and to put multiple servers when you run >>out of steam. good luck, julius >> >>On Mon, 21 Jan 2002, Juan Carlos Zarta Escobar wrote: >> >> >>>Hello again >>> >>>There is my history >>> >>>In my company we start with 15 ws working with ltsp, this ammount its now >>>60 workstation, but now the company need to work about 200 ws, each one >>>launchin netscape 4.7x in KDE2, Im not sure about the capacity of LTSP >>>you can help me please I want an answer for my company befor two weeks, >>>there is my actual network >>> >>> >>> ------------------- --------------------- >>> | applications | | LTSP | >>> | server | | Server | >>> | ip 192.168.0.41 | | ip 192.168.0.254 | >>> -------------------- --------------------- >>> | | >>> | | >>> =========================================== >>> | >>> | >>> | >>> --------------------------------- >>> | ws 01 -200 | >>> | ip 192.168.0.1 / 253 (not 41) | >>> --------------------------------- >>> >>>How can i do this ?? how many servers with LTSP i need ?? please help me >>>, >>> >>>PD THANKS FOR YOUR HELP AND EXCUSE MY ENGLISH !! >>> >>>_____________________________________________________________________ >>>Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: >>> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss >>>For additional LTSP help, try #ltsp channel on irc.openprojects.net >>> >>> >> >>_____________________________________________________________________ >>Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: >> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss >>For additional LTSP help, try #ltsp channel on irc.openprojects.net >> >> > > > _____________________________________________________________________ > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > For additional LTSP help, try #ltsp channel on irc.openprojects.net > > > -- Michael H. Collins http://www.linuxlink.com Linux Streaming Radio http://www.kpig.com Penguins are so sensitive. Lyle Lovett
wm
Description: Binary data
