I think you will find time is measured in Jiffies, and not millisecons/microseconds,
or nanoseconds. The only RTC clock is setup to nudge every Jiffy ( 1/60 for the
intel, and 1/1000 for alpha ) . Although u think it is better at 1/1000 - but this
represents 1000 interrupts per second every second ALL the time!
gat

Jerry Treweek wrote:

> I've had similar problems measuring bandwidth. The greatest difficulty was the
> limited resoution of the available timers. It's a darn shame that a high
> resolution counter isn't available given all these fancy hardware. Milliseconds!
> Pah! You can do an awful lot in a millisecond. Ever since the Pentium was
> release there have been high resolution counters available - anyone written some
> code to access them ? - back then it was all restricted access only! Does Intel
> give a damn now ?
>
> Jerry
>
> Nathan Meyers wrote:
>
> > Willi Richert wrote:
> > >
> > > I have written an ftp-client (connected to the ftp-server residing at
> > > the same computer) which I tried to measure how fast it can handle I/O.
> > > I used getCurrentTimeMillis() (or similar) which gave me for the same
> > > config (retrieve 1meg, same file) sometimes values that differed by a
> > > factor of 2.
> > > Now, how can I get "valuable values". Maybe I missed a similar
> > > discussion, so I would be thankful for every pointer.
> >
> > To explore a couple of obvious questions:
> >
> > 1) Are you sure the different values are wrong? Have you stood by with a
> > stopwatch to compare what the program is reporting with what is really
> > happening?
> >
> > 2) Is the time of what you're measuring long enough to make minor
> > variations insignificant?
> >
> > Perhaps the most important caveat is to realize that a call that reports
> > milliseconds or microseconds or whatever isn't necessarily accurate to
> > the millisecond or microsecond... it's only accurate to the resolution
> > of the underlying clock. If, to get a little extreme, your system ticker
> > is counting off in tenths of seconds, then you're always going to get a
> > time that's accurate to + or - 1/20th of a second.
> >
> > Nathan
> >
> > ----------------------------------------------------------------------
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to