| Eee PC 1000HE arrived | Created: 31.05.2009 12:35 |
|
As sort of a reward for finally doing my tax papers, I got
myself an ASUS Eee PC 1000HE. That is an 10 inch Netbook with
an Atom N280, 160 GB HDD and 1 GB RAM - and not to forget:
a non-glossy display. Unfortunately, unlike its predecessor
the 1000H, it is only available with Windows XP home
preinstalled. But as the hardware is practically identical
to the 1000H except the slightly faster CPU and the larger
battery, Linux works flawlessly on it. With
Ubuntu 9.04 Netbook Remix
everything works out of the box, including suspend to RAM and
disc, WLAN, even the Webcam. What is particularily attractive on this netbook is the long battery life. ASUS claims 9.5 hours, but of course they measure that under Windows, with a display brightness of 40% and everything, including WLAN, disabled. That is not a very realistic usage scenario for me, so first thing for me after installing Linux was to make my own measurements of the battery runtime. In both tests, bluetooth and the builtin webcam were deactivated in the BIOS. In both tests, WLAN was on, but the actual network connection was through cable. Display brightness was set to 60 to 70 percent. That in my opinion is "normal brightness" for the rather good display, i.e. the brightness you would use if you want to actually see something and not preserve battery life. Turning the display up to 100 percent does not make sense, it's just too bright. The first test was basically "idleing". All that was running was an IRC client. Normal power saving was active, so it did dim and turn off the screen eventually. In this scenario, the battery lasted for 7.5 hours before reaching "critically low" level. The system then went into "Suspend to RAM" as configured. I was able to wake it up from there another 1.5 hours later. I find both the runtime and the fact that it lasts for ages in the Suspend mode pretty impressive. The (De*l) laptop I have from work hardly lasts two hours and only few minutes more in "Suspend to RAM". The second test was sort of a "worst case" scenario: Playing back a video (recording of a DVB-S stream at around 900 KByte/sec in pal plus) while running burnMMX in the background. The video was too large to fit into cache, so it was actually read from the hard disc, meaning the disc was not under stress, but could not go to sleep either. The fan was pretty loud during that test, in fact I haven't got it to turn up this far during normal use. But even in this very exaggerated scenario, it survived for 4.5 hours. There is something I do not like though: You cannot currently buy any (original) spare batteries for the 1000HE - "the internet" tells me ASUS always takes many months to release the spare parts. Bottom line: I really like my new netbook, and I find it a shame that I have to read on heise.de that ASUS seems to have plans to discontinue the 1000HE in favor of a new model with a crappy glossy display and less battery life (sorry, article is in german). How braindead can managers be? No wait - not only since the banking crisis that is a rhethorical question. |
|
|
no comments yet write a new comment:
|
|
| ntpd related linux kernel patch | Created: 10.05.2009 19:17 |
|
Recent linux kernels exhibit a problem in combination with ntpd: ntpd takes far
(read: an order of magnitude) longer to get the clock in sync with the
correct time than on other operating systems or older linux kernels.
Up to now, this has been an annoyance, but apparently not annoying enough
for anyone to bother - after all, the clock is only wrong by a few split
seconds, and ntpd will manage to sync it up eventually, although it will
usually take a few hours. The only people really noticing it are probably
the ones having refclocks, as network latency usually is higher than the
error. An excemption to that is when computers are run in an environment where
temperature is unstable, because that results in changing frequencies in
computer parts, meaning: the clock will start to drift notably, and because
ntpd is too slow to correct it in the proper way (by speeding or slowing the
clock a little) some little time jumps like on startup may occour. Luckily, this annoyance should be over soon, because John Stultz was annoyed enough by it to finally track it down. You can read about his findings in this post on the linux kernel mailing list. Bottom line: The misbehaviour is caused by the rewritten time infrastructure in the linux kernel, and a parameter needs to be tweaked to get back to normal behaviour with the nanokernel. This is a one line kernel patch that in my opinion cannot get into the kernel soon enough. Until then, on linux kernel 2.6.19 to 2.6.29 you can do the patch yourself: open include/linux/timex.h in the linux kernel source tree, locate the line that says #define SHIFT_PLL 4 and change it to #define SHIFT_PLL 2. Then (re)compile your kernel. Although I have not done any proper benchmarks, the results I have seen so far were very impressive - ntpd will sync within an quarter of an hour now, instead of the many hours it took without the patch. I really hope this goes into the kernel ASAP. |
|
|
no comments yet |
|