By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,184 Members | 1,369 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,184 IT Pros & Developers. It's quick & easy.

About time spent have big difference in two running

P: n/a
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int
main ( int argc, char *argv[] )
{
long i = 10000000L;
clock_t start, end;
double duration;

printf("Time do %ld loop spent ", i);
start = clock();
while (i--);
end = clock();

duration = (double)(end - start) / CLOCKS_PER_SEC;
printf("%f seconds\n", duration);

return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */

I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds
Why have such big difference?

thank you!!!

Sep 25 '07 #1
Share this Question
Share on Google+
19 Replies


P: n/a
xianwei wrote:
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int
main ( int argc, char *argv[] )
{
long i = 10000000L;
clock_t start, end;
double duration;

printf("Time do %ld loop spent ", i);
start = clock();
while (i--);
end = clock();

duration = (double)(end - start) / CLOCKS_PER_SEC;
printf("%f seconds\n", duration);

return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */

I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds
Have you ever seen a hummingbird, and wondered
how fast its wings flutter? You might try to find
an answer by measuring the time for ten million beats.
So you set up your highly accurate wingbeat counter,
and then you start your timer: an hourglass ...

--
Eric Sosman
es*****@ieee-dot-org.invalid
Sep 25 '07 #2

P: n/a
"xianwei" <ba*********@gmail.coma ¨¦crit dans le message de news:
11**********************@k79g2000hse.googlegroups. com...
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int
main ( int argc, char *argv[] )
{
long i = 10000000L;
clock_t start, end;
double duration;

printf("Time do %ld loop spent ", i);
start = clock();
while (i--);
end = clock();

duration = (double)(end - start) / CLOCKS_PER_SEC;
printf("%f seconds\n", duration);

return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */

I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds
Why have such big difference?
I suspect the clock() function on your system has a granularity of around 15
milliseconds. If this is the case, the clock() function will return the
same value for all calls during each 15 millisecond interval. Depending on
when exactly you start your measurements within that interval, a task
lasting cloless than 15ms can be "clocked" as lasting 0ms or 15ms.
Similarly, one that takes between 15 and 30 might be reposted as taking
exactly 15ms or exactly 30ms.

On top of this granularity issue, you should look into the clock() function.
Does it measure elapsed time? total processor time? processor time spent in
your program vs time spent in the system? or something else even... Your
"timings" will also be affected by other tasks the computer performs while
your program executes, and many other characteristics of you system (cache
memory, bus sharing with i/o devices, etc.)

For your peticular concern, I suggest you try and synchronize your timing
efforts with this small loop:

clock_t last, start;

last = start = clock();
while (start == last) {
start = clock();
}

You should try and measure longer computations, by repeating them in a loop
or increasing the constants.

You should consider using more accurate timing functions such as
non-standard gettimeofday in Linux.

You should repeat the tests many many times, and average the results,
discarding extreme values.

Effective code profiling is *very* difficult. Drawing conclusions or making
changes from profiling data is not easy either: what holds on one
architecture does not necessarily on another one, even just slightly
different. There is no definitive truth in this domain.

--
Chqrlie
Sep 25 '07 #3

P: n/a
On Sep 25, 8:15 pm, Eric Sosman <esos...@ieee-dot-org.invalidwrote:
Have you ever seen a hummingbird, and wondered
how fast its wings flutter? You might try to find
an answer by measuring the time for ten million beats.
Thank you, you are right, I should replace one millions to ten
millions.
When I do that, the time keep in 0.285 - 0.231 seconds, I think this
is
well.

To test how fast humming wings flutter sound not like a good
idea !! :-)

Sep 25 '07 #4

P: n/a
On Sep 25, 8:18 pm, "Charlie Gordon" <n...@chqrlie.orgwrote:
"xianwei" <baikaish...@gmail.coma ¨¦crit dans le message de news:
1190695176.006514.155...@k79g2000hse.googlegroups. com...
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int
main ( int argc, char *argv[] )
{
long i = 10000000L;
clock_t start, end;
double duration;
printf("Time do %ld loop spent ", i);
start = clock();
while (i--);
end = clock();
duration = (double)(end - start) / CLOCKS_PER_SEC;
printf("%f seconds\n", duration);
return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds
Why have such big difference?

I suspect the clock() function on your system has a granularity of around15
milliseconds. If this is the case, the clock() function will return the
same value for all calls during each 15 millisecond interval. Depending on
when exactly you start your measurements within that interval, a task
lasting cloless than 15ms can be "clocked" as lasting 0ms or 15ms.
Similarly, one that takes between 15 and 30 might be reposted as taking
exactly 15ms or exactly 30ms.
Thank you for you explanation about the question.
You should repeat the tests many many times, and average the results,
discarding extreme values.
Yes, when I larger the loop times, the spent times differs in a small
point.
Thanks you enthusiasm.
Sep 25 '07 #5

P: n/a
xianwei wrote:
>
.... snip ...
>
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds. Why have such big difference?
Because the resolution of your clock is obviously roughly 0.0155 S.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Sep 25 '07 #6

P: n/a
CBFalconer <cb********@yahoo.comwrites:
xianwei wrote:
... snip ...
>>
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds. Why have such big difference?

Because the resolution of your clock is obviously roughly 0.0155 S.
Most likely 1/60 second, but that's just a semi-educated guess.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 25 '07 #7

P: n/a
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
>xianwei wrote:

... snip ...
>>>
I run the above the program,
The first time I spent 0.031000 seconds.
The second time I spent 0.015000 seconds
If I try again and again, the time spent on will 0.031 or 0.015
seconds. Why have such big difference?

Because the resolution of your clock is obviously roughly 0.0155 S.

Most likely 1/60 second, but that's just a semi-educated guess.
PCs can have some peculiar number, tied back to the old XT.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 25 '07 #8

P: n/a
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Because the resolution of your clock is obviously roughly 0.0155 S.

Most likely 1/60 second, but that's just a semi-educated guess.

PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Sep 26 '07 #9

P: n/a
"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
>Keith Thompson wrote:
>>CBFalconer <cb********@yahoo.comwrites:
Because the resolution of your clock is obviously roughly 0.0155 S.

Most likely 1/60 second, but that's just a semi-educated guess.

PCs can have some peculiar number, tied back to the old XT.

That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
For those who wonder why 18.2 Hz, that makes 64K ticks per hour.
This may be the very reason for the rather odd original PC frequency:
65536 * 65536 * 4 / 3600 = 4.772185 MHz

--
Chqrlie.
Sep 26 '07 #10

P: n/a
Charlie Gordon wrote:
"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
>On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
>>Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
Because the resolution of your clock is obviously roughly 0.0155 S.
Most likely 1/60 second, but that's just a semi-educated guess.
PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100

Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000

Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0

Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)
Sep 26 '07 #11

P: n/a
In article <46***********************@news.free.fr>,
Charlie Gordon <ne**@chqrlie.orgwrote:
>This may be the very reason for the rather odd original PC frequency:
65536 * 65536 * 4 / 3600 = 4.772185 MHz
No, that comes from the 4/3 the frequency of an NTSC colour
sub-carrier oscillator. I'm not sure if the PC had one of these
anyway and it was reused, or if they were just cheap.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Sep 26 '07 #12

P: n/a
"Richard Tobin" <ri*****@cogsci.ed.ac.uka écrit dans le message de news:
fd***********@pc-news.cogsci.ed.ac.uk...
In article <46***********************@news.free.fr>,
Charlie Gordon <ne**@chqrlie.orgwrote:
>>This may be the very reason for the rather odd original PC frequency:
65536 * 65536 * 4 / 3600 = 4.772185 MHz

No, that comes from the 4/3 the frequency of an NTSC colour
sub-carrier oscillator. I'm not sure if the PC had one of these
anyway and it was reused, or if they were just cheap.
I am positive it did not, since the graphics was done on a separate adapter
board.
But you are right, these oscillators were common and cheap, and the
frequency may not have been exactly what I stated. The BIOS did take
advantage of the 64K ticks in an hour, but there might have been an
adjustment, I'll take a look.

--
Chqrlie.
Sep 27 '07 #13

P: n/a
On 2007-09-26 16:17, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
Charlie Gordon wrote:
>"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
>>On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.

No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100

Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000

Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0

Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)
These examples are rather irrelevant since the clock frequency in these
cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
have caused an error of about 1.1%, which I think would have been
noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
look).

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Sep 27 '07 #14

