Category: Random stuff

Wet tumbling and the weight of brass

so-shiny-im-gonna-dieAfter wet-tumbling my first batch of brass the first thing that came to my mind was that scene from Despicable Me: It’s so fluffy shiny I’m gonna die!

So I went ahead and did my already dry-tumbled “clean” brass over again, leaving my with piles of oh so shiny brass. But… how much? Well, counting brass kinda sucks when you’re talking thousands per caliber, so better put it on a scale and do the math.

Here’s a handy breakdown for future reference:

Case grains per case grams per case cases per lb cases per kg lb per 1000 kg per 1000
9×19 59,5 3,86 118 259 8,5 3,9
.357 Mag. 78 5,05 90 198 11,1 5,1
.38 Special 68 4,41 103 227 9,7 4,4
.40 S&W / 10mm / .357 Sig. 70 4,54 100 220 10,0 4,5
.44 Mag. 115 7,45 61 134 16,4 7,5
.45 ACP 90 5,83 78 171 12,9 5,8
.223 Rem 95 6,16 74 162 13,6 6,2
.308 Win 175 11,34 40 88 25,0 11,3
.50 BMG 865 56,05 8 18 123,6 56,1

* the bigger the cartridge, the bigger the margin of error of course

Finicky buttons on Vortex SPARC

A quick tip for anyone experiencing somewhat finicky buttons on a Vortex Sparc (Gen. 1): Chances are your unit isn’t defective, it’s just time to replace your CR2354 battery.

Apparently the red-dot will continue working until the very last moment, when your cell is completely out of juice – but the controls won’t. Sometimes they work, sometime they won’t. Turning the red dot on and off seemingly takes forever and occasionally won’t work at all. Even though the dot itself was as bright as it gets, turns out my battery was almost out of power. Replaced it with a new one – everything is back to working again like it’s supposed to.

KVM too fast for plymouth-upstart-bridge

Kind of a hilarious bug, really… I recently installed another Ubuntu 14.04 server running inside a KVM with a rather fast storage backend, therefore the system apparently boots just a tiny bit faster than my other images have in the past. Problem is, apparently that slows down the boot process as init thinks something must be crashing and decides to respawn it for good measure…

[ 2.311174] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[ 2.811553] init: plymouth-upstart-bridge main process (191) terminated with status 1
[ 2.812789] init: plymouth-upstart-bridge main process ended, respawning
[ 2.874117] init: plymouth-upstart-bridge main process (210) terminated with status 1
[ 2.875167] init: plymouth-upstart-bridge main process ended, respawning
[ 2.904155] init: plymouth-upstart-bridge main process (217) terminated with status 1
[ 2.905289] init: plymouth-upstart-bridge main process ended, respawning
[ 2.928618] init: plymouth-upstart-bridge main process (221) terminated with status 1
[ 2.929713] init: plymouth-upstart-bridge main process ended, respawning
[ 49.975826] Adding 2093052k swap on /dev/mapper/[...]

Yep, that’s right – 47 seconds waiting and idling, doing nothing when the image could have booted in a fraction of that time.

To fix it, simply add a sleep 2 to your /etc/init/plymouth-upstart-bridge.conf

[...]
stop on (stopping plymouth
         or stopping plymouth-shutdown)     

console output

exec plymouth-upstart-bridge
sleep 2

Init won’t freak out anymore and starts the image as it’s supposed to:

[    1.225045] random: lvm urandom read with 16 bits of entropy available
[    1.281118] bio: create slab <bio-1> at 1
[    1.370262] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
[    1.684687] tsc: Refined TSC clocksource calibration: 2500.001 MHz
[    2.153550] Adding 2093052k swap on /dev/mapper/[....]-swap_1.  Priority:-1 extents:1 across:2093052k FS
[    2.169332] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro
[    2.190451] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[    2.408937] EXT4-fs (vda1): mounting ext2 file system using the ext4 subsystem
[    2.417990] EXT4-fs (vda1): mounted filesystem without journal. Opts: (null)
[    3.316769] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    3.316778] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[    3.495345] FS-Cache: Loaded

Way better….

