Showing posts with label computers. Show all posts
Showing posts with label computers. Show all posts

Friday, January 21, 2011

Questions and issues with Home systems using RAID

I bought a new home computer a few months ago. For the past few weeks I was trying to set up a RAID-1 array at home and ran into a bunch of issues and questions. The Motherboard is an ASUS M4A88TD-V which has a RAID support on the motherboard via a SB850 chipset.


  • There is no way to create a RAID volume from an existing disk. You have to create a new volume from scratch and re-image.

  • There seem to be a need to special drivers. When I boot up Linux with the RAID volume defined it still shows 2 disks!

  • Does the controller (or controlling software) verifies the write? If it doesn't and an error is discovered at read time it is too late.

  • If you have a corrupted file due to a software glitch for example you still need a backup. Otherwise you have a mirror of corrupted files.

  • If the motherboard dies can we take the disks and boot up from another computer with potentially a different chipset - RAID or regular?



Due to the above questions and issues I ended up using the secondary disk for backups.

Monday, March 29, 2010

invalid license data. reinstall is required

I have Vista 64 SP2 and Visual Studio 2008 SP1. Monday morning I got this error message when I try to start Visual Studio. MSDN recommends reinstalling Visual Studio.

Luckily the technical support guy reminded to reboot the computer first. The problem goes away.

Tuesday, October 23, 2007

Another weird problem

This time it is in our development environment. We are integrating with an external report engine and one of my tasks is to look at some performance statistics to see if we need extra hardware to support the report services. The reporting engine is still a 32-bit process so I wrote a bit of code to thunk down from our 64-bit .Net code to 32-bit before calling the reporting service.

After that I hook up our test/performance harness to make the system run 100 reports. That CPU was under siege for well over 10 minutes. After same tuning and monitoring I realized the CPU was not spent in the reporting process (nor our application services for that matter), it was the 64-bit version of rundll32.exe. Out comes the Sysinternals Process viewer. It turns out rundll32 was running:

rundll32.exe ntprint.dll "printer name"

The process is trying to install a printer. I tried it manually and we don't have the printer driver locally. So I guess this process failed repeatedly but kept trying. I looked up some documentation and found the option to turn off the printing portion of the report and everything works like charm. Just another day in the office...

Tuesday, September 18, 2007

Network problem

Ever since late July I have been involved to diagnose a performance problem. After a few weeks of back and forth, dicing through the numbers and adding instrumentation to our code, it boils down to network delays in our .Net remoting calls. At that point I should have throw my hands up and pass the problem to the Network engineers. Unfortunately that person was on vacation and I need to carry on. After a bunch of trials and errors and flipping around options on the network driver level, the problem seems to be related to SNP/TOE. So next time you see a network slowdown, check if SNP/TOE is turned on.

Thursday, September 06, 2007

it might be obvious for others

This is definitely not obvious for me.

I did some performance tuning for our web app and cached some pages a while back. I did this:

<%@ OutputCache Location="Any" Duration="3600" VaryByParam="none"%>

I was going through the IIS logs as see that the page in question is still being requested a lot. Changing it to

<%@ OutputCache Location="Any" Duration="3600" VaryByParam="None"%>

does the trick. It seems implicit and I have definitely seen other people using the lower case version. But the attribute is CASE-SENSITIVE!!!

Wednesday, March 09, 2005

scalability

Comment from Larry Osterman's weblog:

"you can't speed up hard disk copies by throwing more threads or overlapped I/O at the problem, because file copy speed is ultimately limited by the physical speed of the underlying media - and with only one spindle, it can only read or write to the drive one operation at a time."

I thought with RAID, byte striping, SAN and the like you can't really assume what your underlying physical reality is anymore. I once heard this from a technical staff of a high-end RAID provider: "that anything you can throw into the SCSI bus, their RAID box will be able to write". Not really sure if it were true but their disks are really fast.
 
Listed on BlogShares