Letters to the Editor
I thoroughly enjoyed the article by Luis A. Fernanades entitled, xmotd: Writing Free Software [October, 1997]. It was a pleasure to read about a programmer contributing to Free Software and supporting other users. This is the very reason that I switched to Linux. Keep articles like that one coming.
—Steven J. Hill email@example.com
The LJ article on Pgfs is really great—nicely written and very informative. [Pgfs: The PostGres File System, Brian Bartholomew, October 1997.] A very nice example of problem solving with our favorite OS. Thanks for including information on what didn't work; it was just as interesting as what did.
LJ is quickly becoming my favorite magazine.
—Eric C. Newton firstname.lastname@example.org
Table 1 on page 30 of the October issue is hardly a “Summary of Alpha Chip Family”. [Linux and the Alpha, David Mosberger]
David Mosberger surprised me when he stated in the Alpha article that gettimeofday() “returns the current real time at a resolution of typically one timer tick (about one millisecond on the Alpha)”. The gettimeofday() API allows a resolution of one microsecond, and Linux on the i386 gives you that (courtesy of a hardware counter that is incremented at approximately one megahertz). A quick look at the 2.0.29 kernel sources (arch/*/kernel/time.c) suggests to me that gettimeofday() gives you high resolution on the i386, m68k, mips and ppc, but not on the Alpha or SPARC. Are there plans to fix this inequity?
—James R. Van Zandt email@example.com
No, it's not. Correct table is printed below.
I think you raise three different questions:<\n>1. What does _typical_ resolution mean?2. Would gettimeofday() with one microsecond be sufficient for the kinds ofmeasurements I wanted to discuss?3. Will Linux/Alpha support resolutions finer than 1 clock tick?
1.To user X, “typical” is what user X happens to own, I suppose. Seriously though, the traditional gettimeofday() implementation provided timer-tick resolution. The API obviously always has allowed for up to microsecond resolution, but that's not relevant for actual implementations. If you're writing a portable program, you cannot rely on gettimeofday() returning better than timer-tick resolution, hence my claim of this being “typical”.
2. One microsecond resolution is far from sufficient for modern CPUs. Even on a (relatively slow) 200MHz P6 this would correspond to 200 cycles, so it would not be possible to measure low-level events such as primary cache-misses. Even if the resolution were sufficient, keep in mind that getimeofday() typically involves a system call. For example, on a 200MHz P6, it appears to take on the order of four microseconds just to execute a pair of gettimeofday() calls. In summary, there are plenty of scenarios where a CPU cycle counter is advantageous over gettimeofday(). Of course, the converse is also true. What I'm saying is that both techniques have their place for the time being.
3. I don't know. 2.1.xx may already do that, but I haven't had a chance to keep track of recent kernel development.
—David Mosberger firstname.lastname@example.org
I have just read Phil Hughes' Stop the Presses in the October issue of LJ. Being a manufacturer of intelligent multiport cards, Cyclades has been following I2O for a while.
I2O has been around for a few years now. It started to gain momentum only this year, due to the persistence of Intel. SCO, Microsoft and Novell seem to be going to support it. At this point, there are no real implementations of I2O, and the standards are only now becoming stable. I have doubts whether this will actually become real or not. The idea of a standard architecture is good, but I2O is a very heavy interface designed to sell Intel processors.
Besides the fact that you have to pay to get the specs (not necessarily bad, PCI does the same thing), there is another catch. The I2O specs were designed so that there is only one possible CPU to be used on a I2O card: the Intel 960RP. More, only Wind River (working with Intel) has a software implementation of I2O messaging. Intel bundles a runtime license of IxWorks (the RTOS that runs the I2O messaging inside the board) with every 960RP.
Thus, I2O is not an “open” standard. It is an attempt by Intel to standardize intelligent I/O around the Intel 960RP and Wind River's IxWorks.
With I2O gaining some momentum, other hardware companies (PLX is one of them) are designing PCI chips compliant with I2O messaging. But, still, the choices are limited, and the viability of I2O is still to be verified.
Phil also mentioned the “Open Hardware” initiative. Cyclades was the first company to certify products for Open Hardware and is, still, the only one.
—Marcio Saito, Cyclades Corporation email@example.com
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Profiles and RC Files
- Astronomy for KDE
- Maru OS Brings Debian to Your Phone
- Understanding Ceph and Its Place in the Market
- Snappy Moves to New Platforms
- Git 2.9 Released
- OpenSwitch Finds a New Home
- What's Our Next Fight?
- The Giant Zero, Part 0.x
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