[Rxtx] noob trouble with rxtx, losing bytes somewhere

[M.Dec-Gazeta]

Hi Steffen,

> According to the serial HOWTO a 16550A (or 16550) FIFO chip can
> receive up to 14 bytes before interrupting CPU, at 115200 baud
> this makes around 900 events per second. This means, a response
> time of 1 ms or less would be needed.

Very important notice Steffen!!!!
900 events per second - while JVM works it may be to many - even on the fast 
machine :)

>
> According to http://support.microsoft.com/kb/259025 tells
> `Currently in Windows, 3 quantums are equal to either 10
> milliseconds ... or 15 ms ...' suggesting that response times
> below 10 ms cannot be guaranteed at all - which AFAIK is quite
> normal for multi-tasking multi-user non-RT OSes.
>
> So I'm pretty sure no Java application can be able to read
> constantly to an own buffer without support of the OS
> -- not even in theory.

YEEEEEEEEEEEEEES
The kind of solution is a big size of the OS buffer, which will not 
overflows when Java is busy.
But there is a lot of another things as well - vendors drivers, USB /RS232 
hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the 
same USB hub etc.

>
> Did I do a mistake in thinking or is the problem (causing the
> need for single-byte-read-polling) a different one?

You are right.
>From my experience with real time systems (small embedded systems as well), 
the best way is to prepare serial (or another incoming) buffer as big as 
possible and thinking about tuning rest of the application - to have a time 
to empty this buffer in the meantime.

I do it so:
1. I receive data using as high priority as possible HW interrupts and 
prepare "Incoming index" (buffer is circullar of course)
2. In main loop of the program I compare "Incoming index" with "Serviced 
index" and do data analyse.

If its not enough, I am thinking about faster microcontroller :D

Of course - everything depends on (incoming data amount) and/or (data 
structure) and/or (intervals between data packets).

BTW:
Few months ago I have helped my friend, who had to change their old 
soft/hard system on RS232 from UART16550 to USB/RS232 dongle.
Timing in this system is very important.
While it worked on UART, there was no problem, when he started trials on 
USB, troubles came.
Generally - USB BUS pooling was the problem and therefore events in external 
hardware was comming to the system without any sense - additional STOCHASTIC 
delay up to 5-15 ms.
Of course intervals between events visible in PC were stochastic as well...

We will have a lot to do when standards UARTS will gone !!!!! :)

Regards
Mariusz