the Zen of Communication.

Running some performance tuning, the app needed to know how many flops (floating point operations) per cycle the system could handle.

I used SiSoftware’s Sandra benchmarking app. It told me that my Intel Pentium D Dual Core 1.8ghz proc was producing 10.86gflops, but not the flops per clock cycle.

From this we know: a) the total gigaflops (10.86), b) the number of cores (2), and c) the number of clock cycles per second (1.8ghz)

Example of the standard formula:
The formula to determine total gigaflops is:
Flops per cycle x # of Cores x Clock speed.

This involves four values:

a = flop per clock cycle
b = clock speed (ghz)
c = cores
n = gflops

For a dual core 3ghz system with 4 flops per cycle, we can deduce 24gflops (a x c x b = n, or 4 x 2 x 3 = 24) . But I only have the total gflops, clock speed, and number of cores.

Reverse algebra:

a = n / b / c

Or in my case:
10.86 gflops / 1.8ghz / 2 cores = 3.01 flops per cycle (per core). So the E2610 chip at 1.8ghz produces 3 flops per cycle per core, or 6 flops total. Ta da.

Note: It’s worth mentioning that in this case, 10.86 gflops and 1.8ghz seem like closely related numbers, and that it would be quick to figure out how many gflops a system can handle by its clock speed (i.e. 1.8ghz equals 10.86gflops).  This is not the case.  In the first example of a dual core 3ghz proc producing 24gflops, you can’t deduce the one from the other.  It was just a coincidence in my case, so don’t do that.

I’ve spent an awful lot of hours trying to track down the SNMP MIBs for a Barracuda spam firewall. Searches on the Barracuda website for “MIB” and “SNMP” returned very few results – but I was looking for the MIB files themselves.

It turns out Barracuda has cunningly hidden the MIBs within their devices. Read http://www.barracudanetworks.com/ns/downloads/Other/OTHER_Barracuda_Spam_&_Virus_Firewall_SNMP.4.pdf

Specifically, under page bloody one:

MIBs
You will need to obtain and import two MIB files to your SNMP monitor:
1. The Barracuda Reference MIB (standard across all Barracuda Networks products)
2. The Barracuda Spam & Virus Firewall MIB
You can use reference objects included in these MIBs for monitoring either from custom scripts or from
your SNMP monitor. The MIB files are located on the appliance and can be obtained by replacing
YOURBARRACUDA in the following links with the IP address of your Barracuda Spam & Virus Firewall:

http://YOURBARRACUDA:8000/Barracuda-SPAM-MIB.txt

http://YOURBARRACUDA:8000/Barracuda-REF-MIB.txt

Isn’t that great? I thought that was great.

Anyway. There it bleedin is.

Windows 7 will install a hidden 100mb partition at the front of your drive when you do a clean install.  It uses this for system recovery if your install goes belly up, and/or bitlocker headers for drive encryption.

I need neither.  And the kicker is some apps (like TrueCrypt) don’t function correctly with the 100mb partition.  In fact, TrueCrypt CAN’T encrypt your system drive because the bootloader is on the other partition.  Not very helpful.

MyDigitalLife shows how to work around this – http://www.mydigitallife.info/2009/08/20/hack-to-remove-100-mb-system-reserved-partition-when-installing-windows-7/ .  See part three, “Method 3: Trick to Remove 100.00 MB System Reserved Partition During Setup” .

In a nutshell, when you’re installing Win7 (note, if you’re reinstalling, this will erase your data, no two ways about it) and you reach the portion allowing you to select your partition, erase your existing 100mb system partition, and your existing OS partition.  Then pick the freshly unallocated space and tell it to install there.  It will say “We’ll create a hidden system partition for your protection” – say OK.  Now delete the new OS volume – not the 100mb partition. Yes, delete the new partition it created for your OS.

You should have a 100mb system partition, unallocated space, and maybe another partition for your data, if that’s how you roll.

Next select the hidden partition, and click Extend.  This will allocate the rest of the unused space (from the system partition you just deleted) to the hidden partition – giving you a single OS volume with no hidden partition.

Ta-da.

Thanks MDL – saved me some headache there.

Note: this trick only works during reinstallation of Windows.  They have a couple other hacks to remove the hidden partition after you’ve installed, but they didn’t suit my purpose.  AGAIN: THIS WILL ERASE YOUR DATA. Don’t cry to me if you didn’t back it up.

So, vLite out of the box (or extracted download, as it were) requires three files to run – wimgapi.dll, wimfltr.inf, and wimfltr.sys (wimfltr.inf is a driver file that requires .sys).

The interesting thing about Win7 and vLite is that Win7 already has wimgapi.dll in c:\windows\system32 (or syswow64, I presume).

“Neat!” thinks I, and copies that to the c:\windows\program files\vlite directory, and pulls wimfltr.inf and wimfltr.sys from another server I have with the WAIK on it. I run Vlite. It runs slow, but runs. I configure my install source, it runs slow, but runs. I get to modifying my install source (removing components), it runs VERY slow, then crashes. Consistently. Changing options, running as admin, running in a compatibility layer, all return crashes after it runs.

Turns out vLite does NOT like the wimgapi.dll that comes with Win7. So, moral of the story folks – use all the same versions from the same source.  In my case, I pulled them from c:\program files\windows aik\Tools\x86.  In your case, unless you’ve downloaded the 2gb WAIK iso, you’ll need to find them from Google or Bing.  Distribution is apparently some form of international terrorism.

From the WAIK I’d installed, these were files modified 11/1/2006 and 11/2/2006 . As soon as I replaced wimgapi.dll in the C:\Program Files\vLite\ directory with the older version  (replacing the one from 7/9/2009, with the one from 11/1/2006) vLite screamed to life and ran as expected and followed all the way through without a single crash.

This was, needless to say, a relief.  Happy trails.