Restoring an InfoTower 1000

Just a few notes from this one.

I rescued some old gear from ACMS with the intent of at least getting some of it operational whilst I kept a hold of it.

One of the items was a DEC InfoTower system with 7 CD-ROM drives.

The InfoTower was a DEC InfoServer 1000 in a steel cabinet (labelled BA56A) , with a single power supply to power it and all the drives connected.  InfoServers could also be used to drive tape and conventional disk units so they could be served to VMS and other systems over an ethernet LAN.

InfoTowers were available with 4 or 7 CD-ROMs, and whilst a lot of photos out there have these with the older caddied RRD42s and similar, the one I picked up has the RRD43 tray drives.

When I got around to inspecting it, it clearly had a blown power-supply – you could smell the electrolyte from the capacitors the moment the rear service cover was removed.

Interestingly enough, the InfoTowers use an old AT-style power supply which plugs into a backplane which connects to the power-connector made available to each drive bay.

You can replace the power-supply fairly trivially with a modern ATX one if you get a ATX to AT power supply loom.  (I picked up one from ebay).  The power supply you install will need to be no bigger than a standard profile power-supply (so the very large monsters like the old Corsair HX1000 are completely out of the question) and needs at least 3 Molex plugs.   The original supply was a 230W supply.  I used a cheap Aywun 500W power supply since I couldn’t get anything smaller with sufficient Molex plugs.

Unfortunately, most of the eBay looms have the switch soldered to them, rather than connected by spades (like the original AT supplies used), which is wasteful and needless as AC-safe spade connectors are quite cheap.  I cut the spade connectors off of the old power-supply’s switch leads and spliced them onto the switch-cable from the loom.  That said, if I had uncrimped spade shoes and insulators, that would have been a better choice than using the old connectors.

One trap to watch, however, is that the pin-out of the P8/P9 connector on the backplane is the reverse of the convention from PCs – whilst the two connectors are side-by-side, you must connect them with the ground wires outside, not in the middle.  (You should double-check this before you swap the supply over, but I doubt there’s that much variance in the units).  Fortunately the PCB is labelled, so a bit of investigative work should help you verify this before you smoke your new power supply.

AUI to 10Base-T (Twisted-Pair) adapters are also fairly easy to get hands on these days too – I was able to pick up a few more so I’ll have enough to hook up my MicroVAXen as well as the Infoserver.

Overdue Flying Update…

It’s been too long since I last wrote in this blog.

Since last time, I had enrolled and commenced in the Diploma of Aviation (Instrument Flight Operations) with Sydney TAFE and Sydney Flight College.

Last weekend, I flew the last flight test required for the completion of the Diploma – I’m now waiting on confirmation from CASA for the issue of my Commercial Pilots License (Aeroplane), and from the TAFE that I’ve finished the diploma.

It’s been a lot of work getting here – but now I’m finished, and it’s time to take a quick break and get back to all the projects that had been put on hold due to my workload.

CPL Passed!
CPL Passed! Standing with the Piper Arrow III I flew my CPL Flight Test in.

Wind Correction on the HP48/50

Out of frustration with how slow working on an E6B can be during flight planning, I’ve been looking into electronic options for replacing it that do not involve buying an overpriced specialised calculator.

Whilst solutions like the CX-2 can be used in the US in exams, they can’t be used here, which defeats any benefit of using a type specific calculator over a more generic programmable.

Also, the pricing is such that a CX-2 costs about 2/3rd the price of a good programmable like the HP50G.

So I’ve opted to buy a 50G and implement as much of the E6B functionality as is practical for planning.

My initial efforts are as below!

Wind Correction on the HP50G (easily adapted to the non-CAS 48G by removing the →NUM instructions and the UNROT instructions with ROT ROT).

≪ 'curTAS' STO ≫ 'TAS' STO
≪ 'curWV' STO 'curWHT' STO ≫ 'WV' STO

These should all be put into their own folder. They work using globals to store values that carry over between specific operations.

It’s also written with RPN mode in mind. I’m not entirely sure how anybody gets anything done fast on a calculator using algebraic modes.

Oh, and set Degrees for angles unless you do your flight planning in Radians.

Using the above:

Change to the folder, and select the custom menu.

Punch in your TAS, press the TAS softkey.

Punch in your wind as two values – the heading and velocity – and press the WV softkey.

Punch in your desired track and press TRKT. The heading correcting for wind and ground speed will pushed onto the stack.

You only need enter a new WV or TAS if they change – they will persist between multiple TRKT operations.

Flying (Lesson 2)

I recently started taking flying lessons with the Sydney Flying Club based out at Bankstown.

I had been a bit anxious about being able to fly this week as Sydney has been blanked by slightly unpleasant weather lately – we had a storm forecast for Friday which looked like it would hit around 3-5pm.  (2-3pm is usually when I go up).

I managed to get a booking in for 11:30am, so I hiked out to Bankstown, and fortunately, the weather was good enough.

The aerodrome was surprisingly busy. Plenty of helicopter traffic taxing around, and a private jet (looked like an Embrarer, but I don’t know their models well enough to identify which one) taxied past us as we walked to the Piper Warrior I was booked in for (VH-SFM).

