[THIN] Re: OT: Effect of Solid State drives
- From: "Timothy R. Mangan" <tmangan@xxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Thu, 7 Jun 2007 13:30:29 -0400
If you add Virtual Machines to this line of thinking, then one might
conclude that there should be a market for "special-purpose" Oss. Specially
built minimal bloat OS that supports the application needed. Linux
Appliances are the closest to this idea today, except of course Linux is
also a general purpose OS. I think all that is needed is the compelling VM
application that wants the benefits (smaller footprint and more secure) of a
small custom OS.
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Braebaum, Neil
Sent: Thursday, June 07, 2007 1:01 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: OT: Effect of Solid State drives
Well you can set the OS not to use a pagefile - but that has it's
downsides, too.
What you *can't* change, though, is it's *nature*.
Older OSs only used vm when required (ie running out of RAM) modern OSs
behave differently. Water is wet, grass is green ;-)
There are some fundamental differences (as much to do with the reason,
as the mechanics) between swapping and paging - even if from a high
level they may appear the same.
In the days of mainframes, you would (likely) tune them to their
activities - and often, such tuning would have a degree of scheduling,
based on the workmix required. As an example, many mainframes ran 24x7,
during day / office hours, may have provided a fair degree of support to
terminals and sessions. Now they frequently had front-end processors to
deal with some of that, but often a fair degree of "tuning" was done to
provide responsiveness to that sort of activity.
Outside of working hours, that workmix or demand may change more towards
batch processing or heavy database processing, and printing. And you'd
often see scheduled workmix changes, reconfiguring or tuning the OS to
more suitably support that activity.
When UNIX and small / mid-range systems became prevalent, there was less
demand for this sort of thing - computing became more "distributed",
machines were smaller, and often servers would do a reasonably specific
type of activity - and were tuned accordingly. In those days, I spent a
reasonable amount of time, tuning the OS / kernel to support the type of
activity the machine was dedicated to - ie perhaps front-end /
client-side processing, or back-end database serving type machines.
Even then, though, there was a certain degree of general purpose-ness to
the OS usage, and I did write and implement stuff that kinda altered
"workmix" type tuning, based on time-of-day.
Fast forward, now, to current servers running on Windows OSs (and note
I'm not ignoring other modern OSs, merely that Windows is what we're
discussing). You don't have anything like the same degree of OS tuning
readily available or encouraged. And there's been a paradigm shift in
application development - more likely Windows development, than the
system programming you'd get with older operating systems.
So you have general purpose OSs providing workhorse type roles, some
marginal and general tuning to support the type or role that the server
provides, and nothing like the same degree of technical involvement -
both in configuration and systems programming that were evident in OSs
of yester-yore.
None of that's a criticism, just a general take on the history and
implications of how OSs have evolved.
Neil
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Greenberg
> Sent: 07 June 2007 17:50
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: OT: Effect of Solid State drives
>
>
> That begs the question if perhaps can actually setup WIN2K3
> to run purely from RAM and speed up all that caching and
> thrashing stuff!!
>
> Steve Greenberg
> Thin Client Computing
> 34522 N. Scottsdale Rd D8453
> Scottsdale, AZ 85262
> (602) 432-8649
> www.thinclient.net
> steveg@xxxxxxxxxxxxxx
>
>
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Braebaum, Neil
> Sent: Thursday, June 07, 2007 9:31 AM
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: OT: Effect of Solid State drives
>
> > -----Original Message-----
> > From: thin-bounce@xxxxxxxxxxxxx
> > [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Greenberg
> > Sent: 07 June 2007 17:26
> > To: thin@xxxxxxxxxxxxx
> > Subject: [THIN] Re: OT: Effect of Solid State drives
> >
> >
> >
> > Aside from the OS support part, haven't we done this
> already with RAID
> > controllers that have blocks of RAM on them? It always impresses me
> > how much faster these controllers are then ones without RAM. Taking
> > that solid state portion up to multiple gigabytes certainly
> would make
> > a huge difference for disk bottlenecks.
> >
> > BTW- Why does Windows still depend so much on the hard
> drive when we
> > are so much RAM available?? Tim, I think this question is for you J
>
> Well I'll have a go at answering it - I would speculate,
> largely, that it's because from the design stage it is a
> multi-purpose OS, that as well as providing or catering for
> different types of workmix, always
> *attempts* to be responsive for new processes. Hence, the
> pre-emptive paging.
>
> This was a reasonable change from OSs that only ever used
> virtual memory when they'd run out of physical memory.
>
> And it's (the OS) nature is such that it's not lent towards
> performance customisation. By that I mean that in older
> times, when OSs were more bespokely tuned to eek out the best
> performance, this required a reasonable degree of expertise
> and knowledge. Whilst there may be some tweaks and settings
> that can be applied to Windows servers, these days, it's
> fundamental nature and behaviour is general purpose.
>
> Neil
>
>
>
> **************************************************************
> **************
> *
>
> This email and its attachments are confidential and are
> intended for the above named recipient only. If this has come
> to you in error, please notify the sender immediately and
> delete this email from your system. You must take no action
> based on this, nor must you copy or disclose it or any part
> of its contents to any person or organisation. Statements and
> opinions contained in this email may not necessarily
> represent those of Littlewoods Shop Direct Group Limited or
> its subsidiaries. Please note that email communications may
> be monitored. The registered office of Littlewoods Shop
> Direct Group Limited is 1st Floor, Skyways House, Speke Road,
> Speke, Liverpool, L70 1AB, registered number 5059352
>
> **************************************************************
> **************
> *
>
>
>
>
> This message has been scanned for viruses by BlackSpider
> MailControl - www.blackspider.com SBC SITES ONLY GOOGLE
> SEARCH: http://www.F1U.com
> ************************************************
> For Archives, RSS, to Unsubscribe, Subscribe or set Digest or
> Vacation mode use the below link:
> //www.freelists.org/list/thin
> ************************************************
>
> SBC SITES ONLY GOOGLE SEARCH: http://www.F1U.com
> ************************************************
> For Archives, RSS, to Unsubscribe, Subscribe or set Digest or
> Vacation mode use the below link:
> //www.freelists.org/list/thin
> ************************************************
>
SBC SITES ONLY GOOGLE SEARCH: http://www.F1U.com
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
//www.freelists.org/list/thin
************************************************
SBC SITES ONLY GOOGLE SEARCH: http://www.F1U.com
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
//www.freelists.org/list/thin
************************************************
Other related posts:
