lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Thu, 11 Mar 2010 12:24:24 +0100
From:	Jef Driesen <jefdriesen@...mail.com>
To:	linux-kernel@...r.kernel.org
Subject: Low latency mode and performance of pty's?

Hi,

I have an application that uses a pair of pseudo terminals (using socat 
to link them together) to simulate a serial nullmodem cable. I use this 
setup to simulate the serial communication with an external device in my 
test environment. It works fine, but I noticed the performance is quite bad.

You can reproduce the problem by running these commands in three 
different terminals:

# Terminal 1: Setup the pty's.
socat PTY,link=/tmp/ttyS0 PTY,link=/tmp/ttyS1

# Terminal 2: Send some data.
dd if=/dev/urandom of=input.bin bs=538368 count=1
sx input.bin >>/tmp/ttyS0 </tmp/ttyS0

# Terminal 2: Receive the data data.
time rx output.bin >/tmp/ttyS1 </tmp/ttyS1

On my system, this takes about 2m49s, which is much longer than it 
should be. After some discussion in the comp.unix.programmer [1] and 
comp.os.linux.development.apps [2] newsgroups, I learned pty's have a 
low latency flag, which is disabled by default. When patching my kernel 
to enable this flag (patch included at the end of this post), the 
transfer time goes down to about 30s. When running my own applications, 
it's get even better and the transfer is almost instantly.

Now, the reason why I'm reporting this on LKML is that the patch I 
applied is almost identical to a commit [3] that got reverted again [4]. 
Based on the comment in that last commit, the slow performance was 
addressed in another way, but according to my measurements it isn't. Or 
at least it's not as good as setting the low latency flag directly. 
Unfortunately I don't have any experience with kernel development and I 
have no idea how to fix this properly.

[1] 
http://groups.google.com/group/comp.unix.programmer/browse_thread/thread/503d529448f045e5
[2] 
http://groups.google.be/group/comp.os.linux.development.apps/browse_thread/thread/e6041109eb91aaf7/fccf3946dce9c4b1
[3] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3a54297478e6578f96fd54bf4daa1751130aca86
[4] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e043e42bdb66885b3ac10d27a01ccb9972e2b0a3

Thanks,

Jef

--- drivers/char/pty.c.orig	2010-01-11 13:00:58.000000000 +0100
+++ drivers/char/pty.c	2010-01-11 13:01:04.000000000 +0100
@@ -200,6 +200,8 @@ static int pty_open(struct tty_struct *t
   	if (tty->link->count != 1)
   		goto out;

+	tty->low_latency = 1;
+
   	clear_bit(TTY_OTHER_CLOSED, &tty->link->flags);
   	set_bit(TTY_THROTTLED, &tty->flags);
   	retval = 0;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