| 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
| ||
|
Message-ID: <20091122002748.GA6605@swanrl.gmail.com> Date: Sun, 22 Nov 2009 11:27:48 +1100 From: Robert Swan <swan.r.l@...il.com> To: Alan Cox <alan@...rguk.ukuu.org.uk> Cc: linux-kernel@...r.kernel.org Subject: Re: [bisected] pty performance problem On Sat, Nov 21, 2009 at 11:23:20PM +0000, Alan Cox wrote: > > I can provide reasonably stripped down code which demonstrates the > > problem. It has been reproduced by one other person, though his delay > > was about 2ms. > > I would expect that. > > I guess the obvious question would be "why are you using ptys for latency > sensitive communications ?" They now queue like other ttys which fixes a > whole ton of stuff but does mean they have normal tty latencies. I have a client program designed to communicate with an external device through a serial port. It polls this device every 20ms or so. I also have a server to simulate the physical device which allows me to replay values captured previously (for testing and tuning the client). This simulated run doesn't usually need to model the elapsed time so I can set the inter-polling delay to 0. Obviously the 8ms delay I now get drastically slows down these replays. While I could rewrite the communications to optionally use pipes, or get the client to reprocess a log file locally, what I have does seem a reasonable use of ptys. Have fun, Rob. -- 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