The Advisory Boar

By Abhijit Menon-Sen <>

Renault Duster AWD 2019


Renault India introduced the Duster AWD in late 2014, and Hassath and I bought one just days after it was released. We liked it immediately, and wrote a detailed review after one year. At the time of writing, our car is doing fine after five years of unrelenting offroad use.

Time to upgrade?

The Duster retains a dedicated following, but attracts fewer new buyers with each passing year. Its outstanding ride quality and surprising AWD competence are still unmatched in its segment (the Mahindra Thar is much less usable on-road, and the Jeep Compass AWD costs as much as a Duster and Thar put together); but the AWD market in India was always a niche, and the Duster is now increasingly described as “dated” and lagging its competition in terms of features and interior comforts.

Renault chose not to bring its second-generation 2017 Duster to India, and was content to release the occasional “facelift”, most recently in July 2019. Meanwhile, grim rumours began to circulate about the future of the Duster AWD in India after the April 2020 deadline for adoption of BS6 emission standards (or even Renault's future in India, depending on how grim you wanted to be).

In October 2019, the Duster AWD took top spot in Autocar India's list of “cars to buy before they die”.

Alas, the latest facelift did not endear itself to us. The AWD variant, formerly available only in the top-spec RxZ configuration, was relegated to the “RxS(O)” line and stripped of various features to reduce costs. Some of the differences we didn't care about (cosmetic changes), some we could live without (e.g., the touchscreen, electrically foldable outside rearview mirrors, reverse parking camera), and some we were willing to sacrifice (e.g., cruise control, speed limiter).

But that left us with the infuriating omission of the rear wiper and washer and height-adjustable driver's seat with lumbar support. We need both and were prepared to pay more for them, but neither feature could be retro-fitted onto the RxS(O) car (and we couldn't do without AWD).

Conclusion—keep the 2014 RxZ AWD, don't buy a new one.

RxZ AWD: the last of its kind

At least, that would have been the conclusion if it hadn't been for Hassath. At her urging, someone at the dealership went to consult the inventory, and found a pre-facelift 2019 Duster RxZ AWD at the factory in Chennai. Just one.

At first, I was not a fan of buying an "older car", but Hassath asked me to enumerate specific reasons to avoid it. After much thought, the only objection I could come up with was… “But it's brown”.

And that's how we came to buy the very last pre-facelift 2019 RxZ AWD available anywhere in India. And it's actually quite a lovely brown.

Headline feature comparison

Here's an armchair comparison of some major features between the 2014 RxZ AWD (our old car), the 2019 RxZ AWD (our new car), and the 2019 RxS(O) AWD (the latest available model).

This table omits features present in all three models (e.g., ABS+EBD+BA) as well as differences from the brochure that I didn't find interesting (e.g., the colour of the inside door handles).

Feature comparison
  2014 RxZ AWD 2019 RxZ AWD 2019 RxS(O) AWD
Cruise control ×
Speed limiter ×
Front fog lamps (optional)
Rear wiper and washer ×
Height adjustable front seat belts ×
Height adjustable driver's seat with lumbar support ×
Driver's seat armrest × ×
One-touch driver's window × ×
Automatic climate control × ×
Reverse parking camera × ×
New MediaNAV touchscreen ×
Projector headlamps, LED DRLs × ×
Cooled storage × ×

One minor change deserves special mention: the rear window controls have been moved to the front of the rear armrest, which fixes a long-standing annoyance for rear passengers who accidentally lowered the window with their elbow. This might be our favourite new feature.

Not all of the differences above were initially clear to us. The rear wiper and washer and the height-adjustable driver's seat by themselves were enough to tip the scales in favour of the older model. We realised later that we would get automatic climate control and a reverse parking camera, and discovered only when we received the car that it had the new-style touchscreen with Android Auto support.

Thanks to Hassath, we didn't lose any features we already had, we got a few nice surprises, and missed out on only two relatively minor features from the facelift. In short, we got lucky.

Cosmetic changes

Renault has made various design changes to the original Duster, and we don't particularly care for any of them. Since the Duster was launched in 2012, their aesthetic sense has never strayed too far from “can we make it even more shiny somehow?”

Many of these changes can be seen in the Team-BHP reviews of the 2012 Duster, 2014 AWD (which is what we had), and 2016 Duster (which was also only a “facelift”, and looks very much like the 2019 RxZ AWD).

Here are some of the changes we've noticed, in no particular order.


