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
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Nice article, thanks for the
10 hours 13 min ago
- I once had a better way I
15 hours 59 min ago
- Not only you I too assumed
16 hours 16 min ago
- another very interesting
18 hours 9 min ago
- Reply to comment | Linux Journal
20 hours 2 min ago
- Reply to comment | Linux Journal
1 day 2 hours ago
- Reply to comment | Linux Journal
1 day 3 hours ago
- Favorite (and easily brute-forced) pw's
1 day 5 hours ago
- Have you tried Boxen? It's a
1 day 10 hours ago
- seo services in india
1 day 15 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?