Friday, December 28, 2007

Is PCI-e 2.0 really backwards compatible?

UPDATE 1/15/2008: Received my RMA'ed IP35 Pro in the mail the other day from Abit and guess what - it works great. So maybe all my PCI-e spec compliancy ramblings were unwarranted - it was simply a bad pciex1 slot on the motherboard... BUT - according to Abit, they still don't guarantee support for PCI-e 2.0 cards in this board.


Everything I'd read (until now) showed the PCI Express 2.0 specification to be backwards compatible with 1.0/1.0a/1.1.

Interestingly enough, there seem to be quite a few new motherboards in the wild that have problems with the new 8800 GT video cards.

I ran across this after I purchased an Abit IP35 Pro board to use with an EVGA 8800 GT SC. I hooked everything up and as soon as I hit the switch - the thing wouldn't even POST. At first I suspected the 8800 (and I still haven't completely ruled it out) - but after hours of reading forum postings and talking to tech support - I'm leaning toward the problem being a bad motherboard.

For reference, full specs are as follows:
Nspire 650w modular psu
2x1gb OCZ DDR2 Reapers
EVGA 8800 GT SC
Abit IP35 Pro (Bios v14)
WD 320gb SATA

What's so strange about the whole thing is that if I move the 8800 to the second PCI-e slot - the system boots normally. The drawback here is that with this board - running 1 card in the second slot is at 4x instead of 16x. There are TONS of posts on the net - included Abit's own forums - with people having this exact same issue.

Everyone points to the fact that the 8800 GT card is a PCI-e 2.0 card - and the Abit IP35 Pro is 1.0/1.0a. But regardless of this fact - I have seen numerous posts from people with the exact same specs claiming they have no problems with the card and board combo.

Just for the heck of it, I threw the 8800 in an old ASUS 939 (AMD) board I had - and it fired up on the first try no problem. So I'm really having a hard time believing it's the video card.

I really think it's the Abit board. Unfortunately it's been over 30 days now since I originally bought it from newegg - so I have to RMA it directly with Abit. And guess what - they're CLOSED for the holidays?!??!?! UNTIL JANUARY 2ND!?!?! What the crap was I thinking buying an Abit????? Never again.

In Abit's defense - there are many other brands reporting problems. Be sure you do your homework if you're about to buy an 8800 GT.

I've seen forum postings commenting on certain video card manufacturers providing special firmware for the cards to force them into PCI-e 1.0 compatibility mode.. but unfortunately EVGA doesnt seem to be one of them.

I'll update this post after I RMA the Abit board (I plan on cross mailing - so maybe it wont take too long).

Thursday, December 20, 2007

Microsoft Office 2007 Filter Pack for Search (WSS3.0/MOSS2007)

I just noticed Microsoft released the Office 2007 Filter Pack yesterday for Search products (Sharepoint, Search Server, Desktop Search, Exchange, SQL, etc).

This is a welcome addition as the only way to get these file formats searchable previously was to install the actual products on your sharepoint server.

The pack contains iFilters for the following formats:

.docx, .docm, .pptx, .pptm, .xlsx, .xlsm, .xlsb, .zip, .one, .vdx, .vsd, .vss, .vst, .vdx, .vsx, and .vtx

There's still some manual registry editing involved for WSS3.0 to enable them - but there's a link on the download page with full instructions.

I've installed the Filter Pack on my test server and also on my production server with no issues so far. There's no reboot or restart of IIS required - although you do have to restart the spsearch service.

Another nice thing - unlike the PDF iFilter - after installation you do NOT have to delete and re-upload any existing documents to get them indexed. It automatically identifies and indexes them on the next crawl.

Very nice.

Tuesday, December 18, 2007

WSS3.0 SP1 First Report

Well, curiosity finally got the better of me today so I went ahead and installed WSS3.0 SP1.

I performed the install on a test server and it went off without a hitch. I simply stopped the w3svc service and ran the installer. The Wizard even popped-up at the end like it was supposed to. I was pleasantly surprised. The Wizard took awhile to run - but ran without problems.

I hit the main site and all looked good.

Now for my real question - would it fix my issue with all-day-event calendar items in email alerts.

Unfortunately it did not. The screwy timezone issue is still present.

Oh well, at least it didn't break anything (yet)-

More to come when I do it for real on a production server-

Monday, December 17, 2007

WSS3.0 SP1 is out

For those who haven't heard, WSS3.0 SP1 is finally out.

I'll post my experience with the installation in the next couple of weeks.

Thursday, December 13, 2007

IISxpress (IIS Compression)

'Ran across this great little freebie (free for personal use anyway) from Ripcord Software tonight while searching for an IIS Compression product.

I just needed something simple to speed up a little personal/test site (Windows XP) I have running with only 256k upstream. I didn't need the control offered by commercial products such as HttpZip, etc - nor was I going to spend the money.

The compression ratio seems pretty decent so far - generally in the 70ish-% range.

All in all, IISxpress suits my needs perfectly. This will definitely be added to my favorite freebies list.

Monday, December 10, 2007

XML to HTML Transforming

During some recent performance tuning on a ASP.NET web app, I saw a noticable cpu spike whenever the app did a server-side XML-to-HTML transform. The function in question was to essentially render a series of dynamic forms to HTML (where the number and size of the forms varied).

The code simply used streams with an XPathDocument and XslCompiledTransform to transform potentially large amounts of XML (and large XSLTs) into HTML on-the-fly.

After reviewing the code, a coworker had the idea of simply moving the transform down to the client. I honestly don't know why we never thought of that in the first place...

But anyway, we quickly threw together some javascript making use of ActiveXObjects XMLHTTP and XMLDOM and modified our server-side code to just send down the raw XML.

The results yielded noticable performance gains for both client and server. The client generally saw page loading improve by 30%-50% depending on the machine - plus we had the added benefit of reducing the cpu load on the webserver.

The only time the change actually hurt the client was when there was a considerable amount of XML to transform (many MB of data) - which actually would have been faster done server-side - but statistically speaking that was going to be a pretty rare occurance.