All three models have different alloy wheels. We still like the original bold five-spoke “anthracite” design best, both for its distinctive looks and because it's easiest to clean. We don't mind the generic-looking but inoffensive (no red centre) in-between design that we ended up with. The facelift introduces distinctive “diamond cut” alloys, but they're a bit too busy and shiny for our tastes. (Also, diamond cut makes me think of an addictive but crumbly South Indian fried snack, and I'd just as soon keep those away from the car.)

The plastic front and rear skid plates have both become larger and more prominent. The unobtrusive black-and-silver one in front has now become a flamboyant contrasting silver moustache with a nicer-looking mesh for the air dam. The facelift goes back to a darker silver colour for both.

The turn indicators have moved to the outside mirrors, and their place on the body is taken by a stupid shiny badge that says “RXZ” (nowhere else is this X capitalised). If you happen to drive at night with the mirrors folded in, remember to budget an extra few seconds per right turn to recover from temporary blindness after switching on the indicator. 😑

Speaking of shiny badges, the rear hatch now has only a “dCi 4WD” badge instead of the separate RxZ, dCi, and 4WD badges on the old car. The big chrome plate across the hatch says “Duster” in raised letters instead of embossed ones. Also, the wider roof rails now say “Duster” (as does the dashboard, just above the glove compartment).


All three models have different steering wheels, but the differences are minimal. The original design was plain and unremarkable. The one we got is nearly identical, but the horn pad works better (no more presses that fail to activate the horn). The latest design may be a bit nicer to the touch, but tries too hard to make the steering-mounted controls look more interesting.

Both older models have a large cubbyhole above the glove compartment, and a smaller one above the centre console. The facelift does away with these in favour of cooled storage and a closed console. Inexplicably, it does so in a way that still fails to provide a secure flat surface to place mugs of tea on. The lack of storage is a serious impediment—the front cup holders are so tiny and so close to the controls that they can be used to store at most a few coins or perhaps a phone standing on one side. We're glad to have both cubbyholes.

The facelift has two rounded-off rectangular central AC vents on the console, but retains a round vent on each side. The original had four unremarkable round vents with silver outlines and matte-finished dark vanes. The model we got has four round vents too, but the glossy vanes are of appallingly poor quality. They feel flimsy and unpleasant to use, and badly let down the otherwise pleasant interior.

The newer models are upholstered in “Deco Brown” fabric (shades of beige that go nicely with the woodland brown exterior), where the old car had shades of dark grey. The new seats look nice enough to be worth some extra effort to keep them clean.

The outside rearview mirror controls (adjustment only, not folding) have moved from their original position below the parking brake to the block of controls on the driver's door. This doesn't really matter.

That brings us to the end of the comparisons that we can do without starting the car.

What's it like to drive?

The new car has the same engine, the same chassis, the same suspension, and the same steering as the old car. Even the horn sounds the same! So I expected it to feel exactly like the old car to drive. I was wrong.

Somewhere along the line, Renault tweaked the gear ratios significantly. I don't know when, or for which models, but the result makes the new car even easier to drive in the mountains.

The old setup was upshift-happy. You could start from a standstill and be in fifth gear in under a minute at a speed slightly above 40km/hour. If your engine speed dropped to about 1500rpm or lower, you would have to drop a gear or two briefly to build up to a cruising speed again.

The new car is very different. The 3rd and 4th gears in particular are tolerant of a wider range of engine speeds. You can hold on to them for longer and rev higher before you have to shift up. More importantly, you can hold on while the engine revs much lower before you need to shift down. Climbing hairpin turns that we used to take in 2nd gear now feel comfortable in 3rd. You can slow down for traffic or a speed breaker and ease back onto the throttle from 1000rpm or so without shifting down from 3rd. You can do the same thing in 4th gear, so long as you are careful to accelerate gently and don't need to climb uphill right after the obstacle. On good roads that allow for slightly higher speeds, you can spend a lot of time even in fifth gear. It's a truly remarkable change.

Of course, nothing prevents you from dropping gears and getting onto the power early—as the gear shift indicator suggests—but with the long and awkward clutch travel, it's nice to have the option of a more relaxed driving style and also benefit from increased fuel efficiency. Dropping to such low engine speeds and trying to recover without downshifting would result in a lot of juddering in the old car. The new one remains composed. The difference is particularly noticeable on mountain roads, but the new gear ratios should also help in traffic and other situations that call for frequent speed changes.