(To help follow the rest of the post, here’s a map of Bankstown Airport)

SFM was parked in the flight club’s field parking between taxiways L and P.   After completing the preflight checks to the satisfaction of the instructor, we discovered that SFM’s flaps weren’t retracting when we dropped the flaps lever.

Thinking it’d correct itself under airflow, we set out via taxiway P (near the junction to L) upon which point the Instructor took control, set the brakes and tried to throttle up to force the flaps up with the prop wash.

When that didn’t work, we parked again, stopped the engine, un-jammed the flaps – confirmed that they were operating correctly again (they were, mostly – at least they retracted now under airflow force), and set off once again towards the runways.

I taxied all the way from parking to the A run-up bay, stopping to give way to other aircraft leaving the controlled tarmac for the apron,  ran the run-up checks, then taxied up to the A8 holding for 29R.

My instructor, satisfied with my taxing, instructed me that I’d be conducting the takeoff today, let me line up on the runway, and away we went.

Lesson itself was fairly uneventful – “Straight and Level” – all about maintaining level flight at different speeds/attitudes.

The flight back to the airfield was interesting however – by the time we returned from the training area, the winds had changed and the temperature had increased sharply – we were cleared to land on 11L. The instructor takes over from the reporting point, and everything is in order for a nice landing.

He sets up, deploys the flaps and bleeds off speed for final — and we just float there. Turns out that’s there’s a massive updraft freshly developed in front of 11L and because we hadn’t established our descent rate quickly enough, we’re now gently floating down – with our estimated touchdown point leaving us only 40% of the runway. He calls a go around and we re-enter circuit, and are given immediate clearance to land again (phew).

Fortunately attempt two went better and we touched down happily on the first half of the runway.  He taxis off the runway, hands back control, and I taxi us back to the field parking, where I brought the Piper in to park smoothly.

Japan Music Festival at the Roller Den, Sydney

I tagged along to the JMF on a whim, partially as a fan of JRock/JPop – and partially as a photographer looking for somewhere to practice my camera-craft during my off-season.

It was a great show.  Ended up buying Jill’s and kaimokujisho’s albums.  Should have picked up Sparky’s album too, but I was suffering pretty badly from the volume levels and was trying to make it out without spending all of my cash.

Unfortunately for me, I made the amateur’s mistake of not taking earplugs with me – my ears finally stopped ringing 3 days later.

It was a great first outing for my new second-hand 70-200 2.8 VR, which performed admirably in the conditions.  I had also completely forgotten some of the crazy with the D3 and the space remaining counter, so I thought I was running out of space by the end of kaimokujisho’s set – many poor (but potentially salvageable) bursts got deleted, and I thought I had significantly less space during 101A’s set than I actually did, so shot hyper conservatively…  then I discovered about 3 minutes into Jill’s set I had a whole memory card free.  I’ll try to remember about the damned counter next time.

A special kind of Hell…

So, I thought that ActiveRecord transaction support was finally reasonably mature and usable in Rails 4.

How wrong I was.

One of my biggest complaints with ActiveRecord has been that there was no way to set transaction isolation for a given transaction. This got addressed in Rails 4. Unfortunately nothing else appears to have been fixed.

The Problem

The problems remaining in ActiveRecord surrounding transactions:

  • No connector agnostic handling of transaction collisions/forced rollbacks.
  • No visibility of transaction isolation level inside a transaction
  • No automatic restart facilities for transactions.

No connector agnostic handling of transaction collisions/forced rollbacks.

My last post surmised why this is a problem pretty well – you need to understand your specific connector well enough to understand precisely how it’s going to tell ActiveRecord that the transaction failed. This is incredibly non-portable as a result – ActiveRecord is supposed to hide database details, not expose them!

No visibility of transaction isolation level inside a transaction

Transaction isolation is nice and fine, but the way it interacts with transaction nesting is a pain in the ass.

If a new deeper transaction is requested in a nested set with equal or lower transaction isolation to the open transaction, it should just work as normal without changing the isolation level. Whilst I’m sure there’s plenty of arguments to do with performance as to why this is suboptimal, but if you’re lowering isolation levels for ‘performance’, you probably shouldn’t be running those statements inside of a higher isolation transaction block.

I can’t even wrap this in since the isolation level information is discarded when the transaction is created – ActiveRecord makes no effort to remember what isolation level we’re running at.

This one is pretty important too since you can’t always see the implementation details of model methods at a glance and as such can’t tell if it’s usually a short transaction to ensure that it’s results are consistent.

No automatic restart facilities for transactions.

Not everybody realises that a transaction can fail because the database can’t guaranty it’s consistency, leading to the incorrect application of transactions by beginners.

Having an optional automatic restart facility would alleviate some of these problems as it would make it clear that it may be required in some circumstances to handle a transaction restart, and also allow users to get that behaviour with minimal effort.

It also facilities some improvements I have thought of…

A Proposal

