Intel randomly enabling and disabling features across their processor lines
drives me crazy. I want to upgrade my fanless Panasonic R3 subnetbook
—based on a Pentium M 1.2 GHz with a max TDP of only 5.5W(!)— to one
with a processor supporting a 64-bit instruction set,
Intel VT-x
for some light virtualization work with KVM, and as low power as possible.
I started by researching the Intel Atom processor family, hoping that
Intel would have made VT-x a standard by now.
My hopes quickly got crushed.
Read this
list of processors supporting
VT-x: it doesn't even make sense. The lowest power Atom processors
Silverthorne and Lincroft (Z5xx, Z6xx) support VT-x but are 32-bit,
while the slightly more power hungry ones Diamondville and Pineview (N2xx,
2xx, 3xx, N4xx, D4xx, N5xx, D5xx) are 64-bit, but do not support
VT-x.
There is really no choice for me but to aim at the Celeron or Core processor
families. After some more research I established a list of the lowest power
64-bit processors, VT-x-enabled, and based on the Nehalem
microarchitecture. Because these processors have the CPU and the GPU on the
same chip, the TDP includes both. I restricted myself to those with a
max TDP of 18W. The next step in terms of power consumption is
25W, then 35W, which is too high to my taste. I also excluded Core i7
processors which are just more expensive i5 models with more cache or
higher Turbo Boost frequencies, which is not worth the premium in my
opinion.
Now remains to find decent subnetbook models using the above processors...
I never thought I would ever witness this, as an end-user of a Linux system,
from a normal shell session:
$ ls -l
ls: cannot access index.pdf.part: No such file or directory
total 2672
drwx------ 2 mrb mrb 91 Aug 13 20:27 .
drwxr-xr-x 53 mrb mrb 4096 Aug 13 20:26 ..
-rw------- 1 mrb mrb 2610918 Aug 13 20:27 index.pdf
?????????? ? ? ? ? ? index.pdf.part
$ ls -l
total 2672
drwx------ 2 mrb mrb 91 Aug 13 20:27 .
drwxr-xr-x 53 mrb mrb 4096 Aug 13 20:26 ..
-rw------- 1 mrb mrb 2610918 Aug 13 20:27 index.pdf
This is a race condition between getdents() and lstat() !
I was using Firefox to download a file called index.pdf.
The browser creates a 0-byte index.pdf file, then downloads the data to
the temporary file index.pdf.part and, when done, renames it to
index.pdf. I just happened to run "ls -l" right before the
rename, so ls obtained the 2 directory entries via getdents(),
but by the time ls tried to lstat() the second file, the rename
had already been performed, so the lstat() call failed with ENOENT.
The first thought that flashed to my mind was filesystem corruption, but
I immediately re-ran ls and it ran fine.
This race condition is probably easy to reproduce with an automated tool, especially on a loaded
system under a random I/O workload, but the fact it happened to me on a
virtually idle system is very surprising 
I just wasted 30 minutes of my time trying to figure out a strange bug in a Perl script generating Atmel AVR assembly code —for a hardware hacking project I will blog about soon. A function was computing an odd parity bit, and it was generating a correct bit only in some cases...
As it turns out, this was due to unintentional backslashes at the end of lines in a numeric expression (the code was copied from a C macro). Judge by yourself:
$ cat broken.pl
#!/usr/bin/perl -w
use strict;
printf "A = %d\n", (1 ^ \
1);
printf "B = %d\n", (1 ^
1);
$ ./broken.pl
A = 135611809
B = 0
I am puzzled as to how Perl is interpreting my code. Why is the backslash causing it to return a non-zero value for "A"? And why, with warnings and strict mode enabled, does Perl think a human writing this code knows exactly what he is doing and would expect this kind of result without throwing a warning.
It is 4am and I cannot think straight. I will revisit this later.
[Update 2010-07-27 11:38pm: the newline between the backslash and the digit 1
was making it less obvious, but a night of sleep made it more so: Perl was treating
this as a reference to 1, and was XORing the value of the reference
—effectively a memory address— instead of the value 1.]
In a
message to the A51 mailing list,
Frank A. Stevenson announced the release of an A5/1 cracker called
the Kraken, capable of using the Berlin set of rainbow tables to
decrypt GSM traffic.
A5/1 has been cracked many times already,
but tools to do so have never been released to the public.
Most recently, in February 2008, David "h1kari" Hulton and Steve Muller
presented at Black Hat their A5/1 rainbow tables built with FPGAs. They
were planning to release them publicly, but never did so for unknown
reasons. I have met David in person and asked him but his response
was evasive. Perhaps they preferred to simply recolt the fruits of their
work by selling commercial A5/1 cracking products.
Because of the lack of public A5/1 cracking tools, the GSM Association
was claiming until very recently that it is not practical to attack A5/1
and that A5/1 is "still" secure enough.
It is in this context that the A5/1
Security Project was started by Karsten Nohl. They wrote code to compute
A5/1 rainbow tables, went through multiple iterations. The last version of
the code is very well optimized to run on ATI GPU cards. They built with
it what is known as the Berlin A5/1 rainbow table set (see
this
post about the story behind the name), which is about 2TB in size.
The Kraken is the first tool able to perform successful lookups in the
tables.
From now on, we can expect the project to focus more on intercepting GSM
frames off the air. People have been intercepting individual frames for
a while with devices like the
USRP, but some hurdles remain to be solved, such as channel hopping.
Nvidia's latest "Intel's Insides" comic made me laugh out loud:
This is a parody of the Nebulae supercomputer
in which 80.1% of the raw FLOPS computing power is provided by
the Nvidia Tesla C2050 GPUs, and the remaining 19.9% by the Intel
Xeon X5650 CPUs.
(This comic could be found at
intelsinsides.com,
except that the domain is now owned by squatters. Nvidia apparently let the
domain registration expire on July 10!)
There was an interesting talk at
Velocity 2010
last week with Tom Cook from Facebook. I particularly enjoyed learning
about how their engineering and operations teams work with each other.
I am a firm believer that excellent inter-team cooperation, and minimizing
the need for communication (or making it really good), are crucial factors
in making a company efficient and successful.
- A global changelog is maintained by engineers and IT when any change is made
on the infrastructure (anyone can look into it, information not segregated
into exclusive mailing lists)
- Internal news portal to announce features, or critical outages
- IRC used heavily (again, anyone can read)
- Nagios and Ganglia are used for monitoring (had to extend Nagios)
- All of the Nagios alerts are fed into other tools to aggregate them
(emails cause too much noise)
- Configuration management implemented with CFengine and sync every 15min
("Puppet is a fantastic option", "Chef is newer and looks great")
- Configuration management should be implemented regardless of how many
servers you run
- Very short dev cycles: code is pushed daily (mostly bugfixes), new features
pushed every week
- Version control everything
- Testing performed by engineers, not by separate QA teams
- Ops people are integrated with engineering teams, and engineering heavily
involved into deploying code to prod
- Advantages: ops people know the applications well and can help
troubleshoot problems, and engineering helps making the deployment successful
(no "commit and quit").
- Instrument everything: hardware, software, OS, etc
Here is the
video
of the talk.
In a technical paper published on June 23, 2010, at the International Symposium
on Computer Architecture (ISCA) in Saint-Malo, France,
Debunking the 100X GPU vs. CPU myth,
Intel —who lacks a high-performing GPU due to their Larrabee GPU project
having been delayed multiple times— attempts to debunk the claim that
"GPUs deliver substantial speedups (between 10x and 1000x) over multi-core
CPUs".
Intel's research paper is seriously flawed.
Read More
Traditional virtualization infrastructures with a need of some type of
shared storage are expensive to deploy and hard to scale up.
Imagine an infrastructure built on a cluster of hosts
running guest systems where each host contributes a fraction of its
inexpensive local storage space to establish a distributed storage system used
across the entire cluster. This storage layer provides advanced features
such as snapshotting, cloning, thin provisioning. Guest disk images are
stored on this system and are therefore accessible
to any host part of the cluster. Imagine also that this infrastructure
has built-in fault tolerance and automatically replicates data to handle
hosts added to or removed from the cluster (as it can happen in case of
hardware failure). Such a system would provide:
- Good performance scalibility at all levels: CPU, RAM, and storage
all scale linearly because a host contributes each of these resources to the cluster.
Whereas traditional virtualization infrastructures are hard to scale up due to
the inherent throughput and latency bottlenecks of a centralized SAN/NAS.
- Excellent reliability due to the fault tolerance and
lack of a single point of failure such as a SAN/NAS.
- Convenient ability to live migrate any guest from any
host to any other host without the need of centralized storage.
- Ability to replace/upgrade 100% of the parts of a cluster,
over time, with zero downtime.
A project to accomplish all the above exists! MORITA Kazutaka,
FUJITA Tomonori, and MORIAI Satoshi, all working for NTT Cyber Space
Laboratories —I am trying to imagine what NTT might be doing—,
started the Sheepdog project for
QEMU/KVM. Their backgrounds reveal these guys are kernel developers,
Xen hackers, and storage experts. They have worked on the kernel block
layer, Xen Kemari (Virtual Machine Synchronization for Fault Tolerance),
the SCSI layer, and much more.
I am very excited to hear about this project. A Sheepdog block driver
for QEMU/KVM has already gone through multiple iterations of reviews.
The latest patch posted to the qemu-dev@ mailing list was
v6 on
June 6, 2010. Hopefully it will soon make it to an official release.
This whole project is very innovative. As far as I know, no other
virtualization vendor offers anything remotely similar to Sheepdog.
|
|
