Re: TCO and users/box


"Michael Heiming" <michael+USENET@xxxxxxxxxxxxxx> wrote in message
news:f32pd3-a3o.ln1@xxxxxxxxxxxxxxxxxx
In comp.os.linux.hardware sinister <sinister@xxxxxxxxxxxxxx>:
Is there any concensus regarding the TCO of the "one user/box" model and
a
"many users/box with thin clients" model?

I work at a scientific institute; we do scientific computation, some
reasonably intense. We have an aging Sun v1280 server (chips are
900MHz),
and people in a position to make decisions or to give advice agree that
we
should move to Linux in the medium/long run.

My own bias is to use fewer boxes, with more than one user/box, and
perhaps
more than one CPU/box.

Any thoughts on the economics?

I just checked the server; we have 47 people on.

Unsure what those users are doing at all on the systems? You

Right now, they're just logged on.

might want to look into LTSP (www.ltsp.org) 47 people should be
easily hand able for desktop purposes from a single halfway
reasonable server. If you do much CPU intensive tasks, you might
want another box that runs those tasks, or if thin clients are
strong enough, just run those tasks locally.

Thin clients aren't able---either real dinosaur Suns, or PCs running VNC.

Of course you need to restrict users to reasonable resource
limits, so one can't hog a multi user server, which sounds like a
problem on your recent box. Some not probably setup Linux system
will not help you an inch, users will hog all CPU(s) + RAM if you
let them no matter how big/fast a system is. Same is true for the
solaris box.

Right, but is there any way to put a quota on RAM (really, virtual memory)
use? (CPU hogging hasn't been as much of a problem. When virtual memory
runs out, jobs crash---I even saw cases where they didn't crash but gave
erroneous results.)

Though most of the problem seemed to be that the jobs run for awhile, then
finish, but don't free up their memory. IMHO the easiest way to deal with
that would be to write an intelligent script that looks for jobs that appear
to be finished (sitting idle for a long time), and then starts terminiating
them when VM runs down.

Thanks for your input.

Good luck

[..]


--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@xxxxxxxxxx | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 356: the daemons! the daemons! the terrible
daemons!


.

Relevant Pages

  • Re: thin clients on SBS2003 ?
    ... Even with the ease of SBS features. ... > sbs server. ... > thin clients all connect back to a Terminal Server farm in the HQ ... >> sessions. ...
    (microsoft.public.windows.server.sbs)
  • Re: SBS Network Design Inquiry
    ... application sharing mode and thin clients. ... So $1,500 for a starter second server, $1,000 for the operating ... SBS is to serve files and email. ... computers on a wireless LAN. ...
    (microsoft.public.windows.server.sbs)
  • Re: Terminal Services - Why?
    ... against a change from PCs to thin clients. ... If the server crashes, everyone gets thrown off ... point (numbers of thin clients) does TS become more cost-effective? ... I'd have guessed at 20+ as long as you can afford your own Citrix/TS ...
    (microsoft.public.windows.terminal_services)
  • Group policy
    ... I am a extreme newbie with thin clients and also AD so please be patient ... reasonable (although I would still prefer Application server mode ... Remote Admin mode is by default only available to Administrators. ... 231287 - Loopback Processing of Group Policy ...
    (microsoft.public.windows.terminal_services)