The inevitable flip side of this change is that the car takes longer to reach highway cruising speeds. Where the old car was sprightly and felt eager to accelerate into the triple digits, the new one is more sedate and likes to take some time to think about it. Once at that speed, it feels as relaxed and composed as ever, but you might need to change gears a bit more often if you intend to dart aggressively through openings in traffic instead of just cruising along.

We spend a lot more time driving in the mountains than on highways, so this arrangement suits us perfectly. A gradual increase in the number of roads in India where one can use cruise control as something more than a gimmick also helps to accept more relaxed highway manners.

Apart from this, the car feels utterly familiar. The driving dynamics are still the same: negligible body roll through corners, stable and responsive handling, and excellent ride quality.

Our review of the 2014 Duster is still relevant for background information.


Apollo claims that the stock Apterra HL 215/65R16 tyres are all-terrain tyres, but they just don't look like it. They're obviously strongly road-biased, and the manufacturer is probably counting on most drivers to do no more off-road driving than an occasional foray through mud or wet grass. Unfortunately, this assumption does not apply to our driving conditions at all.

Still, these tyres seem comfortable enough and behave well on road, at least while they're new. We decided to keep them for however long they last before switching to something with a more aggressive tread (such as the Yokohama Geolandar A/T tyres we fitted on the old car).

Air conditioning

The old car had the worst AC unit we had ever encountered.

It bears repeating here that the redesigned AC vent flaps are so cheap and flimsy that they do not give a good first impression, but it's too soon to say much about the AC itself.

The AC controls don't look nearly as nice as the European version (which gets three knurled silver-and-black control knobs), and while they don't feel nearly as bad as the vents, they are only a few rungs lower on the ladder of nastiness. If you like LEDs, the AC controls have about two dozen between the two knobs and eight buttons. One of these buttons is marked “A/C off”, and it has a red LED that lights up when the A/C is switched off(!).

Reverse parking camera

The reverse parking camera does the minimum required to tick a checkbox on the brochure. It's an improvement over parking sensors alone, but we would have preferred a clearer and brighter image with guidelines that responded to steering changes.

At night, the image is just barely usable if you use your brake lights to illuminate the scene. The reversing lights are not nearly enough to provide any useful detail.

New MediaNAV system

The new MediaNAV is uglier than the old one, but works fine. All we want is to play music from a phone via Bluetooth, and it still does that. The system seems to respond more quickly when you touch the screen.

There is still no dedicated mute button near the screen, and the system now hesitates for a moment when you use the controls mounted behind the steering wheel to mute the audio. On the other hand, going back to play the last audio track used to take some frantic spinning of the selector wheel, but a quick touch now suffices.

We don't care about the inbuilt navigation at all (we never used it), but we can use Google Maps directly on the touchscreen now, thanks to Android Auto support. Unfortunately, the USB port is placed at the top right corner of the screen, and when you plug in a cable, a bit of the connector will block your view of the corner (where the time is displayed). Then, depending on where you put your phone, the cable might obscure some other bits. This unforgivably thoughtless bit of design can be mitigated by buying a cable with a special right-angle USB connector.

The physical AC controls have LED indicators, but the console displays a slightly-delayed and redundant notification of every change anyway. You can turn this off in the display settings.

The MediaNAV manual mentions a “Vehicle” menu with “Eco” and “4x4 info” (realtime compass and inclinometer display) options, but this unit does not have it.


The stock headlamps on the old car were an immediate disappointment. The new ones are much better (still halogen bulbs, and without the projector setup introduced by the facelift).

The one-touch control for the driver's window is handy when you want it, and annoying when you don't. I'm not sure yet which happens more often when I'm driving.


The 2019 RxZ AWD is a welcome improvement over the 2014 RxZ AWD: many good things remain unchanged, some things are better, and only the AC vents are unquestionably worse. The Duster remains a capable car, well suited to our needs, at a reasonable price point.

In short, we got lucky.

Bogus Hindi translations


My annoyance at tortured translations between Hindi and English is not confined to the strange inverted use of until in Hinglish.

Here are some phrases that have suffered terribly in translation in the opposite direction.

कार्य प्रगति पर है

This is the usual translation of “work in progress” on road signs, but प्रगति means “progress” in a larger sense—think “scientific progress”, not “the progress bar is stuck at 95%”. And कार्य is a very grandiose word to apply to construction work, but it's just the sort of Sanskrit-derived word that the powers that be love to slip into official signs as if they were nothing out of the ordinary.

What's worse, “पर है” means “on” in the sense of putting one thing on another. So if you were to translate the sign back into English, “The work is on the progress” wouldn't be too far off. Nowhere else is प्रगति used in a way to suggest that you can put things on it (or in it).