Updating SmartArray controllers on 64-bit Ubuntu 14.04

Want to install a firmware update on one of your HP SmartArray controllers while running a 64-bit OS? Turns out, the binaries distributed by HP seem to be 32-bit only – running for example Ubuntu 14.04, here’s what you gotta do…

root@host:~#./CP021971.scexe 
./CP021971.scexe: 153: ./CP021971.scexe: pushd: not found
./CP021971.scexe: 158: ./CP021971.scexe: popd: not found
./ccissflash: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

 

But libstdtc++6 seems already installed, hmpf… 32-bit maybe?

root@host:~# dpkg --add-architecture i386
root@host:~# apt-get update
root@host:~# apt-get install libstdc++6:i386
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  gcc-4.8-base:i386 gcc-4.9-base:i386 libc6:i386 libgcc1:i386
[...]

 

Let’s try that again…

root@host:~#./CP021971.scexe                                                                                                                                               
./CP021971.scexe: 153: ./CP021971.scexe: ./CP021971.scexe: 158: ./CP021971.scexe: popd: not found
pushd: not found

        This program consists of two phases: device discovery and device update.
        No device will be updated until you answer.

Do you want to run device discovery?
(yes/no) yes
Finding hardware. This may take a few minutes.
Found 1 devices.

Do you want to upgrade the device that has older ROM?
(yes/no) yes
1 devices will be updated.
Updating: P410i Slot: 0 from [5.70] to [6.40]
Updating: P410i Slot: 0 from [5.70] to [6.40]

As part of the reboot process, you must power cycle the server and any external array storage devices.

Well, that was rather easy…

Fix check_hpasm for 3.x kernels

After upgrading one of my HP ProLiant servers to Ubuntu 12.04 LTS (better late than never) the check_hpasm Nagios plugin broke, resulting in no regular checks of the internal arrays being performed.

Apparently that’s a known bug with the hpacucli utility doing the actual checks, which can’t uname returning a 3.x kernel version. You can manually fix this by running it like this:

Usage:
 setarch x86_64 --uname-2.6 [[program] [program arguments]]
Example:
 setarch x86_64 --uname-2.6 hpacucli ctrl all show

Therefore a quick and dirty fix for check_hpasm would be to open up /usr/lib/nagios/plugins/check_hpasm and go to the part that reads:

if [ -x "$hpacucli" ]; then
 for i in config status
 do
$hpacucli ctrl all show $i | while read line
 do
 printf "%s %s\n" $i "$line"
 done
 done
 fi

and replace the line (553 in my case) calling hpacucli with:

/usr/bin/setarch x86_64 --uname-2.6 $hpacucli ctrl all show $i | while read line

Worked just fine for me.

Grant Williams ASFA 2013 presentation

While this isn’t an economics or investment blog by any means, here’s a nice 30 minute presentation by Grant Williams recently given during the 2013 ASFA conference. Humorous as always and IMHO spot-on, outlining the current state of international financial markets, the current government bond bubble and equity rally of 2013… and how it’s all inevitably going to go down in flames. Very well worth watching, even if you aren’t a investor, trader or otherwise closely associated with the financial markets.

[youtube https://www.youtube.com/watch?v=5A3CoFyi2U8]

Fix for bad write performance with LUKS + RAID5

After setting up a new fileserver with an LUKS encrypted dataset on top of Linux software RAID5 I did some benchmarks and reliability testing before filling it up with “real” data… but it turns out write performance was quite horrible. Only a fraction of what the “raw” RAID5 could do, all while having the CPU mostly idle. So what’s going on?

Apparently only small blocks of data get written to the disks when using LUKS encrypted volumes (mostly default settings) therefore dramatically reducing write performance (figured it out thanks to this) on my RAID 5 volume. Setting the stripe_cache_size from 256 to 8192 increased throughput from roughly 50-70 MB/sec to well above 200 MB/sec.

echo 8192 > /sys/block/md0/md/stripe_cache_size

To permanently set it, so you don’t have to manually adjust it after every reboot, consider setting up a udev rule like this:

/etc/udev/rules.d/md-stripe-cache.rules


SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="8192"