P: n/a
Peter J. Holzer wrote:
On 2007-09-26 16:17, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
>Charlie Gordon wrote:
>>"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100

Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000

Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0

Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)

These examples are rather irrelevant since the clock frequency in these
cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
have caused an error of about 1.1%, which I think would have been
noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
look).

hp
Pardon me??? That whole list is from dos computers.
However they all do modify their clockticks in some way.
I have never seen a clocktick to have a one to one relation
to the 18.2 HZ clock, they all modify that to give a
"decimal" clocktick.
When however you print all clockchanges,you can recognize the
relation to the systemclock.
Sep 27 '07 #15

P: n/a
"Peter J. Holzer" <hj*********@hjp.atwrites:
On 2007-09-26 16:17, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
>Charlie Gordon wrote:
>>"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.

No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100

Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000

Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0

Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)

These examples are rather irrelevant since the clock frequency in these
cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
have caused an error of about 1.1%, which I think would have been
noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
look).
CLOCKS_PER_SEC doesn't necessarily match the actual clock frequency.
It just gives you the factor by which you need to scale the value
returned by the clock() function.

For example, a physical clock frequency of 18.2 Hz and a
CLOCKS_PER_SEC value of 1000 would be consistent. Successive calls to
clock() might return
0
55
110
165
...
989
1044
and so forth; each result exceeds the prievous one by 54 or 55.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 27 '07 #16

