I have been working on an application for work written in Java. It's a
production system used for loading firmware into embedded devices via
RS-232. It is designed to load multiple devices in parallel (tested
with up to 32 on a machine thus far). With another Java application
running on Windows XP, a single unit would take about 1 min to load
~400,000 byte binary image. I ported this code to the production
system on Linux and it took over 15 min to load a single unit.
I ran some tests on Windows XP and Linux CentOS 5.1 using the Sun
NetBeans IDE 6.7.1 profiler. The same Java code on both Linux and XP
machines, the same model of machine (Dell, Pentium 4 3GHz, 2.5GB
memory). I am using the Sun comm API currently, and previously I was
using the Serlio API. In all cases, the profiler shows the serial Tx
to be about 20x faster (twenty times) on Windows XP than in Linux. It
takes Linux several seconds to Tx 1024 byte blocks of data over the
serial port where Windows XP takes a fraction of a second. I had also
noticed that Linux seemed to be very slow in 2006-2007 when using
Fedora (can't recall which version) and the Serialio API, but at that
time I could not get Windows to work at all. This has forced us to
lean toward the use of Windows (and pay for licensing for multiple
machines, etc.) instead of Linux for every system that will be used in
testing and manufacture of our product.
I am wondering, have there been any performance tests comparing Linux
serial IO to Windows and what was the result? Is it a problem in the
comm API (e.g. - the Windows DLL having better performance than the
Linux .so)? Is it a problem in the Linux serial driver itself? Is
there something I can/need to do on Linux to tweak the driver and make
it faster?
Thanks,
PGA
--
Paul G. Allen
Random Logic Consulting
http://www.randomlogic.net
Well, as far as I know. Same code on both systems. The embedded device
operates at 115200, 8N1, no flow control. It uses RPC/SLIP protocol
for commands and data. They talk to each other, but the Linux system
just takes forever to send the data.
PGA
On Sat, Jan 9, 2010 at 11:10 AM, Samuel Thibault
<[email protected]> wrote:
> Paul G. Allen, le Sat 09 Jan 2010 10:57:48 -0800, a écrit :
>> In all cases, the profiler shows the serial Tx
>> to be about 20x faster (twenty times) on Windows XP than in Linux.
>
> Did you properly set the serial port speed?
>
> Samuel
>
--
Paul G. Allen
Random Logic Consulting
http://www.randomlogic.com
Paul G. Allen, le Sat 09 Jan 2010 10:57:48 -0800, a ?crit :
> In all cases, the profiler shows the serial Tx
> to be about 20x faster (twenty times) on Windows XP than in Linux.
Did you properly set the serial port speed?
Samuel
Paul G. Allen wrote:
> Well, as far as I know. Same code on both systems. The embedded device
> operates at 115200, 8N1, no flow control. It uses RPC/SLIP protocol
> for commands and data. They talk to each other, but the Linux system
> just takes forever to send the data.
>
Serial Line Ip protocol? Can be a problem of your routing table?
Michael
> PGA
>
> On Sat, Jan 9, 2010 at 11:10 AM, Samuel Thibault
> <[email protected]> wrote:
>
>> Paul G. Allen, le Sat 09 Jan 2010 10:57:48 -0800, a écrit :
>>
>>> In all cases, the profiler shows the serial Tx
>>> to be about 20x faster (twenty times) on Windows XP than in Linux.
>>>
>> Did you properly set the serial port speed?
>>
>> Samuel
>>
>>
>
>
>
>
* Paul G. Allen ([email protected]) wrote:
> Well, as far as I know. Same code on both systems. The embedded device
> operates at 115200, 8N1, no flow control. It uses RPC/SLIP protocol
> for commands and data. They talk to each other, but the Linux system
> just takes forever to send the data.
What does the RPC/SLIP - the app or the Kernel?
If you have no flow control is it possible that someone is dropping a byte
somewhere any recovering?
If your device is set at the right speed (check with stty -a < /dev/ttyS??? )
then what speed does :
dd if=/dev/zero of=/dev/ttyS??? bs=1 count=10000
show, for my line set at 9k6 (on ttyS0) it's showing 1.0kB/s which
seems about right.
What's the serial card - is it an onboard card or a PCI plug in,
I've seen problems on Linux a few times where the device driver
has the speed of some plugin cards out by a factor of 8.
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
> I am wondering, have there been any performance tests comparing Linux
> serial IO to Windows and what was the result? Is it a problem in the
Our peak throughput is about 40-50Mbits/second
> comm API (e.g. - the Windows DLL having better performance than the
> Linux .so)? Is it a problem in the Linux serial driver itself? Is
> there something I can/need to do on Linux to tweak the driver and make
> it faster?
You probably need to ask a java list and profile it below the java level
to get answers here. It's possible there are small performance
differences between Linux and Windows at 115,200 but I'd not expect any
except maybe in latency and then only small ones.
The number of java experts on the kernel list is quite small I'm afraid.
On 01/09/2010 12:57 PM, Paul G. Allen wrote:
> I have been working on an application for work written in Java. It's a
> production system used for loading firmware into embedded devices via
> RS-232. It is designed to load multiple devices in parallel (tested
> with up to 32 on a machine thus far). With another Java application
> running on Windows XP, a single unit would take about 1 min to load
> ~400,000 byte binary image. I ported this code to the production
> system on Linux and it took over 15 min to load a single unit.
>
> I ran some tests on Windows XP and Linux CentOS 5.1 using the Sun
> NetBeans IDE 6.7.1 profiler. The same Java code on both Linux and XP
> machines, the same model of machine (Dell, Pentium 4 3GHz, 2.5GB
> memory). I am using the Sun comm API currently, and previously I was
> using the Serlio API. In all cases, the profiler shows the serial Tx
> to be about 20x faster (twenty times) on Windows XP than in Linux. It
> takes Linux several seconds to Tx 1024 byte blocks of data over the
> serial port where Windows XP takes a fraction of a second. I had also
> noticed that Linux seemed to be very slow in 2006-2007 when using
> Fedora (can't recall which version) and the Serialio API, but at that
> time I could not get Windows to work at all. This has forced us to
> lean toward the use of Windows (and pay for licensing for multiple
> machines, etc.) instead of Linux for every system that will be used in
> testing and manufacture of our product.
>
> I am wondering, have there been any performance tests comparing Linux
> serial IO to Windows and what was the result? Is it a problem in the
> comm API (e.g. - the Windows DLL having better performance than the
> Linux .so)? Is it a problem in the Linux serial driver itself? Is
> there something I can/need to do on Linux to tweak the driver and make
> it faster?
It seems unlikely that there's a kernel bottleneck of this magnitude in
the serial code for something that simple. Seems more likely to me that
the Java VM's serial communications code is doing something silly. Have
you tried running strace on your process to see if the syscalls
accessing the serial port look strange? What's the CPU usage like when
this is running?
"Paul G. Allen" <[email protected]> writes:
> I ran some tests on Windows XP and Linux CentOS 5.1 using the Sun
> NetBeans IDE 6.7.1 profiler. The same Java code on both Linux and XP
> machines, the same model of machine (Dell, Pentium 4 3GHz, 2.5GB
> memory). I am using the Sun comm API currently, and previously I was
> using the Serlio API. In all cases, the profiler shows the serial Tx
> to be about 20x faster (twenty times) on Windows XP than in Linux. It
> takes Linux several seconds to Tx 1024 byte blocks of data over the
> serial port where Windows XP takes a fraction of a second.
I don't know about Java, but I'm using 460 kb/s and 920 kb/s serial
ports and Linux can transmit (and receive) full speed data without any
problem. This includes mobile Pentium III 500 MHz with 460 kb/s NS super
IO chip.
4-port OX16PCI954, PL2303 (max 2) and FTDI2232-based USB dongles also
work as well. I know people use ca. 4 Mb/s async serial (with PPP).
The last time I remember serial IO problems it was 8-port 8251-based ISA
card on 486DX. I think it was reliable at max 19200 b/s.
Perhaps you're requesting hardware (or software) handshaking when it's
unavailable? Or maybe there is some "padding" configured?
I wonder what does strace say about it.
--
Krzysztof Halasa
On 09/01/10 18:57, Paul G. Allen wrote:
> I am wondering, have there been any performance tests comparing Linux
> serial IO to Windows and what was the result? Is it a problem in the
> comm API (e.g. - the Windows DLL having better performance than the
> Linux .so)? Is it a problem in the Linux serial driver itself? Is
> there something I can/need to do on Linux to tweak the driver and make
> it faster?
>
> Thanks,
>
> PGA
>
If you can narrow down the problem, one might be able to help.
I would suggest that you write a test Java program that both sends and
receives data on the same port and then post that source code to the list.
Anyone can then plug in a serial loopback connector, and reproduce the
problems you observe.
Without any way to reproduce the problems you observe, there is very
little chance of fixing it.
I suspect the problem is probably due to interrupts and serial buffer sizes.
As an aside, I would probably have used usb instead of serial as the
interface. It would be faster but not a lot more expensive.
Kind Regards
James
>From some of the responses I've gotten both on and off list, it
appears the problem is most likely in the .so provided by Sun and
Seriaio. Others are getting great performance using other methods (C
applications, PC-PC connections, etc) which indicates that the Linux
serial driver is just fine. I am going to ping on Sun about this and
see about either getting it fixed or doing it myself.
Thanks,
PGA
--
Paul G. Allen
Random Logic Consulting
http://www.randomlogic.net