i386 vs custom compiled i686 kernel?

[Benergy]

Good evening.

This is my first time posting here so hello from south-east Queensland, Australia!

First, a little background. I work in IT as a technical support engineer for a small MSP. My experience is almost solely Windows and Windows Server, with intermittent short bouts of Mac and various Linux distros over the years.

I'm after a change. Windows gets worse with every release. I can't stand it any longer so I've done my research and Debian is where I've landed. I know it's not the first choice for somebody new to Linux, but I've got a little Linux experience already and I'm a want-to-be-retired Windows power user looking for a challenge.

The challenge gets more interesting: I've got an old Sharp Actius MP30 netbook from the early 2000s. It runs a Transmeta Efficeon TM8800 processor clocked at 1.6GHz, the fastest variant released to the public from what I'm aware. I've upgraded the ram to the maximum 1GB PC3200 single channel and 128GB SSD (IDE/PATA). The video card is a Radeon Mobility of the era. Again, not the easiest option for somebody new to Linux but I'm up for a challenge and keen to learn.

Now to my primary question: If I obtain/compile (I've never compiled anything Linux from source) a kernel specific for my Transmeta Efficeon processor, will I observe better performance? I understand the earlier Transmeta Crusoe processor wasn't quite 'instruction complete' in regards to it's i686 implementation, but was much more than i586 compliant - similar to the AMD Geode. I am assuming the Efficeon processor is the same (information is difficult to come by). I'm currently using an installed copy of Debian Live 9.1.0 i386 lxde as it seems the most compatible/lightest for this machine as far as 'unflavoured Debian' goes. Custom compiled kernel info link: https://bbs.archlinux.org/viewtopic.php?id=99152

In addition to my primary question: I've noticed in my console it says "Linux localhost 4.9.0-3-686 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) i686". Does this mean I'm in fact running some i686 optimised variant of Debian x86 which expects full i686 compliance and not i386 as the download said? I've also read that compiling a non-SMP build will provide additional performance - is this true?

I'd just like to get Debian running faster than Windows XP did on this machine - which I believe Debian 9 + lxde should be lighter?

I won't add anything additional to this wall of text, despite having further questions.

Mods - please move this to the appropriate forum if this is too in-depth for 'Beginner Questions'.

Thanks for your time! Enjoy your evening (or day, wherever you are).

Ben

[steve_v]

I'm a want-to-be-retired Windows power user looking for a challenge.

You might just get one, with that hardware. It's old and not very common, so you'll likely have to try it and see. If it will boot and run an i686 Debian livecd, roll with it.
That old AMD GPU might get interesting too...

If I obtain/compile (I've never compiled anything Linux from source) a kernel specific for my Transmeta Efficeon processor, will I observe better performance?

Back when my main machine was a VLB 486 with 16MB, a custom (read: stripped down) kernel was a big performance boost, mostly due to memory constraints. These days, I'd not bother.

Custom compiled kernel info link: https://bbs.archlinux.org/viewtopic.php?id=99152

Call it a hunch, but I suspect you are in for a world of hurt trying to get Stretch to run properly on a 2.6.x kernel. No harm in trying though.

Does this mean I'm in fact running some i686 optimised variant of Debian x86 which expects full i686 compliance and not i386 as the download said?

True i386 support was dropped last year. i386 == i686 now.

I'd just like to get Debian running faster than Windows XP did on this machine - which I believe Debian 9 + lxde should be lighter?

Maybe. IME (1.6GHZ dual-core atom/2GB is the closest I have to that hardware), XFCE offers comparable performance to XP. LXDE should be lighter than that.
Bear in mind that you're comparing software that's 16 years apart though, expect no miracles.
If LXDE is still too slow / memory hungry, you might run a bare window manager, such as openbox.
Your biggest performance woes will probably be trying to run modern apps, on my netbook Firefox uses more memory than the whole operating system. Kernel optimisations are a drop in the bucket.

Somebody with similar hardware might emerge from the woodwork, but be prepared for a bit of experimentation yourself - that 's a pretty oddball machine you have there.
If Debian doesn't fly right for you, I believe there are still a few distros around that produce an i486 or i586 build. DSL runs fine on my 486, but that might be getting a bit extreme.

Good luck.

[Benergy]

Good morning, steve_v.

Thanks for the detailed response! Yes the live cd did boot and I successfully installed 9.1.0 to the internal SSD. It's slow but it works. It'd probably be quicker if it didn't have the GUI overhead running on the processor rather than the Radeon mobility graphics but I'll get to that later.

I'm thinking the Efficeon processor it much more x86 i686 compatible than it's predecessor, Crusoe. Here's some more info:

The Efficeon processor is Transmeta's second-generation 256-bit VLIW design which employs a software engine to convert code written for x86 processors to the native instruction set of the chip (Code Morphing Software, aka CMS).

Efficeon most closely mirrors the feature set of Intel Pentium 4 processors, although, like AMD Opteron processors, it supports a fully integrated memory controller, a HyperTransport IO bus, and the NX bit, or no-execute x86 extension to PAE mode. NX bit support is available starting with CMS version 6.0.4.

Internally, the Efficeon has two arithmetic logic units, two load/store/add units, two execute units, two floating-point/MMX/SSE/SSE2 units, one branch prediction unit, one alias unit, and one control unit. The VLIW core can execute a 256-bit VLIW instruction per cycle, which is called a molecule and has room to store eight 32-bit instructions (called atoms) per cycle.

The only unusual behaviour I've noticed is some screensavers which likely rely on OpenGL I'm guessing.

I've investigated which releases used Kernel 2.6 which seems to be Debian 4,5,6 with some releases of 3.1 having it as an option. Since I'm thinking the Efficeon is i686 specification complete, I don't think the custom kernel will be necessary or beneficial to performance? Unless a uniprocessor kernel can help things along. Your DSL suggestion might be the best option! I've read "DSL has built-in scripts to download and install Advanced Packaging Tool (APT). Once APT is enabled, the user can install packages from Debian's repositories" which is nice to read!

I'll download DSL and take it for a spin. Then I'll look at this Radeon mobility situation. I remember Radeon support used to be very poor about 10-11 years ago when I first started playing with Ubuntu.

Are there any suggested CPU benchmarks I can use to compare distros on this machine?

Thanks for your time!

Ben

[stevepusser]

The usual suggestion to get ATI/AMD graphics working well is to install the non-free firmware-amd-graphics package. (firmware-misc-nonfree before Debian 9) Installing inxi and then running

Code: Select all

inxi -G

can give you information on the current state of your graphics driver/

[steve_v]

Since I'm thinking the Efficeon is i686 specification complete, I don't think the custom kernel will be necessary or beneficial to performance? Unless a uniprocessor kernel can help things along.

I'm tempted to agree here, the standard debian kernel configuration is a fairly sensible one.
SMP does introduce some locking and synchronisation overhead, but I'd anticipate it being fairly minor.

If you want to suck it and see, recompiling the kernel isn't difficult, and a kernel compile has been my standard CPU benchmark for years.
Also, many interesting knobs to tinker with, if you like that sort of thing

Are there any suggested CPU benchmarks I can use to compare distros on this machine?

As above, time to compile a kernel... though said kernel has grown to the point that it may not be very time-efficient these days. sysbench is probably a better option.

As for your GPU, I vividly recall ATIs drivers being a steaming turd, but much has changed since then.
If you have the chip I'm thinking of, the proprietary AMD/ATI driver no longer supports it. You likely want the open source radeon driver, and as Steve suggests, it's associated firmware package.

[Benergy]

Good afternoon, Gents.

Apologies for the delayed response, we've just had a long weekend here in Australia so it was spent with family and friends.

I tested DSL on Friday and it performed very quickly, as expected. However, I was unable to get my wifi adapter working (connected to my SSID) despite researching the topic for a while and following the exact instructions others have said worked for their DSL. All I had different in my config was wifi channel 1 versus channel 6 on their setup and their wifi was unsecured where as mine was WPA2. Maybe DSL is a bit outdated but I haven't looked any further into it yet.

I installed VIM yesterday and configured my sources.list to allow non-free and got firmware-amd-graphics and inxi installed. The results when I run inxi -G (from within X, otherwise I received an error saying to use X) are as follows:

Graphics: Card: Advanced Micro Devices [AMD/ATI] RV200/M7 [Mobility Radeon 7500]
Display Server: X.Org 1.19.2 drivers: ati,radeon (unloaded: modesetting,fbdev,vesa)
Resolution: 1024x768@60.00hz
GLX Renderer: Mesa DRI R100 (RV200 4C57) x86/MMX+/SSE2 DRI2
GLX Version: 1.3 Mesa 13.0.6

Does this suggest it's running the ati, radeon driver successfully? I'm not sure if I'm interpreting the output correctly.

Sounds like it's time to get my hands dirty and "roll my own" kernel. I'll try and figure out a uniprocessor compile and then use it as a benchmark across a couple of different distros/configs to determine which performs the quickest.

Thank you for your assistance so far, it's much appreciated!

Ben.

[Segfault]

Re: kernel
You can build your own kernel, it will preserve some RAM and it will be [marginally?] faster.
Start with make allnoconfig, then do make nconfig and start turning options you need on. Prepare your mind for a long day. Have some stuff ready to keep your brain from overheating. Candles and black robe are optional. In the end you will know alot more about hardware than you knew before. I went thru this long time ago (BTW, there was no allnoconfig back then) and I have no regrets. BTW, in Gentoo we have a kernel patch that allows for -march=native, meaning the kernel code will be optimized for your CPU.

[stevepusser]

Yes, that inxi output show that the radeon driver is installed and working.

[Benergy]

Re: kernel
You can build your own kernel, it will preserve some RAM and it will be [marginally?] faster.
Start with make allnoconfig, then do make nconfig and start turning options you need on. Prepare your mind for a long day. Have some stuff ready to keep your brain from overheating. Candles and black robe are optional. In the end you will know alot more about hardware than you knew before. I went thru this long time ago (BTW, there was no allnoconfig back then) and I have no regrets. BTW, in Gentoo we have a kernel patch that allows for -march=native, meaning the kernel code will be optimized for your CPU.

Thanks! I've done some reading and concluded that make allnoconfig and make nconfig should help me finely tune the kernel with just what I need After reading your comment about the Gentoo kernel patch for -march=native it got me thinking... will it even identify the microarchitecture of my processor? Then I started reading GCC optimization and pouring over the source for cpuid2cpuflags for further answers before stumbling onto Transmeta Efficeon TM8600 CHOST & CFLAFS in make.conf? in the Gentoo forums and found the following:

for CHOST use i686. There is no Efficeon specific march in gcc so set march=i686 in your cflags. -pipe and -fomit-framepointer are safe to use. -0s, -01, -02 and -03 are all safe to use in cflags, pick one. The Efficeon TM8600 has mmx, sse and sse2 so you can set those in your USE flags or cflags as -mmmx, -msse and -msse2.

I think with the suggestions I've received here I'm heading in the right direction! In the meantime, the machine is folding@home for stanford. I've run init 3 to close X and free up resources for the folding@home console client. I have a second console session running nmon to keep an eye on things.

Yes, that inxi output show that the radeon driver is installed and working.

Thanks for confirming this. Much appreciated!

I'm going to do some further reading shortly about compiling my own kernel so I have everything ready to get started. Thank you very much for all the help so far, guys

[Segfault]

The thread from Gentoo forum is 13 years old. Back then gcc did not have -march=native option. Since gcc-4.<something> you can use -march-native, to see what it does you can run

Code: Select all

gcc -march=native -E -v - </dev/null 2>&1 | grep cc1