It would be perfectly natural and unambigous to write “काम चल रहा है”, but that's just not officious enough to satisfy anyone.

निजी अस्पताल

Hindi newspapers use this term to mean “private hospital”, but निजी would be better translated as “personal”. It doesn't convey the private vs public sense of being the opposite of a “सरकारी अस्पताल” (Government hospital). When I read about someone going to a निजी अस्पताल, I always imagine them going to their own hospital (which I would too, if I had one).

In this case, I don't know of a better way to say it.

I like volumeicon


My headphone cable has become flaky, so I've been using a small external speaker for a while. I now need to change my volume settings so often that running alsamixer in a terminal each time was beginning to annoy me. So I looked for a systray-based mixer (I use xmobar with xmonad), and I found volumeicon (packaged in Debian as volumeicon-alsa).

I really like volumeicon. The default behaviour is perfectly sensible. Click the icon to mute, click again to unmute. Hover to see the current volume level, use the scroll wheel to change it. Middle click to "Open Mixer", which runs alsamixer in a terminal. Right click to set "Preferences".

What's more, the preferences are also remarkably sensible. You can pick the ALSA device and channel to control, and there's a straightforward menu to change the appearance and behaviour of the icon. volumeicon preferences

It's been quite a while since I encountered a new program that did exactly what I wanted with so little fuss.

Resolving a conflict between manpages-dev and libbsd-dev


I use xmonad, which needs ghc.

On my Debian 9/stretch machine, the manpages-dev package is declared to break libbsd-dev, which ghc depends on. So in practice, one must choose between xmonad and manpages-dev, which has annoyed me for a long time.

Today I tracked down a related Debian bug report and happened to notice that my libbsd-dev 0.8.3 was just one minor revision too old to avoid the conflict declared by manpages-dev 4.10-2:

$ apt-cache show manpages-dev|grep Breaks
Breaks: libbsd-dev (<< 0.8.4-1), manpages (<< 4.13-3)

I also noticed that libbsd-dev 0.9.1-1 packages were available in unstable/sid, and followed the instructions to create a backport of the package to stretch.

$ dget -x
$ cd libbsd-0.9.1
$ sudo mk-build-deps --install --remove
$ dch --local ~bpo9+ --distribution stretch-backports "Rebuild for stretch-backports."
$ dpkg-buildpackage -us -uc

I installed the updated libbsd0 and libbsd-dev packages, and was then able to install manpages-dev for the first time in… several months, at least.

I have manpages again!

Restoring a #4 plane


I, too, have an old #4 smoothing plane that my grandfather gave me.

Unlike some of the other tools I inherited from him, this plane is wholly unburdened by any pedigree—or even a manufacturer's name. My grandfather bought it in Calcutta when I was eleven years old. I knew nothing about planes, but I used it happily for a few years. Then I discovered computers, and the plane went into a box.

Now, nearly three decades later, I need a plane again.

This is my story of restoring an old plane to the point where I could use it. If there's anything to take away from this article, it is that, with sufficient effort, even a poorly-manufactured plane may eventually be made to work well. Was it worth the effort? Well, I have a working plane now. I know my grandfather would have been pleased.


As a first approximation, restoring old tools consists of taking them apart and rubbing the parts against a variety of abrasive substances (sometimes for hours) to remove rust and reshape them until they look and work better.

To learn about plane restoration, I recommend starting with this video tutorial by Paul Sellers, whose focus is to quickly restore a plane to working order. Here's a diagram of bench plane parts; the rest of this article assumes you are familiar with these terms.

General cleanup

The plane wasn't in terrible condition to begin with. Once I wiped off the dust with an oily rag, it took only a few minutes to get rid of a few spots of surface rust on the body with sandpaper. There was some rust on the plane iron too, which I sanded off after soaking briefly in a dilute vinegar solution.

Plane iron

There were two things wrong with the plane iron: it was not very good, and it had been sharpened many times by an eleven-year-old me.

Fixing the damage I had done in the past was not as difficult as I had feared. The bevel was uneven and rounded, there were nicks in the cutting edge, and it wasn't very sharp. Thanks to my diamond sharpening plates, it was just a matter of time and practice to grind and polish a new bevel, relieve the corners, and put a fine camber on the cutting edge.

