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
|PasswordPing Ltd.'s Exposed Password and Credentials API Service||Apr 28, 2017|
|Graph Any Data with Cacti!||Apr 27, 2017|
|Be Kind, Buffer!||Apr 26, 2017|
|Preparing Data for Machine Learning||Apr 25, 2017|
|openHAB||Apr 24, 2017|
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
- Graph Any Data with Cacti!
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- The Weather Outside Is Frightful (Or Is It?)
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)
- IGEL Universal Desktop Converter
- Server Technology's HDOT Alt-Phase Switched POPS PDU
- From vs. to + for Microsoft and Linux