[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rxtx
Subject:    Re: [Rxtx] Timeout accuracy
From:       Trent Jarvi <taj () www ! linux ! org ! uk>
Date:       2004-07-09 14:09:10
Message-ID: Pine.LNX.4.58.0407091456331.12043 () parcelfarce ! linux ! theplanet ! co ! uk
[Download RAW message or body]

On Fri, 9 Jul 2004, Olgierd Eysymontt wrote:

> Hi,
>         I'm using RXTX for communicating dataloggers in a 422 network
> and I
> need to detect the end of a packet by a timeout.
> 
>         Seeing the waveforms on a scope I see the computer takes some
> time to
> detect the timeout (I have defined the value to 3 ms and computer takes
> between 50 ms and 100 ms to detect the timeout), my question is if there
> is a way to make this time lower as I have the bus only 25% aprox. used
> in time.
> 
>         I've searched the mailing list archives without luck.
> 
>         My system is a Fedora Core 1, j2sdk1.4.2_03, serial board is
> titan
> pci-200L-si.
> 
>         Thank you very much to you all, RXTX has made my life much
> easier as I
> were before programming the same routines in C before to know about
> RXTX.
> 
> Olgierd Eysymontt
> 
> 

for 422, rxtx (java serial comm in general) is going to be a bit sluggish.  
But I'd expect something less than 50 ms.  maybe closer to 20 ms.

The obvious thing to check is the usleeps in SerialImp.c.  Some of rxtx 
functionality is poll like on boards with incomplete kernel support.  The 
usleeps keep the CPU use down at the expense of latency.

The second thing to look at would be a realtime linux kernel.  This will 
help but the 100 ms you mention suggests we are in another degree of 
latency.  Maybe it will help.  But check the usleeps first.

The last thing I can suggest is that crossing the JNI is expensive for 
you.  So the more you can do in a single call accross the JNI in time 
sensitive areas, the better.  You may want to move some of the native code 
around to do more specifically what you are after.

I have only done one test with time.

loop()
{
	-data available event-
		read();
		write();
}

This was all from Java.

When I tried this with an uncalibrated scope, it appeared to be ~20 ms 
between bytes going out.  This was back in jdk 1.3 though/linux 2.4 
though.  w32 was a little (10%) better which was really odd because it was 
in vmware on linux.

-- 
Trent Jarvi
taj@www.linux.org.uk
_______________________________________________
Rxtx mailing list
Rxtx@linuxgrrls.org
http://mailman.linuxgrrls.org:8080/mailman/listinfo/rxtx
[prev in list] [next in list] [prev in thread] [next in thread]