Art
Computing
Contact info
CV
Electronics
Geek culture
Home brewing
Math
Music
Physics
Rants
Ψ/Φ
Style
Teaching
Theatre
WHAT'S UP
[2016-05-13] Bought via Huuto.net as I was looking for a second laptop for multiscreen gigs. Came with the Ultrabase Series 3. With better CPU+graphics than my current primary T410, this might eventually replace it; they can even share keyboards and my current Mini Dock Series 3. Also, the optical drive bays fof T410 and the Ultrabase are compatible.
As for Gentoo, I simply copied the root filesystem from Willow as it's mostly the same hardware anyway.
I've generally used LILO as some of my machines have problems with Grub. On this machine, though, LILO takes about 10 sec to load the kernel. It may have something to do with the UEFI, more precisely its legacy mode needed for LILO. Strangely, I don't have the LILO slowness issue on other, newer machines.
[2017-10-29] I recently got (back) into Grub for a pure UEFI install on Escher, and I was inspired to try it here too. Besides better automatic config, Grub loads the kernel at the expected sub-second speed. I wonder how this relates to the UEFI bit, as I still use the legacy option. (Proper UEFI booting would need its own partition, and repartitioning this laptop would be extra hassle.)
General caveat on moving from LILO to Grub: the kernel "make install" will run lilo if it is available, thus overw?ri[dt]ing Grub. So better remove lilo altogether, after testing everything works with Grub.
My Julia code has over twice the performance per clock, compared to Willow's i5-520M (Westmere). I thought it would be due to AVX, as my code is heavily vectorized to make use of SIMD, but even binaries I'd compiled for Westmere undergo a similar speedup. Presumably, even SSE* instructions benefit from the wider execution units. On the other hand, being an i3, this lacks the AES instructions of the older i5.
Unfortunately, Linux-PHC for undervolting does not seem to work :-/ Combined with lower thermal limits, this means it is harder to achieve maximum performance; with full load, the fan has a hard time keeping it safe.
While plain acpi_cpufreq works, it seems the P-states driver is preferred for Sandy Bridge and newer Intels to access deeper power saving stages when idle. Unfortunately, it has a couple of problems:
[2018-04-04] With Escher I use the neat method of embedding the firmware in the kernel. This avoids the initramfs mess, among other benefits. Alas, it appears to break suspend-to-RAM. I don't remember the source, but that would explain my recent suspend issues, so I'm back to the initramfs way on this machine.
Frankly, the situation is a little hairy: the initramfs approach breaks booting on pure UEFI, the in-kernel way breaks suspend to RAM. Currently, I don't have the two on one machine, but it could happen...
As in Willow. The temperature sensor data location had changed, so I modified the fan and autosuspend script to work on both Thinkpads.
[2016-05-28] The script now includes CPU frequency throttling at the higher end of temperatures. It uses the "Processor" cooling device, so it too works on both machines.
As in Willow. This seems to be the last generation before the newer chicklet keyboards.
[2018-08-22] H.264 decoding on Intel HD is available via VAAPI, which is less widely supported than VDPAU. There are projects bridging the two, so that VDPAU-aware players can access the hardware via VAAPI. I have tested one of these in the past, but they have their own issues, not to mention the whole Rube Goldberg feel of stacking APIs.
I have recently tested mpv which can use VAAPI directly, and it seems to work quite well. This is a welcome feature, since the CPU chokes on heavier files such as Full HD at 60 FPS. Vlc should also work, but I have not tested it properly as I prefer plain commandline players.
The sin/cos functions in GLSL are buggy in this GPU. One example is described elsewhere for HD 4600. This is a real drawback from my earlier Intel HD (Westmere), although generally speaking the speedup does not have such quality penalty.
In my applications, the most notable discontinuities occur far from zero, so I worked around it with mod:
const float pi = 3.1415926535897;
const float twopi = 6.283185307179586;
float my_sin(float x) {
return sin(mod(x - pi, twopi) + pi);
}
While this works, having to do it is embarrassing. It's basically the
first step in writing trig functions from scratch efficiently.
The GPU heats up considerably under heavy load, so CPU-heavy applications should be avoided at the same time. Preferably, use a CPU throttling application such as thermald or my script above.
[2017-10-29] There's also a much smaller error which is not corrected by this mod trick. It also occurs on HD Westmere and 630, which don't have the larger issue. For me, it only shows up at small details after multiple iterations, so it is not a show-stopper. Nevertheless, proper GPUs don't do anything like it.
See Willow for display control buttons.
As in Willow.
As in Willow, but needs iwl6005-ucode instead.
As in Willow.
Parallels Willow. The full scientific name would actually be Salix velox to indicate the speed upgrade. In Finnish this makes a punny name "Vauhtiraita".