P: n/a
Keith Thompson <ks***@mib.orgwrites:
CLOCKS_PER_SEC doesn't necessarily match the actual clock frequency.
It just gives you the factor by which you need to scale the value
returned by the clock() function.
And in fact, CLOCKS_PER_SEC has the same value on all
XSI-conformant UNIX systems, even though such systems are not
required to have a clock that ticks at any particular frequency.
--
Ben Pfaff
http://benpfaff.org
Sep 27 '07 #17

P: n/a
On 2007-09-27 17:34, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
Peter J. Holzer wrote:
>On 2007-09-26 16:17, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
>>Charlie Gordon wrote:
"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
>PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.
No. CLOCKS_PER_SEC is (mostly) an int.
Watcom compiler:
#define CLOCKS_PER_SEC 100

Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000

Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0

Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)

These examples are rather irrelevant since the clock frequency in these
cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
have caused an error of about 1.1%, which I think would have been
noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
look).
Pardon me??? That whole list is from dos computers.
However they all do modify their clockticks in some way.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^

That's the crux. If they modify the clockticks, they aren't the same any
more. If a program does NOT modify the clock ticks, the frequency is
18.2 Hz, which is not an integral number.
I have never seen a clocktick to have a one to one relation
to the 18.2 HZ clock, they all modify that to give a
"decimal" clocktick.
I am positive that Turbo C (up to and including Turbo-C++ 1.0, which
was the last version I've used) did not modify the clock rate, because
on ocassion I needed a higher resolution and had to reprogram the timer
chip myself. It is possible that clock did the conversion internally,
as Keith suggests, but I doubt that, because:

* I think I would remember it

* I found some old benchmark code of mine, which contains a comment
on the granularity of the times() function on Ultrix, but none on the
granularity of clock on MS-DOS. I think I would have added a comment
if granularity of clock was worse than CLOCKS_PER_SEC suggested.

So, I think that CLOCKS_PER_SEC should have been 18.2 on Turbo-C, but I
don't remember if they actually defined it as 18.2 or approximated it
with 18. However, I notice that in your examples the Borland compiler is
the only one which defines CLOCKS_PER_SEC as a floating point constant,
which strongly suggests that it was 18.2 in earlier versions and when
they changed it to 1000, they didn't want to break programs which
(erroneously) assumed that CLOCKS_PER_SEC was of type double.

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Sep 29 '07 #18

P: n/a
On 2007-09-27 22:34, Keith Thompson <ks***@mib.orgwrote:
"Peter J. Holzer" <hj*********@hjp.atwrites:
>On 2007-09-26 16:17, Sjouke Burry <bu*************@ppllaanneett.nnlllwrote:
>>Charlie Gordon wrote:
"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-25 21:40, CBFalconer <cb********@yahoo.comwrote:
>PCs can have some peculiar number, tied back to the old XT.
That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
seconds). Was CLOCKS_PER_SEC actually a floating point constant on
MS-DOS compilers? I don't remember but I guess it must have been.

No. CLOCKS_PER_SEC is (mostly) an int.

Watcom compiler:
#define CLOCKS_PER_SEC 100

Microsoft C Compiler Version 2.00.000 V 6.00A
#define CLOCKS_PER_SEC 1000

Borland BC5 however disagrees.
#define CLOCKS_PER_SEC 1000.0

Digital Mars compiler:
#define CLOCKS_PER_SEC ((clock_t)1000)

These examples are rather irrelevant since the clock frequency in these
cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
have caused an error of about 1.1%, which I think would have been
noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
look).

CLOCKS_PER_SEC doesn't necessarily match the actual clock frequency.
I know, I have used systems where they didn't match (in fact I'm using
one right now). I am quite sure that they did match on MS-DOS with the
Turbo-C compilers, though. I should have written "... the unit of time
returned by clock is exactly 1/100 or 1/1000 second" instead of "...
clock frequency ...".

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Sep 29 '07 #19

P: n/a

Just for reference:

Assuming a stock IBM PC without the counter reprogrammed,
the "18.2 per second" interrupt was derived as follows:

The IBM PC Clock Crystal oscillates at 4770000 Hertz.
4770000 / 4 / 65536 = 18.19610595703125 Hertz.

This is close to 65536 ticks per hour:
3600 Seconds (1 Hour) / 65536 = 18.20444... Hertz.

And is related to a NTSC Color Crystal at 14318180 Hertz:
14318180 / 12 / 65536 = 18.2065073649088541666... Hertz.

That 4770000 Hertz IBM PC Crystal had a best case accuracy
of +/- 0.0005%, a typical accuracy of +/- 0.002%, and a
worst case accuracy of +/- 0.01%. Some servers have oven
stabilized crystals with an accuracy approaching 0.00001%
(0.1 ppm).

Also, There is a list of interrupts and IRQs here:
http://docs.huihoo.com/help-pc/int-int_table.html

--
Guy Macon
<http://www.guymacon.com/>


Sep 29 '07 #20

This discussion thread is closed

Replies have been disabled for this discussion.