The back of the iron was nowhere near flat, and the steel was very hard. It took several sessions on the extra-coarse plate to flatten the (last few centimetres of the) back, leaving only two low spots on the corners where the grinding wheel in the factory must have dug in. Removing them would have meant removing a lot of steel, so I stopped there. I did try tapping the back of the iron with a hammer to create a low spot in the centre, so that only the edges would need to be ground flat, but the steel was so hard that it had no noticeable effect.

(Normal sharpening during use subsequently removed enough steel from the cutting edge that the low spots on the back are no longer apparent.)

The leading edge of the cap iron fit poorly against the back of the plane iron. I ground it flat on the diamond plates to eliminate the gaps, and lightly polished the upper surface. I also filed off a sharp exposed point on the thread of the captive screw, which always managed to find its way under my fingernail when I was reattaching the cap iron to the sharpened plane iron.

Lever cap

The lever cap was so poorly machined that it gets its own section here. The cam on the lever was shaped wrong, so that it couldn't be released at all once it was locked down, and I had to loosen the screw on the body to remove the lever cap every time I wanted to sharpen the plane iron. Worse still, the screw didn't hold the lever cap securely—the cap would slide around as I tightened the screw, and end up crooked or off-centred. Even after the screw was tight, the lever cap would sometimes slip off the correct position and come loose.

I flattened the leading edge of the lever cap to improve contact with the cap iron. I tried to file the cam to the correct shape, but I didn't get it right, because it wasn't possible to remove the cam, and access was limited by the flat spring and the body of the lever cap. The best I could do was to make it work "backwards": to lock down in the raised position, and release when lowered. This is rather annoying, but it does seem to work.

As for the other problem, the only solution I have is to hold down the cap firmly when tightening the screw. With the modified cam, at least I don't always need a screwdriver handy to remove the plane iron for sharpening.

The right answer may be to find a used lever cap on eBay.

Body and sole

The sole of the plane was not flat. I put some #150 grit silicon carbide paper on a sheet of float glass and rubbed the plane (with the blade on, but retracted) across it a few times to identify low spots. I had to use the extra coarse diamond plate and #60 grit belt sander paper to flatten the sole just enough to bring heel, toe, throat, and edges into level. I then worked my way back up the grits to polish out the scratches. I also relieved the edges of the sole and heel on the sandpaper.

The face of the frog was not flat. I used #150 grit paper on float glass to knock down some of the high spots, but decided it wasn't worth it to pursue a couple of low spots along the edge. I cleaned up the contact surfaces along the bottom of the frog and on the body too.

The throat opening was not finished evenly, and it had some nicks in it. I used a flat file to remove some of the irregularities, but decided not to remove as much steel as it would take to make the throat straight and square and work out all the nicks. The opening was quite wide to begin with, and the remaining nicks seemed to not matter much in practice.

The wooden parts (tote and front knob) were in good condition, with no cracks or surface damage, so I didn't need to do anything to them.

Things I didn't fix

The sides of the body were not square to the sole. Sandpaper on float glass would have fixed it, but my fingers were threatening to fall off after flattening the sole and the frog, so I didn't bother. I may need to revisit this once I start using the plane on a shooting board.

There's no good way to close down the throat. The opening was wide to begin with, and I had to file it down further to remove irregularities. Advancing the frog causes chatter because the contact points between the frog and body are sketchy. Applying enough abrasives could, in theory, solve this problem, but it's not worth it.

The adjustment knob used to set the depth of cut is a bit awkward to use, partly because the lever cap needs to be cinched down so tightly. Another oddity is that it is on a screw with a normal thread; I believe it's usually reversed, so that rotating the knob clockwise advances the blade. On my plane, it's the other way around. Nothing to do about that but get used to it.

The lateral adjustment lever just doesn't work well. The mechanism has a lot of slop, isn't quite centred, and goes further on one side than the other. I don't know how to fix that.


My plane will never compete with the old Stanley or new Lie-Nielsen #4s of this world, but it does work. I can set it finely enough to take full-width shavings a few hundredths of a millimeter thick, leaving a mirror-smooth finish. Occasionally, I can even plane knotty cypress against the grain without tearing out or leaving gouge marks on the surface. That's far beyond anything I expected from it.

Is it a plane I will use forever? No. But it's a plane I will always remember, and that makes it a pretty special gift.

Relaying from Postfix to gmail


Here's how I configured Postfix to relay mail from through using the credentials set up for on Google Apps.

There are three parts to this: making Postfix relay mail based on the sender address, teaching it to authenticate to gmail, and configuring gmail to accept the relayed mail. (Postfix was already configured to send outgoing mail directly.)

Sender-dependent relay

I created /etc/postfix/relay_hosts with the following contents:

Then I ran «postmap /etc/postfix/relay_hosts» and set sender_dependent_relayhost_maps in /etc/postfix/

sender_dependent_relayhost_maps =

SMTP SASL authentication

I created /etc/postfix/sasl_passwords (mode 0600) with the following contents:

Then I ran «postmap /etc/postfix/sasl_passwords» and added the following to /etc/postfix/

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps =
smtp_sasl_security_options = noanonymous

That enables SMTP AUTH in the Postfix SMTP client and tells Postfix where to look up the username and password for a domain.

Gmail will accept SMTP AUTH only in a TLS session, so TLS client support must be configured in Postfix (which means setting smtp_tls_security_level to "may"). But even once that's done, gmail advertises only the following authentication mechanisms:


I didn't want to worry about OAUTH, so I was left with PLAIN was the only reasonable choice. Postfix will not use plaintext authentication mechanisms by default, so I also had to remove "noplaintext" from the default value for smtp_sasl_security_options.

As an additional precaution, I also set smtp_tls_policy_maps to change the default TLS policy from "may" to "encrypt" for

Gmail configuration

When I tried to send mail through the relay, Postfix wasn't able to authenticate:

SASL authentication failure: No worthy mechs found

SASL authentication failed; cannot authenticate to server[]: no mechanism available

Google considers password authentication to be “less secure”, and you have to explicitly enable it on the less secure apps settings page. There are some other alternatives, but I was happy to take the path of least resistance here.

I did that and tried again, only for mail to bounce with this error:

Invalid credentials for relay []. The IP address you've registered in your G Suite SMTP Relay service doesn't match domain of the account this email is being sent from. If you are trying to relay mail from a domain that isn't registered under your G Suite account or has empty envelope-from, you must configure your mail server either to use SMTP AUTH to identify the sending domain or to present one of your domain names in the HELO or EHLO command. For more information, please visit

This message is misleading, as I found out by using openssl's s_client to establish a TLS session and then authenticating by hand. SMTP AUTH succeeded, but MAIL FROM was subsequently rejected. I followed the link in the message, which led me to the SMTP relay service support page.

The Google Apps admin console doesn't use sensible URLs, but I followed the breadcrumb trail to an “Advanced settings” page where I was able to edit the SMTP relay service settings to set “Allowed senders” to “Only addresses in my domains”, as well as to “Require SMTP authentication” and “Require TLS encryption”. Remember to “Save” the changes.

The error I got was because the “Only accept mail from specified IP addresses” option was checked for this particular domain. I could have added the IP address of my server to the list, but SMTP authentication was what was I wanted to use anyway.

Who invented the slicing-by-N CRC32 algorithm?


One of my contributions to Postgres 9.5 (back in 2015) was a two-stage optimisation of the CRC computation code. First, switching to a faster algorithm; and second, to use the Intel SSE4.2 CRC instructions where available. I was delighted to have the opportunity to implement such a dramatic performance improvement (CRC computation used to be at the top of the profile on every streaming replica by some distance).

Optimising something by writing assembly (even if it was only a couple of instructions, later replaced by compiler intrinsics) is always fun, but here the algorithm change was also a substantial improvement, in that it used a lookup table to process eight input bytes at a time. This technique is known as “slicing-by-N” (where N depends on the size of the lookup table), and was originally described here:

Frank L. Berry, Michael E. Kounavis, "Novel Table Lookup-Based Algorithms for High-Performance CRC Generation", IEEE Transactions on Computers, vol. 57, no. , pp. 1550-1560, November 2008, doi:10.1109/TC.2008.85

This paper, having been published in a prestigious IEEE journal, is of course not easily available for download (not when I looked in 2015, and apparently not today). I was able to find what I needed to implement the technique thanks to other reference materials, notably including Stephan Brumme's Fast CRC32 page (now considerably expanded since 2015), but I never actually got to read what Messrs. Kounavis and Berry had to say about their technique.

