Robert Pogson

We have known for many years that the future lies in cheap, good-enough CPUs. What do Intel and AMD crank out? Hearts for super-computers.

Wake up, folks. We read that ASUS is awash with Atom CPUs and is dumping them in China where they are good enough. Intel is upset that this reduces the market for high-powered CPUs.

I have been writing on these pages for years that China is a key market. This is more proof. The world will produce what China wants in software and hardware. China wants low-cost/power/heat CPUs and Free Software. They will get it whether Intel supplies them or leaves it to VIA/ARM/home-grown stuff.

What are the Chinese doing with Atoms, besides netbooks? Not much except cranking out ever-lower-cost netbooks that are good enough for browsing/word-processing. ARM is in the mix too. Atom has to be priced as low as ARM to keep share for Intel and Wintel. It is not. The market will decide no matter how much Wintel twists the arms of OEMs. Entrepreneurs in China have no interest in being co-opted by Wintel when they have a market in hand for all their production for years to come. The Chinese market is several times the size of the USA and netbooks are good enough for what they want. Why even try to sell fire-breathing dragons there?

The neat thing for me about China is that because they demand low-cost computing, GNU/Linux has the inside track. The newly announced pricing for that other OS prevents it from competing with GNU/Linux in this market. If they keep the price low in China, other countries will demand similar treatment. It is almost over, folks.

Normally, I stick to information technology in this blog but I have flown hundreds of thousands of miles in my life  in many kinds of planes and a helicopter so I have intense feeling about air travel.

The destruction of the plane of Air France over the Atlantic a couple of weeks ago is a great tragedy for all involved but it is also a great failure of mechanical technology. Like many such disasters, it likely involved an improbable combination of failures that took the plane outside the cone of survivability. A recent article, ”
Intact tail fin offers clue to Air France crash
” seems to have pegged one of the critical points of failure, over-stressing the tail fin. There have been several crashes involving similar failures but this article points out that a combination of assaults can still bring down planes.

Normally, planes are designed to fly in a smooth stream of air and the rudder is just part of the drag the tail provides to keep the plane going nose-forward. In a cross-wind landing, the rudder might be used to offset a turn of a few degrees from nose-on. Pilots practise many hours getting the feel of their planes countering such effects automatically. It seem likely, that in the turbulence of a storm over the Atlantic, the rudder may have been applied inappropriately breaking the tail fin off. Without that drag and stabilization, the fuselage may have broken apart by turning normal drag into a component of 500 mph cross-wind. The fuselage is strong and light, like an egg shell. As long as forces are distributed uniformly/smoothly, it stays together, but when turned too far from nose-forward it can collapse and tear apart. The distribution of tail fin, bodies, and other debris suggests this is what caused the plane to break up.

The layers of failures that got the plane into this situation still remain unknown but trying to punch through a storm instead of going around may have been the first. Radar can spot precipitation but not winds (except Doppler radar) and the crew may have bitten off more than they could chew. The storm reached far above flight level and was part of a chain so punching through may have seemed like the best strategy with the information available. Uncertainty about the reliability of the air-speed sensors (pitot tubes) may have been a factor, killing computer control in the face of conflicting information but computers had been tasked with limiting stress on the rudder…

Let us hope the black boxes are found to provide sufficient information to describe the behaviours of the equipment and the air with greater certainty. Let us hope this teaches humanity some lessons to prevent future failures. It seems past tragedies were not enough. While the media have made the assumption that people died promptly, it is quite likely that many died a horrible death being mutiliated by strong aerodynamic forces on pieces of fuselage or falling over a minute from high altitude in darkness. We should take no comfort from fuzzy ideas of a quick death during the destruction of a plane. We must resolve to prevent such tragedies in the future.

I know automobiles kill and maim far more than planes but planes have a unique ability to allow one to contemplate imminent death. It has been a recurring nightmare in my life. Now that I travel less, I hope that I will never be in a situation like that. My sympathies are with people who fly.

UPDATE 2009-07-02

A preliminary report as reported in the news media gives some semi-solid information:

• based on study of debris the BEA is leaning to the conclusion that the plane broke up on a belly-flop in the sea
• the BEA was unable to access autopsies done by Brazil
• Senegal and Brazil give contradictory accounts of the handoff  by ATC.

The first conclusion seems off-base to me. If the plane flopped, there should have been a few survivors. No life preservers were deployed. What happened to the half-load of fuel that would have been on board? Why were bodies scattered over 50 miles a few hous after the crash?

One of the clues was damage to the shelves in the galley. If the galley had separated at altitude and fallen in that orientation at impact, would not the shelves have had the same damage?

We need more explanation. This sounds like an imcomplete report or a report based on incomplete data. We shall see as more comes out.

see

• Article 1
• Article 2
• Article 3 (with link to the actual report)

Reading the actual report does install some cnfidence that they are doing the best they can with the information available but it does have some shocking detailes:

