<<  Page 3 of 3

Computer fan bearings

When I first got into messing with computer hardware, the received wisdom as regards fan bearings, for cooling fans on computers, was that there were two types, ball bearings and sleeve bearings, and that the tradeoffs were that ball bearings were noisier, but that sleeve bearings tended were less reliable, and tended to fail silently, likely letting the device they were cooling overheat and fail. Ball bearings get a lot noisier before they fail, and were thus the recommended solution for most purposes.

But these days, there are a variety of names for fan bearings. In Newegg’s list, today, of 120mm fans for sale, the various bearing types are described as follows (with each bearing type followed by the number of fan models that contain it):

  • Sleeve (43)
  • Ball (15)
  • 2 Ball (19)
  • 1 Ball, 1 Sleeve (2)
  • Fluid Dynamic (17)
  • Hydraulic (1)
  • Hydro Wave (7)
  • Nanoflux Bearing (NFB) (4)
  • Ever Lubricate (11)
  • EverLasting Quiet (1)
  • Rifle (2)
  • SSO (2)
  • Z-AXIS (1)

Besides ball and sleeve, the principal alternative in that list is “fluid dynamic”. To computer people, fluid dynamic bearings have a high reputation, as being the thing that replaced ball bearings in hard drive spindles, making them a lot quieter. Hard drives no longer make an annoying whine just from spinning, like they did prior to about five to ten years ago (depending on manufacturer).

I disassembled a fluid dynamic bearing from a failed Seagate drive, to see how it worked. (The drive had failed with a head crash; the bearing was still fine.) Disassembling it required grinding, because it appeared to have been welded together (with a tiny, exquisite weld). Revealed was the following (click on the image to see a 4x larger version):

Photo of Seagate fluid dynamic bearing

The main shaft of this bearing is an ordinary plain bearing (aka sleeve bearing): a cylindrical shaft rotating inside a cylindrical enclosure, separated by oil. Nothing special needs to be done to get the oil evenly-enough distributed to separate the two parts, since the shaft naturally drags the oil around with it. The trickery comes at the end of the shaft, where there is a bronze ring shrink-fit on to the shaft, to handle thrust (that is, loads coming from one end of the shaft or the other). This thrust bearing would, in the normal course of things, not have any sort of principle that would restore fluid to the interface; so the bronze ring would touch the steel enclosure. Although bronze and steel are a good combination for bearings, which gives relatively low friction and wear, still, spinning 24 hours a day, they’d wear out quickly if touching. To prevent this, the designers of this bearing have added a special pattern of grooves to the steel surfaces that would contact the bronze, as is visible in the photo; these re-direct fluid that would slip off an edge of the interface back into the middle of it. That way, the thrust surfaces touch each other only on startup of the hard drive spindle, a rare occasion and one during which it is not spinning particularly fast.

But the chances that anyone will ship such a beautiful piece of machinery inside an ordinary computer fan are pretty slim. Indeed, the computer fan bearings which I’ve taken apart, and which have been described as “fluid dynamic bearings”, operate on an entirely different principle. The shaft is the same sort of thing: a sleeve bearing. But the thrust is taken up differently. The following diagram, from a Scythe brand fan (which Scythe describes as having a fluid dynamic bearing made by Sony), is a good example:

Diagram of Scythe fan

Most of those parts are about the same as they would be on a sleeve bearing fan. The fan is held in by a plastic split washer that fits into a groove on the bottom of the fan spindle, as in an ordinary sleeve bearing fan. The porous bronze sleeve, filled with oil, is also usual in sleeve bearing fans. The difference is the “rotor suction magnet”, which takes the thrust load off the plastic split washer. The way computer fans are arranged, the force produced by the wind from the fan is trying to lift off the top of the bearing, on which the fan blades (not shown) are mounted. The magnet overcomes this force, replacing it with a force in the opposite direction, which gets taken on the bottom end of the shaft.