Recently, I had occasion to look at CRC32 implementations again, and I found a different paper that I had looked at briefly the last time: Cyclic Redundancy Check Generation Using Multiple Lookup Table Algorithms by Indu I. and Manu T.S. from TKM Institute of Technology, Kollam, in Kerala (my mother's home state in South India). I remember noting that there was something odd about the paper, but not having time enough to give it more than a passing glance. This time, I spent a while reading it, and it's certainly very odd.

ABSTRACT: The primary goal of this paper is to generate cyclic redundancy check (CRC) using multiple lookup table algorithms. A compact architecture of CRC algorithm (Slicing-by-N algorithm) based on multiple lookup tables (LUT) approach is proposed. This algorithm can ideally read large amounts of data at a time, while optimizing their memory requirement to meet the constraints of specific computer architectures. The focus of this paper is the comparison of two algorithms. These two algorithms are Slicing by-N-algorithm and Sarwate algorithm, in which slicing by-N-algorithm can read arbitrarily 512 bits at a time, but Sarwate algorithm, which can read only 8 bits at a time. This paper proposes the generation of CRC using slicing by 8 algorithm. In this, message bits are chunked to 8 blocks. All are processed at a time. Proposed Slicing-by-8 algorithm can read 64 bits of input data at a time and it doubles the performance of existing implementations of Sarwate algorithm.

Is this paper claiming to have invented the slicing-by-N algorithm? It's hard to tell from the blather in the abstract, but going through the remaining blather (and effort that, in retrospect, I cannot in good conscience commend to the reader) suggests that this is indeed the case.

Recently time is the major concern. So in order to process large amount of data at a time, Multiple Lookup based approach is more efficient. Multiple Lookup based approach contains five CRC algorithms, called Slicing by-N algorithm (N ϵ 4, 8, 16, 32, 64), which is used to read up to 512 bits at a time. So performance of the system should be increased. Here proposing Slicing by-8 algorithm to read 64 bits at a time. Here proposed an efficient design of CRC generator using Slicing by-N algorithm (N=8). In this algorithm, input message stream is sliced into N slices and each slice has 8 bits. So using this Slicing by-8 algorithm, it can read 64 bits at a time and it triples the performance of existing implementation of Sarwate algorithm.

Oho, so it triples the performance of existing implementations of the Sarwate algorithm, does it? Funny the abstract claims a paltry doubling in performance then. The paper goes on to describe CRC computation with block diagrams, and then has some more blather about VHDL and MATLAB and some screenshots of “simulation waveforms”, all of which seems to amount to showing that the various CRC algorithms produce the same results and that processing more input bytes at a time is faster than not doing so. I made judicious use of the fast-forward button to reach the conclusion, which begins with

The design of CRC generator using Multiple Look Up based approach is proposed. In this paper, slicing by-8 algorithm is designed, and compares this algorithm with the existing algorithms, that is, with Sarwate algorithm and LFSR method.

So yeah, they're claiming in a slightly roundabout way to have invented the slicing-by-8 CRC algorithm. However, the authors cite the Kounavis and Berry paper anyway, perhaps so that any criticism can be blamed on some sort of unfortunate misunderstanding. I didn't find any citations of this paper in the minute or two I spent on the search, but Citeseer and Researchgate link to it, and it's quite prominent in search results, so it's probably only a matter of time before someone cites it.

The paper was published in "International Journal of Modern Engineering Research” ( in 2012; the journal's name alone reminded me of the scammers, Academic Journals Online, whom I encountered a few years ago. IJMER does not, however, appear to be one of the AJO journals. Perhaps it's a second cousin.

Unfortunately, the authors include no contact information in the paper, so I was not able to send them a link to this page.

Raspberry Pi murder


I wanted to restore a clean Raspbian image on the Raspberry Pi that was running in the battery room. I could have gone and got it, but I would have had to climb a ladder.

So I thought “Why not just remount the filesystems 'ro' and dd the image to /dev/mmcblk0?”

I remounted / and /boot (after "systemctl isolate", which stopped sshd but left my ssh session running) read-only, and dd'ed the image from an NFS mount onto /dev/mmcblk0. The dd worked fine. I used /proc/sysrq-trigger afterwards to sync and reboot (I couldn't run any binaries after the dd, which wasn't much of a surprise). The machine fell off the network as expected…

…and never came back up. So I climbed up the ladder and brought the Pi down to my desk and plugged it into my monitor. It did start to boot, and got a fair distance before the kernel panicked. I didn't bother to try to figure out the problem, just extracted and rewrote the SD card; and all was well thereafter.

But I still think my plan ought to have worked.

Fighting voltage fluctuations


The mains power supply in Lweshal is dismal.

There are frequent outages, of course—the transformer in the village blew up earlier this year, and we had no power for a week. Two or three times in the summer (when forest fires were burning everywhere) a tree fell on the line and cut off power for a few days. There's a big fuse near Mauna which seems to keep melting down. But none of that is really a surprise in a remote area.

The unpleasant surprise was how bad the supply could be when there's no outage. For some reason, extreme voltages are quite common. I've seen the mains voltage at a record low of 25V for several hours once, and we've had whole days when it stayed around 60–90V—voltages so low that the electricity meter stayed off, even though our 9W LEDs inside would light up. Free power!

High voltages don't last nearly as long, but we've seen spikes of 300V and more on occasion. It's difficult to decide which condition is more destructive. High voltages fry appliances, but persistent low voltages where some lights appear to work encourage people to draw more current than their circuits can safely carry—and in a place where people use 1.0mm² wire even for 16A circuits, and nobody has any earthing, that isn't something to be taken lightly.

Either way, voltage fluctuations blew up our UPS twice. The first time we didn't have any sort of voltage regulator installed. After having to pay for a new logic board, we installed a custom-made "constant voltage transformer" (a big auto-transformer with a voltage meter). It clicked a lot to indicate its displeasure, and we had to take it back to the shop to make it cut off the output altogether if the voltage was too low (but why didn't it do that to begin with?). Then the next fluctuation killed the UPS again.

