[kwlug-disc] SSD Drives/desktop

[unsolicited]

Darcy Casselman wrote, On 10/21/2010 7:54 PM:
> I wish I had eSATA on my laptop.  That way I could put a disk image
> file on a spinning disk and see how that compares to the XP VM I've
> got running on the SSD on the same machine.

(e)Sata should be slower. (Than SSD.) At least on reads?

PCMCIA?

Got an SD reader in it? e.g. Prices on 32GB have come way down, and on 
a couple of laptops I've seen, SD is much faster than anything over 
USB. Not sure of internal connections, think it's direct SATA not USB, 
so it may be faster than eSata, and perhaps approaching SSD. WAGing here.

> Said VM *feels* faster than the enterprise workstation class machine
> natively running Windows at work.

That's normal. Win in a VM loses a lot of extraneous hw 'crap' and it 
frequently runs faster in a vm than native. (Assuming you're not using 
hardware taxing things like SQL server or Exchange.)

> This is Windows we're talking about, after all.  It *always* swaps.
> You could give it 32GB RAM and it'll still swap to disk.

Set paging file size to 0 unless and until it complains. (It will. You 
may not care when it does.)

In Glenn's case, the win vm is dedicated to a particular application 
or two, so he may get away without a paging file.

> On Thu, Oct 21, 2010 at 7:41 PM, Lori Paniak
> <ldpaniak at fourpisolutions.com> wrote:
>> It is unlikely an SSD will increase the performance of your virtual
>> machine.  If the VM is starved for memory and is swapping, then
>> performance will be abysmal whether you have an SSD or not as the
>> virtual disk driver will be the bottleneck.
>>
>> There are a couple easy (inexpensive) things to check to increase VM
>> performance:
>>
>> 1) Is the VM running with a SATA/SCSI virtual disk?  These virtual
>> devices are much faster than legacy IDE devices.
>>
>> 2) How much RAM is assigned to the VM?  For any version of Windows, this
>> should be greater than 1GB.  More for Win 7.  Don't be afraid to give
>> the VM more RAM.
>>
>> 3) Is hardware virtualization enabled in the host BIOS?  It should be if
>> your CPU supports it.
>>
>> The best way to speed up a VM is to host it on a machine with plenty of
>> RAM and a 64-bit CPU than supports hardware virtualization.  A 64-bit
>> host OS helps too so that VMs can access as much memory as they need.
>>
>> On Thu, 2010-10-21 at 19:16 -0400, Insurance Squared Inc. wrote:
>>> My wife complains that when we run windows inside virtualbox that it's
>>> slow.  I upgraded her ram to not much effect.
>>>
>>> Does anyone have comments on upgrading to an SSD drive under linux?
>>> Looks like 64gigs are now down around $150.  Lots of chatter about boot
>>> up times, but I don't care about that.  Do they make that much
>>> difference in speed for general work?
>>>
>>> I've also read something about 'trim' which apparently linux doesn't
>>> have - should one care?

virtualbox performance under win seemed abysmal to me, I went back to 
vmware player. Performance under Linux, as in Glenn's case, was much 
better. You might try running it under the other Glenn - after 
following the other steps already mentioned by others, assuming you 
already have the class of hardware mentioned. CPU support of hardware 
virtualization, etc., etc.

virtualbox will natively use vmware player files, so if you're using 
vmware player under Linux now, you can install virtualbox, point it at 
the files, and give it a try. The reverse isn't true - but I believe 
virtualbox comes with utilities to convert a vm's files to vmware 
equivalents. I have no experience with this to know if you'll notice 
any change in speed.

In your vm when it seems slow, pop up task manager - right-click time, 
choose task manager. Go over to performance - is there memory free? 
(Perhaps remove paging file and reboot first, so you get more 
self-evident stats.) Once you've checked that out, minimize, don't 
close, task manager. A box will appear in the task bar next to the 
time - do you notice it going solid green a lot / for long periods of 
time? The former is memory bound, the latter CPU bound.