• news reports supporting the idea of a high-altitude breakup said the victims were found naked. The report says the victims were found clothed.
• it was many days before victims or wreckage were found. The circle of debris was many kilometers in diameter.
• the crash happened near the boundaries of ATC regions so it was many hours before an incident was declared.
• impact was in a normal flight line but on the belly. Did the plane lose altitude information and fly into the ocean?
• automatic signals indicated the engines may have been set to idle…
• other planes sent radio messages about diverting a few kilometers to get around storms just before and after the crashing flight. These folks did not.

This is absolutely wierd. Did the plane have a stall at low altitude? Were they trying to ditch? Did they dive to recover from decompression but overdo it? How did they drop thousands of feet and not have time for an SOS? Why did they not find the black boxes?

This is a huge mystery folks. Does it have to happen again before it can be figured out? If the plane belly-flopped, will a large enough piece be down there to be spotted on high resolution sonar? How could the circle of debris be sol large so quickly if the breakup was on impact?

My son is a computer geek like me. He was a slow starter. He did not get into it until he was a teenager but he has an annoying habit of doing things before I do, reminding me all the time that I am slowing down…

He was the first in our family:

• to build a PC from OTS parts,
• to use a 3gHz CPU,
• to use more than four hard drives in a box,
• to use multi-core CPU, and
• to use dual socket motherboard.

Of course, I am proud of him but it still bugs the geek in me that I cannot stay ahead of him.

However, there is occasional joy in my family relations, like when, a few times a year, he writes, “Dad, how do you…?”. Hah! I am still useful!

Last week, after I returned from the annual teaching battle, my son said, “Dad, I am getting this weird message and Google does not help…”.

too many iterations (6) in nv_nic_irq

Lo, it was a problem using the forcedeth driver that I had encountered and overcome two years ago. I gave him hints that worked promptly to end an annoying instability in a server running GNU/Linux. Apparently, the information that I found to solve the problem was no longer on the web so we will document it here.

The problem is that forcedeth.c which is a reverse-engineered driver for an Nvidia NIC has a problem dismissing an interrupt, that is, clearing the interrupt flag so that the CPU promptly interrupts again when the driver returns control. To slow down this tight loop the authour put in a timeout which wreaks havoc in some production systems. There are parameters that can be configured to control the interrupt behaviour.

Here is the code.

* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
* This means recovery from netif_stop_queue only happens if the hw timer
* interrupt fires (100 times/second, configurable with NVREG_POLL_DEFAULT)
* and the timer is active in the IRQMask, or if a rx packet arrives by chance.
* If your hardware reliably generates tx done interrupts, then you can remove
* DEV_NEED_TIMERIRQ from the driver_data flags.
* DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
* superfluous timer interrupts from the nic.

…

/*
* Maximum number of loops until we assume that a bit in the irq mask
* is stuck. Overridable with module param.
*/
static int max_interrupt_work = 5;

/*
* Optimization can be either throuput mode or cpu mode
*
* Throughput Mode: Every tx and rx packet will generate an interrupt.
* CPU Mode: Interrupts are controlled by a timer.
*/
#define NV_OPTIMIZATION_MODE_THROUGHPUT 0
#define NV_OPTIMIZATION_MODE_CPU        1
static int optimization_mode = NV_OPTIMIZATION_MODE_THROUGHPUT;

/*
* Poll interval for timer irq
*
* This interval determines how frequent an interrupt is generated.
* The is value is determined by [(time_in_micro_secs * 100) / (2^10)]
* Min = 0, and Max = 65535
*/
static int poll_interval = -1;

So, the usual recommendation is to bump up the parameter, max_interrupt_work. I found that did not work well because these machines are so fast. What value would be large enough? Trial and error improved things but it was still flakey. This was on a machine with 8 processors. We could easily afford to poll the device to service the NIC…

We set

options forcedeth optimization_mode=1  poll_interval=100

in /etc/modprobe.d/options followed by rmmod  forcedeth; modprobe forcedeth  and everything was sweetness and light. No more freezes or crashes serving files at gigabit/s speeds.

How cool is it that old Dad could steer a young man towards the answer to a geeky problem in seconds?

While ASUS says that other OS is best, ACER merely recommends it. I am not sure what the difference is but ASUS sounds like a sell-out to me while ACER seems to be reflecting the comfort zone of people.

It is easy to find GNU/Linux on ACER’s site if you look for the 8.9inch netbook. News out of Taipei  is that

“Acer is in the process of putting Moblin in the range of its products,” said R.C. Chang, chief technology officer at Acer, at a news conference in Taipei. Acer products that will soon run with Moblin Linux include Aspire One nettops, as well as regular laptop and desktop PCs, he said.

ACER may be just hedging bets but is seems a more friendly way to do that than what ASUS did. ACER is selling like hotcakes and is eating Dell’s lunch. ACER is seriously into supplying netbooks to ISPs.

see this article