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 firstname.lastname@example.org
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 email@example.com
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 firstname.lastname@example.org
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 email@example.com
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 firstname.lastname@example.org
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- SUSE – “Will not diverge from its Open Source roots!”
- Dealing with Boundary Issues
- Vagrant Simplified
- Libreboot on an X60, Part I: the Setup
- System Status as SMS Text Messages
- October 2015 Issue of Linux Journal: Raspberry Pi
- Bluetooth Hacks
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- New Products
- October 2015 Video Preview