Increase performance of pseudo terminals?
Jef Driesen
I'm using socat and pseudo terminals, to create two virtual serial ports
linked with a null modem cable. The purpose of this setup is to allow
two applications to communicate with each other, as if they were talking
to real serial ports.
socat PTY,link=/tmp/ttyS0 PTY,link=/tmp/ttyS1
But I noticed the performance is quite bad. Trying to transmit data
takes very long. For instance transmitting 32KB takes a few minutes on
my machine (Ubuntu 9.10), while on another user's machine (Mac OS X)
it's much faster, in the order of a few seconds.
Any idea what is causing this?
I know the transfer protocol is not exactly efficient because it's using
very small blocksize (16 bytes packets with a few extra bytes for
framing), but that doesn't explain the difference on other machines.
Note that I don't have control over the transfer protocol.
Thanks in advance,
Jef
Jasen Betts
> Hi,
>
> I'm using socat and pseudo terminals, to create two virtual serial ports
> linked with a null modem cable. The purpose of this setup is to allow
> two applications to communicate with each other, as if they were talking
> to real serial ports.
>
> socat PTY,link=/tmp/ttyS0 PTY,link=/tmp/ttyS1
>
> But I noticed the performance is quite bad. Trying to transmit data
> takes very long. For instance transmitting 32KB takes a few minutes on
> my machine (Ubuntu 9.10), while on another user's machine (Mac OS X)
> it's much faster, in the order of a few seconds.
>
> Any idea what is causing this?
In debian squeeze using socat and testing it using sx and rx (from
the lrzsz package) (128 byte packets one direction one byte responses
the other) I get 538368 (128 byte) blocks sent in 26s
-- System Information:
Debian Release: squeeze/sid
APT prefers stable
APT policy: (700, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-bpo.2-686 (SMP w/2 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages socat depends on:
ii libc6 2.7-18
ii libreadline5 5.2-4
ii libssl0.9.8 0.9.8g-15+lenny5
ii libwrap0 7.6.q-16
> I know the transfer protocol is not exactly efficient because it's using
> very small blocksize (16 bytes packets with a few extra bytes for
> framing), but that doesn't explain the difference on other machines.
> Note that I don't have control over the transfer protocol.
>
> Thanks in advance,
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Jef Driesen
> On 2009-12-31, Jef Driesen<jefdr...@hotmail.com.invalid> wrote:
>> Hi,
>>
>> I'm using socat and pseudo terminals, to create two virtual serial ports
>> linked with a null modem cable. The purpose of this setup is to allow
>> two applications to communicate with each other, as if they were talking
>> to real serial ports.
>>
>> socat PTY,link=/tmp/ttyS0 PTY,link=/tmp/ttyS1
>>
>> But I noticed the performance is quite bad. Trying to transmit data
>> takes very long. For instance transmitting 32KB takes a few minutes on
>> my machine (Ubuntu 9.10), while on another user's machine (Mac OS X)
>> it's much faster, in the order of a few seconds.
>>
>> Any idea what is causing this?
>
> In debian squeeze using socat and testing it using sx and rx (from
> the lrzsz package) (128 byte packets one direction one byte responses
> the other) I get 538368 (128 byte) blocks sent in 26s
What commands (and options) did you used? I would like to reproduce your
test to compare.
Jasen Betts
in three different terminals:
terminal 1: socat PTY,link=/tmp/ttyS0 PTY,link=/tmp/ttyS1
terminal 2: sx music.raw >>/tmp/ttyS0 </tmp/ttyS0
terminal 3: time rx /tmp/foo.dat >/tmp/ttyS1 </tmp/ttyS1
music.raw was the largest file in my home directory
time on the third line is optional
Jef Driesen
I reproduced that test with a 538368 byte file, filled with random data:
dd if=/dev/urandom of=test.bin bs=538368 count=1
So that's 128 times less data than in your test, and it takes already
2m49s. That's an enormeous difference!
$sx test.bin >>/tmp/ttyS0 </tmp/ttyS0
Sending test.bin, 4206 blocks: Give your local XMODEM receive command now.
Bytes Sent: 538368 BPS:2482
Transfer complete
$ time rx out.bin >/tmp/ttyS1 </tmp/ttyS1
rx: ready to receive out.bin
Bytes received: 538368 BPS:3177
Transfer complete
real 2m49.490s
user 0m0.000s
sys 0m0.000s
David Schwartz
> $sx test.bin >>/tmp/ttyS0 </tmp/ttyS0
> Sending test.bin, 4206 blocks: Give your local XMODEM receive command now.
> Bytes Sent: 538368 BPS:2482
>
> Transfer complete
> $ time rx out.bin >/tmp/ttyS1 </tmp/ttyS1
>
> rx: ready to receive out.bin
> Bytes received: 538368 BPS:3177
I get 28,000-30,000 BPS running the same test on a Fedora 12 box.
DS
Jasen Betts
both of you so slow?
I get 100 times faster speeds.
rx: ready to receive /tmp/foo.dat
Bytes received: 68911104 BPS:2240791
entry level intel CPU purchased in 08
model name : Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz
bogomips : 4800.03
stock debian kernel
2.6.30-bpo.2-686 #1 SMP Tue Sep 22 14:34:48 UTC 2009 i686 GNU/Linux
David Schwartz
> both of you so slow?
>
> I get 100 times faster speeds.
>
> rx: ready to receive /tmp/foo.dat
> Bytes received: 68911104 BPS:2240791
>
> entry level intel CPU purchased in 08
>
> model name : Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz
> bogomips : 4800.03
>
> stock debian kernel
Weird. I think it's worth someone with scheduler knowledge poking
into. It seems that for some reason, the handoffs from one process to
another take longer than they should. I tried tweaking some scheduler
parameters, but saw no changes.
DS
Jef Driesen
When running from a Fedora 12 livecd on the same hardware, I get about
the same number (29933 BPS).
Jef Driesen
My system is a Lenovo 3000 N100 laptop (Intel Core 2 Duo T5600 1.83GHz,
2GB RAM). Stock Ubuntu 9.10 kernel:
2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64
GNU/Linux
Thus somewhat older, but not an outdated machine.
David Schwartz
> When running from a Fedora 12 livecd on the same hardware, I get about
> the same number (29933 BPS).
It's because CONFIG_HZ=1000.
128 (bytes per block) * 1000 (jiffies/sec) / 4 (master-slave exchanges
per block) = 32,000 bytes/sec.
Each master/slave exchange is delayed one jiffy, intentionally. (See
my other post.)
DS
Jef Driesen
That would explain why my Ubuntu system is 10 times slower, because it
seems the Ubuntu kernel is build with CONFIG_HZ=100. (I'm not 100% sure
about this, because that options appears in a number of config files,
and in some of them there is also CONFIG_HZ=250.)
Jasen Betts
I seem to have CONFIG_HZ=250 here too. Anyway, the kernel should not be waiting
for the end of the timeslice to switch tasks. Once the task enters a
blocking select() or fills the output buffer some other task with unfinished
business, or a now unblocked select() will start.
Rainer Weikusat
> On 2010-01-04, Jef Driesen <jefdr...@hotmail.com.invalid> wrote:
>> On 04/01/10 18:05, David Schwartz wrote:
>>> On Jan 4, 7:16 am, Jef Driesen<jefdrie...@hotmail.com.invalid> wrote:
>>>
>>>> When running from a Fedora 12 livecd on the same hardware, I get about
>>>> the same number (29933 BPS).
>>>
>>> It's because CONFIG_HZ=1000.
>>> 128 (bytes per block) * 1000 (jiffies/sec) / 4 (master-slave exchanges
>>> per block) = 32,000 bytes/sec.
>>>
>>> Each master/slave exchange is delayed one jiffy, intentionally. (See
>>> my other post.)
>>
>> That would explain why my Ubuntu system is 10 times slower, because it
>> seems the Ubuntu kernel is build with CONFIG_HZ=100. (I'm not 100% sure
>> about this, because that options appears in a number of config files,
>> and in some of them there is also CONFIG_HZ=250.)
>
> I seem to have CONFIG_HZ=250 here too. Anyway, the kernel should not be waiting
> for the end of the timeslice to switch tasks.
In this particular case, the tty-code apparently delays input
processing for 1 jiffy (1/HZ seconds).
Grant Edwards
> In this particular case, the tty-code apparently delays input
> processing for 1 jiffy (1/HZ seconds).
There's a "low latency" flag that you can set on "real" serial
ports to disable that 1 jiffy polling of the input buffer. I
don't know if the pty driver supports that or not (there are a
lot of serial port features that aren't supported by the pty
driver).
--
Grant Edwards grante Yow! I've got a COUSIN
at who works in the GARMENT
visi.com DISTRICT ...
Jasen Betts
I'm not seeing that here, perhaps debian turns that delay off.