I think we need to make the following changes to the transaction code:

  • Create an IsolationLevel class or comparison method so it’s possible to actually compare isolation levels against each other easily. As there is a clear heirachy of isolation with the standards based isolation levels, we should be able to compare them naturally in our code, and it should be possible to add any non-standard levels a driver offers.
  • Add an isolation_level attribute to the Connection.current_transaction objects so you can discover what isolation level is currently in effect
  • Add an optional restartable attribute to the transaction which defaults to false which indicates if the transaction can be auto-restarted. Add a optional max_retries attribute to specify how hard it should try.
  • Treat ALL transactions uniformly – at the moment the code differentiates a transaction started with an explicit isolation level parameter vs one without. You should be able to join transactions at the same isolation level that you desire at the very least, and there’s little harm in allowing transactions of lower isolation levels to join higher isolation level transactions.
  • Consider using the auto-restart facility, if enabled, to kick the isolation level on a transaction to a higher isolation level if required by a sub-transaction. This can be expensive if it’s happening a lot, but it’s better than some of the hoops required without it. In a lot of circumstances, however, the cost should be negligible as the query caches should help reduce the second execution costs.

Detecting Transaction Failures in Rails (with PostgreSQL)

So, Rails4 added support for setting the transaction isolation level on transactions. Something Rails has needed sorely for a long time.

Unfortunately nowhere is it documented how to correctly detect if a Transaction has failed during your Transaction block (vs any other kind of error, such as constraints failures).

The right way seems to be:

RetryLimit = 5 # set appropriately...

txn_retry_count = 0
  Model.transaction(isolation: :serializable) do
    # do txn stuff here.
rescue ActiveRecord::StatementInvalid => err
  if err.original_exception.is_a?(PG::TransactionRollback)
    txn_retry_count += 1
    if txn_retry_count < RetryLimit 

The transaction concurrency errors are all part of a specific family, which the current stable pg gem correctly reproduces in it’s exception heirachy. However, ActiveRecord captures the exception and raises it as a statement error, forcing you to unwrap it one layer in your code.

On Python and Pickles

Currently foremost in my mind has been my annoyances with Python.

My current gripes have been with pickle.

Rather than taking a conventional approach and devising a fixed protocol/markup for describing the objects and their state, they invented a small stack based machine which the serialisation library writes bytecode to drive in order to restore the object state.

If this sounds like overengineering, that’s because it is. It’s also overengineering that’s introduced potential security problems which are difficult to protect against.

Worse than this, rather than throwing out this mess and starting again when it was obvious that it wasn’t meeting their requirements, they just continued to extend it, introducing more opcodes.

Nevermind that when faced up against simpler serialisation approaches, such as state marshalling via JSON, it’s inevitably slower, and significantly more dangerous.

And then people like the celery project guys go off and make pickle the default marshalling format for their tools rather than defaulting to JSON (which they also support).

Last week, I got asked to assist with interpreting pickle data so we could peek into job data that had been queued with Celery. From Ruby.  The result was about 4 hours of swearing and a bit of Ruby coding to produce unpickle. I’ve since tidied it up a bit, written some more documentation, and published it (with permission from my manager of course).

For anybody else who ever has to face off against this ordeal, there’s enough documentation inside the python source tree (see Lib/ and Lib/ that you can build the pickle stack machine without having to read too much of the original source.  It also helps if you are familiar with Postscript as the pickle machine’s dictionary, tuple and list constructors work very similarly to Postscript’s array and dictionary constructs (right down to the use of a stack mark during construction).

LCA2012: Day -1: Arrival and Registration

So, I’m in Ballarat for LCA2012, courtesy of my employer.  I’ll be presenting on Tuesday along with David on some of the work I’ve done on a few tools for systems automation.

The flight was uneventful – although the landing was a bit rough…

The drive from the car rental place to Ballarat was fortunately uneventful, but plagued with a combination of idiots who insist on doing things the hard way (for crying out loud, don’t try to shoot past me on the left if I’m indicating a left merge already >_< ) and the fact the car’s speedo reads about 5-7kph under actual resulting in us doing about 92kph down the western highway when I thought we were doing 98kph (I have a 100kph limit still.  damned P-Plates).  The car is a newish Camry and is by far the newest thing I’ve actually driven any distance now – quite impressed in some ways, but disturbed by the lack of vision due to the body shape (pillars are huge >_< ) and the very light steering.

Fortunately we reached Ballarat and found the motel without troubles.

Registered at the University and picked up the schwag pack.  This year’s bag is a crumpler sack style thing, contianing: A catalyst branded screen cleaning cloth + case, Bulletproof Networks branded mousemat (looks like it might be faux leather or even real leather), an LCA branded keep cup, intel branded universal USB -> smartphone charger, DSD branded stubbieholder and careers spiel pamphlet, LCA t-shirt, LCA conference guide and a Freetronics LeoStick.

Met up with some people and went to Murphy’s – an Irish pub on the main drag – for dinner.  Had the Irish Pizza which was quite pleasant, and generally emptied my wallet on food. (Ouch).

All in all a good start to the week – tomorrow is miniconfs.