I can think of a couple of reasons why this might be better. One is that the bottom end of the shaft has a larger surface area than the groove which holds the plastic split ring, and so can handle the thrust force better. The flimsy plastic split ring also will bend a bit, likely making the surface area on which the thrust is taken even smaller. Another reason is that the magnet’s strength might be chosen so as to exactly counterbalance the wind force — although the wind force depends on a lot of things, including supply voltage and air pressures, and thus could never be exactly counterbalanced. In any case, the reason isn’t that the bottom end of the shaft sports any particular cleverness; when I took one of these bearings apart, there was nothing like the sort of oil flow channeling that the Seagate bearing had.

But whatever the reason, a lot of companies make such fans, using different names. Of the above fan bearing names, besides “Fluid Dynamic”, the “Nanoflux Bearing” and likely the “Ever Lubricate” bearings use this principle of having a magnet to take up the thrust force. In some designs, the magnet is put below the bottom of the shaft, to magnetically attract the steel end of the shaft. It is thus also sometimes called a “magnetic bearing”, a term which suggests the sort of ultra-expensive magnetic levitation bearing that Iraq was once trying to get hold of for their gas centrifuges for uranium. Such is marketing. As for what the generic name for such devices should be, I suggest “thrust magnet bearing”; it’s reasonably terse, and sort of conveys what the thing is. It won’t wildly excite marketing people, but I don’t think it’ll make them wince, either.

In other fans, ordinary sleeve bearings are described as “fluid dynamic bearings” — which in a sense they are, since sleeve bearings do involve fluid dynamics. The “Hydro Wave” bearing that I took apart was an ordinary sleeve bearing. This seems misleading, but not necessarily in any serious way: on the forum at silentpcreview.com, there seems to be a consensus that sleeve bearings are better than was traditionally thought. My guess is that this is because the denizens of that forum tend to operate their fans at low speeds, where there isn’t much thrust force. Also, even without any additional magnets, the magnetic field loop that is used to turn the fan provides a restoring force against thrust. In some sleeve bearing fans, the fan hub can be pulled out a few millimeters against that force before one hits the split washer that retains it. In those fans, especially in low-speed ones, adding thrust magnets is likely superfluous.

As for “rifle bearings”, the term is strange enough that I’ve ordered a couple of fans with them to see what they are; but one (marketed as an “air rifle bearing”) was just an ordinary sleeve bearing fan, and the other just a magnetically-counterbalanced bearing. The name suggests that either the shaft or its bearing would be rifled, but I don’t see what the point of doing either would be; it could pump all the oil out one end of the bearing, but that doesn’t seem sensible.

That pretty much exhausts Newegg’s list of names, although a couple of oddballs are left. Of course, as I hope was apparent, this article is not intended to be authoritative or up to date; that would be actual work and would cost actual money. It is just the result of having occasionally ripped apart a fan or two, over the years.

Setting text width in HTML

This blog quite intentionally has very little formatting. “Quite intentionally”, because not only does it save my effort, but also lets mobile devices with tiny screens format the text the way they want, without having to fight my formatting. But there’s one piece of formatting code I use: limiting the width of the text column. That is a principle of typesetting that I disliked at first, but eventually accepted: long lines are just too hard to read; the eye too easily loses its place when scanning back to the left to get to the start of the next line.

Though a lot of sites limit text width, usually, from what I’ve seen, it’s done badly:

  • Specifying text width in terms of pixels. This produces annoying results for people with bad eyesight who use huge fonts, and for people who have portable devices with lots of microscopic pixels (such as what Apple calls a “retina display”), and who thus also use huge fonts (that is, huge when measured in pixels). It also can fail for people who have displays narrower than the specified number of pixels, since they can end up with lines that go off the edge of the screen, and need to keep scrolling the screen back and forth for each line that they read.

  • Specifying text width as a proportion of the screen width. This won’t overflow the screen, but may produce columns with annoyingly many or annoyingly few characters.