Accurex DPM-3000

In such a dire situation, only a device with a genuine superhero name could possibly save us, and the Accurex DPM-3000 certainly delivers on that front. I bought one from Amazon, and we installed it upstream of the main distribution board. It doesn't do any voltage regulation, just cuts off the output beyond the predefined low and high voltage thresholds. Here is it in action.

Photograph of Accurex DPM-3000

It has worked correctly in various low-voltage conditions (we've had a 130V supply for most of the past two days). It has high- and low-voltage bypass modes that I have never tried, and an optional output timer that restores power to the house only if the power stays on for two minutes. It's useful that it displays the input voltage (even when the output is cut off), and the 32A circuit breaker is very handy when we're working on the distribution board.

Other Amazon customers assured me that the device makes no noise during operation, but of course it does. It clicks away merrily, but it's a small price to pay for reliable voltage limits.

Update (2017-04-23): Our low- and high-voltage records for the Accurex are 43V and 592V respectively (both voltages persisted for some hours before returning to normal).

Namecheap suspended my domain without notification


My mother called to tell me that people were complaining that mail sent to her address at one of my domains ( was bouncing. Here's an excerpt from the bounce message she sent me:

DNS Error: 27622840 DNS type 'mx' lookup of responded with code SERVFAIL

I thought it was just a temporary DNS failure, but just for completeness I tried to look up the MX for the domain, and got a SERVFAIL response. I checked WHOIS for the domain and was horrified to find this:


In a near-panic (because this meant email to one of my work addresses was also being bounced), I checked a bunch of stuff: No, the whois details for the domain were not incorrect (nor had they been changed recently). No, Namecheap had not sent me any whois verification mail about the domain. No, Namecheap had not sent me any notification that it was going to suspend the domain. No, the Namecheap admin page didn't say anything about the domain having been suspended.

I couldn't find any relevant articles in the support knowledgebase, so I opened an emergency ticket with Namecheap support. They responded in an hour, and helped to resolve the problem immediately. They did admit that I didn't receive a notification because of an error on their part:

We have double-checked contact details on the domain in question and registrant details appeared to be missing on the domain due to a one-time glitch at our end. That is the reason you have not received verification email. Please accept our most genuine apologies for the inconvenience caused you.

I have always found Namecheap support to be responsive and helpful. I do appreciate their candour and the prompt response in this case as well, but I am deeply shaken that their system has no controls in place to prevent a domain from being suspended without any sort of notification (especially since they were sending me notifications about other domains registered under the same account in the same time period).

I don't know when exactly the domain was suspended. I have actually lost mail because of this incident—and at least one of them was an important response to some mail I sent. But thanks to my mother's correspondents, I think the problem was discovered before very long. I cannot afford to worry about this happening for my other domains that are up for renewal in the near future. If the same thing had happened to, it would have been catastrophic.

I have been a happy customer of Namecheap for more than five years, and recommended it to any number of friends during that time. Along with EasyDNS (which is much more expensive), it's by far the best of the dozen or so registrars I've used over the past two decades. I have no idea where to move my domains, but I'll start keeping an eye out for an alternative.

Update, moments after writing the above: my friend Steve points out that there's something to be said for having a vendor who admits to their errors honestly; and only a pattern of errors rather than a single incident would justify moving my domains away to an unknown registrar. A few days from now, I hope to be able to properly appreciate Steve's wisdom in this matter. Meanwhile, I'm saved from precipitous actions by the fact that I haven't the faintest idea where to migrate anyway.