Did someone ever write a "serial response benchmark"??
1) send a char, save a time stamp
2) have a second machine to receive the char and return it.
3) receive the char in the first machine and figure out how long the loop took
4) tell the worts case latencie to the user
Jens Michaelsen
Stuart Hughes schrieb:
> Hi Jan,
>
> The test is very simple. A task runs every 100usecs and measures the
> current time, using the time stamp counter, which is a free running
> clock on Pentiums that has a resolution to the clock frequency.
>
> The previously calculated expected time is used to calculate how
> late/early this pass ran, and if it is the largest so far, it overwites
> the current max/min value (min being the earliest time which will be
> negative).
>
> Next, the expected next wakeup time is caculated (now+100usec).
>
> Finally the task suspends until its next wakeup.
>
> The results are available at any time by doing a cat /proc/jitter. The
> results give a good idea of the amount of jitter. Please remember the
> limits of measument accuracy that occur due to the resolution of the
> 8254 interrupt clock source (1/1193180 ~ 0.838 usecs).
>
> Regards, Stuart
>
> Jan Borgosz wrote:
> >
> > Hi
> >
> > I'm solving problems with measurment devices for jitter - may you write
> > something more about your program, methods and algorithms
> >
> > Sincerely
> > Jan Borgosz
> >
> > Stuart Hughes wrote:
> >
> > > Hi all,
> > >
> > > I have attached a simple portable jitter test. This I have tested this
> > > on rtlinux-2.0pre2 and RTAI-0.7.
> > >
> > > The basis of the test is that each cycle is independant of each other,
> > > so that clock drift errors do not accumalate.
> > >
> > > If you make this, and type ./run_test, it will install all the needed
> > > rt-modules, as well as the target jitter_rt.o module.
> > >
> > > Once you have done this, you can the leave it runnning and at any point
> > > type:
> > > cat /proc/jitter to see the max/min recorded jitter values in
> > > nanoseconds.
> > >
> > > Please note, that in order to get a true appreciation of worst case, you
> > > should stress the system. I usually run a ping -f to the target machine
> > > and on the target run top with an interval of zero. You may have some
> > > other methods you prefer.
> > >
> > > Any comments about the module, even bad ones are welcome (as it can
> > > always be improved.
> > >
> > > Regards, Stuart.
> > >
> > > PS: An interesting note, on my laptop (Dell Inspiron 7k), normally I
> > > will see worst case jitters on RTL/RTAI of about +/- 15 usec. But, if
> > > you invoke any of the 'special functions' such as changing the screen
> > > brightness or plugging in the power cord, you will see jitter up to 53
> > > milliseconds.
> > >
> > > ------------------------------------------------------------------------
> > > Name: jitter.tgz
> > > jitter.tgz Type: WinZip File (application/x-compressed)
> > > Encoding: base64
>
> --
> Tel: +44 (0)1273 234 647 Fax: +44 (0)1273 704 482
>
> Visit http://www.zentropix.com/ for Real Time Linux Tools
> --- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> ----
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/~rtlinux/
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
