Showing posts with label hardware. Show all posts
Showing posts with label hardware. Show all posts

Tuesday, March 31, 2009

Good Results So Far For Google RAM

A week ago I had 4GB of RAM die (well, part of matched pair anyway) in my main desktop PC.

I’m currently awaiting replacement under warranty from Corsair, but meantime it’s hard to run dev tools and big virtual machines with the measly amount of memory I have left. So I thought it was time to give the new Google network-attached RAM a try.

I had to flash the motherboard BIOS of course and upgrade the chipset driver and the on-board network controller firmware. Google RAM, just like wake-on-LAN, has to interact with the network card at a hardware/BIOS level. In this case, the purpose is to ensure that any OS I boot sees the new space just like local memory.

Then I rebooted and … nothing.

Where is my free 4GB of storage?

Then I remembered that Google’s revenue model for this product requires you to run a Windows service that in turn interacts with a Google-provided kernel patch for PAE.

In addition to providing checks in real time – as my machine accesses RAM – for any security threats, this service displays Google ads as 5 new icons on my desktop.

Apparently they are context-based, and determined by Google’s analysis of what I have in RAM at the time.

And they are surprisingly accurate. I had a picture of a Corvette open in Photoshop, and the G-RAM icons turned into links to car dealerships, new-car financing, and a discount oil change.

Google’s FAQ insists that it does not look at my clicks or the image file metadata – instead, its server analyzed the image in real time (since the network RAM is in their datacenter) and determined I was looking at a new Corvette.

The only downside was that my cable modem signal dropped out for a couple of minutes, and the local service warned me not to touch any processes using G-RAM until it could sync back up, or those apps would immediately crash.

No matter, overall it’s great technology, and I think my RAM replacement will arrive from Corsair tomorrow.

Monday, December 29, 2008

Fear of the Driver Disk

The problem of bloatware/crapware on retail PCs is well known -- to the extent that Apple makes fun of it, pointing out the absence of such software on new Macs, while PC tools exist just to clean it.

But bloatware has a less-famous, equally annoying sibling: all the garbage that brand-name hardware devices install off their driver or utility disk.

Pick up a peripheral -- printer, web cam, DVD drive -- from a major brand, and if you follow the automagical installer on the drive disk, you'll get a half-dozen apps that you may not need or like. In some cases, they're just bad apps (that have a habit of arranging to start at boot), while in other cases they can destabilize a perfectly-running system.

The problems are that

  1. in some cases you do need these apps, because some hardware features require "support software" to be present, and don't fully leverage the many built-in drivers and control panels available for free in Windows ...
  2. most hardware companies internally view the driver/utility software as an afterthought, writing it hastily, testing it inadequately, and staffing it with ... well ... whomever they can find.

There are two main remedies.

In many cases, getting an unbranded or "strange-branded" device is a smart idea (provided you know what you're getting). I've found these devices have straight-forward, minimalist support apps, make great use of built-in Windows drivers, and don't put any garbage on your system -- for the simple reason that they don't have the resources to write a bunch of half-baked apps, or to form "distribution partnerships" with people who do.

If I do have a brand-name product, I generally attempt to install it without its own driver disk, no matter what the instructions say. In many cases, the device is fully supported by Windows out of the box; in other cases, some features may not be available -- but I may not need them. (E.g., If I wanted to use my digital camera as a webcam, that would have required the vendor driver disk... but I have never wanted to use that feature of the device.)

And if that latter approach fails, it's pretty easy to uninstall the device or otherwise convince the PC it's never seen the device before -- so that you can go the RTFM route and use the supplied disk.

Sunday, November 30, 2008

Most Laser Printers are Razors, not Cars

Once upon a time, buying a small or midrange laser printer was like buying a car. Big upfront expenditure, lots of sweating the details, and a moderate amount of thought about gas mileage and scheduled maintenance, er, toner and fusers and all that.

Now, however, it's more like buying a razor. The core features are mostly reasonable, each "size" printer has a speed/duty cycle that determines its suitability for an installation, and the cost is so small that it's all about the consumables (blades).

So why won't vendors -- or manufacturers -- print the cost-per-page of consumables right next to the dpi, ppm, idle power consumption, and time-to-first-page?

It's easy to find 10x differences between otherwise similar printers in the cost-per-page based on the manufacturer's price for toner cartridges and their intended yield.

Big companies, of course, have IT purchasing folks who perform these calculations, factor in the discount they get because the CIO plays golf with the right people, and order the gear. In the case of printers, large companies are typically buying high-volume printers that are among the cheapest per page anyway.

But startups, professional practices (think doctors, accountants), small to midsize businesses -- they rarely calculate the TCO for each device. It would be helpful to have the consumables price per page listed right on the sticker, like MPG.

Thursday, July 24, 2008

No, CherryPal Will Not be the First (or any) Mass-Market Cloud Computer

Notwithstanding this predictable VentureBeat article about a thin-client device with a somewhat anatomically suggestive logo.

I've previously written about why thin-client is a not-now and not-soon solution.

The $249 "CherryPal" box reminded me of another twist on the problem ... one that comes into play when the thin client isn't just software (like Skyfire's screen-scraping browser) but a new hardware device.

See, here's the thing about building your own new hardware in smallish quantities: it's really expensive on a per-unit basis. Or, another way, you can't offer a fraction of the capability per dollar that a Dell or Sony can. Your $249 thingamabob is going up against other $249 devices that have way more stuff (e.g., entire laptops) because they are produced in high-volume orders of established designs/modules/parts.

To be more precise, there is a spreadsheet you can put together that maps your bill of materials, plus any special physical design issues into a cost per fabricated unit. It includes multipliers that will make you sad, like your $2 can't-live-without-it chip might end up adding $20 to the finished product cost... depending on where it fits in, affects other parts, quantities, and other stuff.

It's tempting though, especially since the last 5-10 years have brought the ability to fabricate in China for lower cost and in much smaller quantities than would have been practical before. (Of course the costs aren't really lower, they're just externalized into a bunch of other areas ... but those are politics/economics/policy areas more than tech, so I'll leave them be for now.)

So, whereas before you might have needed to sell 700,000 units to break even on something, now 20,000 units will do it: increased temptation.

But if you're CherryPal, you still need to convince someone that a $249 thin-client is more useful than a $299 laptop with 10x the horsepower, a screen, storage, and all the rest.

Thursday, November 29, 2007

Overclocking: I So Ought To Have Known Better

Ok, I'm not a big pc modder guy, but I was trying to squeeze some extra life for gaming out of a machine that isn't the latest. Using techniques I had successfully executed before, I was in the process of kicking the 3.2 GHz CPU up to 3.65, when I toasted my HDD. The thing was, I started skipping some steps I had done the previous times, and that turned out to be my downfall.

I know, the high-clock-speed chips are so 2005, because a slower CPU can have 7 cores, and execute 19 instructions per clock cycle and have so much on-die cache that you just mirror the entire system RAM into cache on startup and then pull out the DIMMs and use them to level that kitchen table with the short leg.

The fun part is seeing which component will fail from the overclocking. It's not the CPU of course. At one time it was the video card; fixed that. This time it looks like either the SATA bridge or the drive electronics themselves. Ah well. It'll totally be worth it once I get that pixel shader 3.0 action going. (I told you it was an older machine, besides, don't get me started on the awful experience I had trying Vista/DX10/PS4).