The best way to specify text width is relative to the font size. HTML provides the “em” unit, which is the width of the character “m”. About 35 of those translates into about 75 characters of average text, which is what Lamport’s LaTeX manual says is the maximum width one should ever use. (Personally, being an exceptionally fast reader, I don’t mind twice that width; but this blog is for other people to read, not for me. And above twice that width, even I start to get annoyed.)

One can set the width using HTML tables to divide up the screen into columns whose width is specified in “em” units; and there’s not too much wrong with that. But a width specified that way might be too large for smaller screens. Fortunately the CSS standard provides a way to set an upper bound on the width, without using tables:

<style type="text/css">
    .foo { max-width:35em }

The above goes in the “head” section of the HTML file. To use that style, one then writes:

<div class="foo">
    Text whose width is to be limited goes here.

It’s simple, and precisely what is needed: it produces a column 35em wide, unless the screen is narrower than that, in which case the column fits the screen. The “class” attribute can also be set for other HTML elements, such as <body> or <p>, so one doesn’t need to add extra <div>s if one doesn’t want to.

Blogging software

The weblog software that people seem to choose by default these days is Wordpress. Wordpress has a lot of features, is widely used and liked, and is offered as a free single-click install by a lot of web hosting providers. But several of the Wordpress blogs I follow have been hacked at some point. When I looked into blogging software, the reason became clear: Wordpress is a large piece of software, written in PHP, a language which originally was designed arose in a world where security concerns were much less significant, and which has addressed those security concerns (and other evolving needs) by adding things, not by a fundamental redesign. (UPDATE: it appears I was being far too generous to PHP in saying that it had been ‘designed’.) The result is a rather large, complicated language, which is hard to learn well enough to master all the security issues. Also, Wordpress uses an SQL database to store weblog entries, comments, and such, which opens up possibilities of SQL injection attacks. The single-click install is easy, but upgrading is not so easy; and if one runs the software for any length of time, one has to upgrade much more often than one has to install.

A lot of other blogging software, too, uses SQL databases to store weblog data. But databases add complexity; for one thing, to back up a database-driven weblog means issuing special commands to back up the database, in addition to doing the normal backup of the weblog’s files. The added complexity might be worthwhile if there were any real need for a database, but there normally are few enough weblog entries that using a file for each one is quite practical; and once written, they seldom change.

I suspect that the reason why blog software commonly uses databases is that PHP makes using SQL easy, and doesn’t make other ways of storing data as easy. In any case, it’s quite inefficient: even though weblog pages hardly ever change, the PHP/SQL combination means that each time a user asks to view a web page, a PHP process gets started up (or woken up), sends queries to an SQL server, receives the results, and rebuilds the web page using them, adding the headers, sidebar, and other formatting that the user has chosen. The sidebars often take further SQL queries. Due to this inefficiency, database-driven blogs are routinely brought to their knees when they draw huge traffic (as in “slashdotting” or “instalanche”). Right when a weblog is getting the most attention is exactly the wrong time for it to fail. There are various optimizations that can improve this — for one thing, PHP can be left running (WSGI) run inside Apache (mod_php) rather than re-started for every request (CGI); and there are also plugins which cache the resulting web pages rather than rebuilding them every time. But installing and maintaining one of those plugins is additional work; and even they don’t bring the efficiency up to the level that static web pages naturally have.

Of course you can easily move a Wordpress blog to wordpress.com, and let them handle issues like caching and keeping the software up to date. That’s how they make their money: by selling advertising on the blogs they host, and/or charging those blogs for premium features. The blogging software they give away is not a revenue source; indeed, if they were to make it too easy to maintain, they’d be sabotaging their revenue source.

I don’t grudge them their revenue — the people who write blogging software do need to eat — but personally, I feel like going to the other extreme. Thus this blog is done in PyBlosxom, a small file-based blogging package written in Python, which I’m using in static-rendering mode, where rather than being run each time someone visits, it is run once and generates all the web pages for the entire blog. PyBlosxom’s default mode has the author writing blog entries in HTML; I’m using a plugin that provides for writing them in Markdown.

<<  Page 3 of 3