NetWinder Office Server
If you haven't seen RISC assembly code before, it may be strange to see so many operands on a single line. After all, CISCers are used to simple syntax like MOV A,B (or MOV B,A). RISC technology, by comparison, allows you to specify several operands on a single line as well as communicate more than just the usual relative, absolute and immediate addressing information. Although many hackers these days avoid learning assembly code (ESR recommends C, Python, Perl and LISP in his advice on how to be a hacker), it is difficult to appreciate operating system design without such knowledge. Of course, someone has to know it or nothing could get implemented. When porting Linux to a new platform (such as StrongARM), assembly code is more important than is usually the case.
One fault of Linux that Tanenbaum criticized (not the least politely) back in 1992 was that Linux was platform-specific, that is, a monolithic kernel for Intel 386. Today, Linux has been ported to several hardware platforms, and the kernel is more modular. We need to be familiar enough with assembly code to be able to do the porting and debugging work, and we must not get too dependent on it, lest we write too much platform-specific code. The idea is, Linux is superior to any hardware platform, so we use a cross-platform assembler (meaning C) for the code and limit our involvement with the specifics of the chips. (This way, when the x86 dies, Linux lives.) Nevertheless, RISC chips are simple, with only a few instructions, yet one can do so much on a single instruction. RISC technology, particularly in the context of parallel processing, is affiliated with the microkernel, and hopefully we will see more of both in the future. In the meantime, let's get back to the chip.
The StrongARM SA-110 has the following features:
16 32-bit registers for user programs (r0 through r15)
21 basic opcode types, including 63 of what we would typically consider opcodes in the CISC world (which when multiplied by 15 conditionals would represent 945 instructions), with a host of other operations available
one of fifteen conditionals available for every opcode
2.1 million transistors (RISC economizes on transistors, which is a bit ironic these days)
32KB of cache (16KB for instructions, 16KB for data)
a 233 MHz operating speed, overclocked to 275 MHz on the NetWinder for 250MIPS (million instructions per second)
The SA-110 has no math coprocessor. The chip performs extremely well on tasks where the instructions and data can be entirely cached and no floating-point operations are involved. Tasks involving too much code and data to make use of the cache become slow, and floating-point operations grind the chip to a halt. While some of these differences have to do with how well the Linux kernel and gcc jive with the chip set, without an FPU, a chip is disadvantaged (but the StrongARM excels at floating-point emulation, if you code specifically for it). If you check out the benchmarks (see Table 1), you can see how scattered the results are. I would not rest too much on them; the machine is quite perky, despite its typically lower than K6/233 scores. My favorite benchmark, the chess test, has NetWinder evaluating between 17 and 19 thousand positions every second (about one million per minute). Rebel.com expects to have 600MHz StrongARMs soon, and if the micro-architecture techniques get seriously improved (low power consumption and desire to avoid pipeline stalls make speculative execution and multiple branch prediction respectively impractical, though unique qualities of ARM could make other tricks possible) and the processor visits the debugger, future NetWinders should be much faster. (But then again, how much processor power do you need for e-mail, web, file, print, FTP and TELNET services?) The machine in question has 64MB of memory (34.8MB free), with most services turned on. As for disk access, Table 2 shows what Bonnie reports.
As you can see, the results are sporadic, with the processor scoring lower than a K6/233 in many cases and the disk drive operating much slower than a typical desktop hard drive. In spite of the low benchmarks, the machine has never lagged on me and does its tasks quite well. This is probably one case where the benchmarks don't mean very much, unless you plan on using the NetWinder for crunching numbers and maintaining huge databases. The chip set is fun to use, and I think hackers who are interested in the StrongARM might like to take a look at these machines, as well as anyone who wants a simple machine for use as a server.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide