September 5, 2000
By Karen Kenworthy
IN THIS ISSUE
Hope you didn't miss me yesterday. Here in the U.S. it was "Labor Day," a holiday that honors the importance of work, and those who labor for a living. Naturally, the day's a holiday, so most people skipped work. :)
But for me, there was an even more special day recently. It was the day last week my mother, myself, my oldest niece Vanessa, and Vanessa's new daughter Alexis, spent together. Do the math, and you'll see that covers four generations of daughters!
What a thrill it was to see my mother gently cradle her great-granddaughter in her arms! Cooing and gently rocking, she coaxed a bubbly smile from tiny Alexis. And what a thrill to see little Vanessa, my brother Bill's first child, now a loving mother and wife. So comfortable, so happy. You think she's been a mother all her life.
No, that day wasn't a national holiday. But if you'd been there, you would have joined in our celebration of life. It was a magical moment I'll never forget.
Meanwhile, back here at the secluded Power Tools workshop, the e-mail never stops. Recently, most messages have been about our latest Power Tool, the 'Net Monitor. As you'll recall, it made its debut last week, as a little program that periodically attempts to retrieves a page from the Web site of your choice. It keeps a log of its successes and failures, giving us a measure of the reliability of our favorite Web site.
Almost immediate after the 'Net Monitor appeared, I received this note from reader Pat Gormady: "Karen, I love your 'Net Monitor! I think it will help keep IP's honest. An obvious bug appeared when I attempted to start the program. The Icon on the start menu was a shortcut to nowhere!"
Oops! Pat downloaded the 'Net Monitor installer just minutes after I first uploaded it to my Web site (https://www.karenware.com/. This original version had a setup bug that kept it from creating the proper shortcut on the Windows Startup menu. As a result, Pat had to fend for himself, making his own shortcut to the program's executable file, NetMon.exe. :(
Thanks to Pat's note, I was quickly able to find my mistake, and revise the setup program. So if you downloaded the 'Net Monitor installer (ptnetmon- setup.exe) any time after its first few hours of life, you won't see the problem Pat found.
Pat's note also included a great suggestion. Why not, he asked, report how long it takes 'Net Monitor to complete each test? This would give us more information about the quality of service each Web server provides.
Of course, Pat's exactly right. The time it takes a server to deliver a Web page is important. And that time can vary widely. Sometimes the fault is the server's. It may be performing some time-consuming process, such as a backup, at the same time it's trying to provide your page. Or the server may be receiving more requests than it can handle promptly.
Other delays can be caused by traffic jams on the Internet. Equipment malfunctions, power failures, temporary congestion, even bad weather, can all cause delays and disruptions. And they can all deprive us of the service we're paying for, and our Web site visitors expect to receive.
In theory, timing something is pretty easy. You just look at your clock before a process begins, and again just after it ends. The difference between the two clock readings is the process's elapsed time.
Now your computer has a nice digital clock, built into its circuitry. In addition to the time of day, this clock also keeps track of the current day, month and year. Windows uses this clock to record the date and time a file is created, modified, or last accessed. Many other programs use this clock too.
But the 'Net Monitor doesn't use this clock to measure a test's elapsed time. That's because the "resolution" of the computer's built-in clock is too low. The time reported by this clock only changes once very second. If you check the clock after less than a second has passed, you won't see any difference. The elapsed time will appear to be zero.
Even if the time reported by your computer has changed by one second, there's no way to know if the actual elapsed time is only one second, or as much as 1.999 seconds. In other words, the actual elapsed time might be as much as twice the reported elapsed time, when timing short intervals.
The time needed to retrieve a Web page can be as great as several seconds. But it can be a lot less than a single second. Typical times I've encountered run from 250 milliseconds (thousandths of a second) when accessing a Web page stored on a nearby server, to 8 to 10 seconds when accessing a page stored on a busy server across the country. I wanted 'Net Monitor to be able to measure times like these to the nearest thousandth of a second. And to do that I had to find another clock.
To find that high resolution clock, let's take a trip back in time. Back to the dawn of the PC industry. Back to the days when giant 5.25-inch diskettes, dot- matrix printers, and 4-color monitors ruled the earth. Back, back, all the way back, to the dimly lit year of 1981.
Gathered 'round a campfire, wrapped in animal skins, trying to keep warm, we see a small group of electrical engineers. As we silently creep towards them, we begin to overhear their conversation. What luck! They are talking about the design of the first IBM PC!
"Well, that covers just about everything, except the video display," says the one with the largest forehead. "But that may be a showstopper. Custom video circuits are too expensive. And building a custom monitor will really break the budget. But what else can we do? After all, it's not like you can go to a store and by a computer monitor!"
After the laughter dies down, one of the younger engineers, who's been poking the fire with a stick, tentatively clears his throat and starts to speak. "That's right, computer monitors are rare and expensive," he says. "But what about TV sets? They're cheap and plentiful. Couldn't we adapt them to do the job?"
The rest, as they say, is history. The designers of the original PC did make use of existing TV technology when creating their first video display adapters and monitors. No, the PC didn't produce an actual TV signal. And the monitors weren't full-blown TV sets. That would have added unnecessary expense.
Instead, the engineers stripped out the portions of the U.S. TV broadcast standard necessary for efficiently sending signals over the airwaves. But they kept the scanning, timing, and color generation portion of the standards. The result allowed them to use inexpensive, readily available, components to build the first video adapters and computer monitors.
It also meant that every original PC included a circuit that oscillated, or changed state, 3.579 million times per second. That's because every American TV set has one. A circuit oscillating at this exact frequency can (directly and indirectly) produce all the timing signals need to produce or decode a U.S. TV signal!
Okay, the circuit doesn't oscillate exactly 3.579 million times per second. The exact rate is 3,579,545 oscillations per second. But you get the idea. This is one circuit that changes state very rapidly, a lot more often than the computer's clock/calendar chip we were talking about a moment ago. It would make a great clock for timing 'Net Monitor's tests.
Maybe it's tradition. Or maybe it's because, almost since the beginning, computer programmers have use this oscillator to time high-speed events. Whatever the reason. Almost all computers today still contain a 3.579 MHz oscillator, even though it's no longer needed to produce the computer's video display. And for the last several years (since the arrival of Windows 95 and Windows NT), Windows itself has given programs, like 'Net Monitor, and easy way to use this oscillator as a high resolution clock.
Windows constantly monitors this circuit, keeping a count of how many times it has "ticked" since Windows was booted. This count is stored as a 64-bit binary number, meaning it will "roll over," or overflow the space available and restart at zero, every 5,153,376,776,576 seconds. For those of you who don't have your calculators handy, that's approximately 59,645,564 days, or 163,300 years!
This "clock" is just what we need. By asking Windows for the current tick count, just before a test starts, and just after it ends, 'Net Monitor can compute the number of ticks that took place while a test was running. To convert ticks to seconds, the program just divides the number of ticks by 3,579,545. The result is a test's elapsed time, accurate to more than a millionth of a second.
Well, not quite. After all, the computer was doing other things besides our test during that interval. But the computed time is pretty close to the actual time. To be safe, 'Net Monitor rounds the result to the nearest thousandth of a second before displaying the elapsed time.
If you'd like to try out the new 'Net Monitor, with it's nifty high resolution test timer, just download a free copy from my Web site at https://www.karenware.com/powertools/ptnetmon. The programmer's among us might want to check out the program's Visual Basic source code, available there too, to see exactly how Windows' high-speed clock works.
Either way, be sure to check out the other features I added to 'Net Monitor last week. We don't have time to talk about them today, but I'm sure they'll come up the next time we get together.
Speaking of get-togethers and time -- if there's someone you haven't spoken to in a while, why not change that this week? Life's a lot shorter than any of us realize. Too short to let opportunities to spend time with loved ones pass us by.
And don't forget me. I'll be cruising the 'net this week, as always. If you see me there, be sure to wave and say "Hi!"