Increase performance of pseudo terminals?
in [Unix Programming]
|
From: Jef Driesen on 5 Jan 2010 16:40 On 05/01/10 15:06, David Schwartz wrote: > On Jan 5, 12:42 am, Jef Driesen<jefdrie...(a)hotmail.com.invalid> > wrote: > >> Yes, I rebuild the ubuntu kernel packages, following the instructions on >> this page [1] (I used the apt-get source method). When installing the >> resulting deb package, the previously installed Ubuntu package got >> replaced (and I installed an older kernel too, in case something went >> wrong). After rebooting, uname confirms I'm running the rebuild kernel: > > *sigh* It may be that it rounds up and zero and one have the same > effect. I think you can change: > schedule_delayed_work(&tty->buf.work, 1); > to: > flush_to_ldisc(&tty->buf.work.work); > And it will process it right then and there. But I'm not really sure > it's safe. I tried this, but it doesn't seem to have any effect either. Now I start to wonder if I'm doing something wrong with the patching, or is there really no effect?
From: Rainer Weikusat on 6 Jan 2010 05:29 Jef Driesen <jefdriesen(a)hotmail.com.invalid> writes: > On 05/01/10 15:06, David Schwartz wrote: >> On Jan 5, 12:42 am, Jef Driesen<jefdrie...(a)hotmail.com.invalid> >> wrote: >> >>> Yes, I rebuild the ubuntu kernel packages, following the instructions on >>> this page [1] (I used the apt-get source method). When installing the >>> resulting deb package, the previously installed Ubuntu package got >>> replaced (and I installed an older kernel too, in case something went >>> wrong). After rebooting, uname confirms I'm running the rebuild kernel: >> >> *sigh* It may be that it rounds up and zero and one have the same >> effect. I think you can change: >> schedule_delayed_work(&tty->buf.work, 1); >> to: >> flush_to_ldisc(&tty->buf.work.work); >> And it will process it right then and there. But I'm not really sure >> it's safe. > > I tried this, but it doesn't seem to have any effect either. Now I > start to wonder if I'm doing something wrong with the patching, or is > there really no effect? Are you sure that you are patching the subroutine which is actually called? At least the 2.6.32 pty-code doesn't call tty_schedule_flip.
From: Jef Driesen on 6 Jan 2010 11:41 On 6/01/2010 11:29, Rainer Weikusat wrote: > Jef Driesen<jefdriesen(a)hotmail.com.invalid> writes: >> On 05/01/10 15:06, David Schwartz wrote: >>> On Jan 5, 12:42 am, Jef Driesen<jefdrie...(a)hotmail.com.invalid> >>> wrote: >>> >>>> Yes, I rebuild the ubuntu kernel packages, following the instructions on >>>> this page [1] (I used the apt-get source method). When installing the >>>> resulting deb package, the previously installed Ubuntu package got >>>> replaced (and I installed an older kernel too, in case something went >>>> wrong). After rebooting, uname confirms I'm running the rebuild kernel: >>> >>> *sigh* It may be that it rounds up and zero and one have the same >>> effect. I think you can change: >>> schedule_delayed_work(&tty->buf.work, 1); >>> to: >>> flush_to_ldisc(&tty->buf.work.work); >>> And it will process it right then and there. But I'm not really sure >>> it's safe. >> >> I tried this, but it doesn't seem to have any effect either. Now I >> start to wonder if I'm doing something wrong with the patching, or is >> there really no effect? > > Are you sure that you are patching the subroutine which is actually > called? At least the 2.6.32 pty-code doesn't call tty_schedule_flip. That might be the problem! I did patch the tty_schedule_flip() function. My kernel is 2.6.31-16. Do you happen to know which function needs to be patched? Maybe tty_flip_buffer_push()? It's identical, except that it uses the low_latency flag to choose between schedule_delayed_work and flush_to_ldisc. See the attachments for the patches I tried. In case the newsgroup doesn't allow attachments, they can be downloaded on my website too: http://www.subaquaclub.be/users/jefdriesen/tmp/tty_v1.patch http://www.subaquaclub.be/users/jefdriesen/tmp/tty_v2.patch
From: Rainer Weikusat on 8 Jan 2010 14:19 Jef Driesen <jefdriesen(a)hotmail.com.invalid> writes: > On 6/01/2010 11:29, Rainer Weikusat wrote: >> Jef Driesen<jefdriesen(a)hotmail.com.invalid> writes: >>> On 05/01/10 15:06, David Schwartz wrote: [ tty_schedule_flip ] >>>> *sigh* It may be that it rounds up and zero and one have the same >>>> effect. I think you can change: >>>> schedule_delayed_work(&tty->buf.work, 1); >>>> to: >>>> flush_to_ldisc(&tty->buf.work.work); >>>> And it will process it right then and there. But I'm not really sure >>>> it's safe. >>> >>> I tried this, but it doesn't seem to have any effect either. Now I >>> start to wonder if I'm doing something wrong with the patching, or is >>> there really no effect? >> >> Are you sure that you are patching the subroutine which is actually >> called? At least the 2.6.32 pty-code doesn't call tty_schedule_flip. > > That might be the problem! I did patch the tty_schedule_flip() > function. My kernel is 2.6.31-16. Do you happen to know which function > needs to be patched? Maybe tty_flip_buffer_push()? It's identical, > except that it uses the low_latency flag to choose between > schedule_delayed_work and flush_to_ldisc. The pty_write routine ('hardware write routine' for ptys) calls tty_flip_buffer_push (at least in 2.6.32). But before changing that, I'd try to enable low latency mode for ptys (by setting tty->low_latency to something != 0 in pty_open, for instance). Should this help, I'd consider adding an ioctl (to pty_unix98_ioctl) to enable/disable 'low latency mode' for ptys.
From: Jef Driesen on 11 Jan 2010 08:12 On 8/01/2010 20:19, Rainer Weikusat wrote: > Jef Driesen<jefdriesen(a)hotmail.com.invalid> writes: >> On 6/01/2010 11:29, Rainer Weikusat wrote: >>> Jef Driesen<jefdriesen(a)hotmail.com.invalid> writes: >>>> On 05/01/10 15:06, David Schwartz wrote: > > [ tty_schedule_flip ] > >>>>> *sigh* It may be that it rounds up and zero and one have the same >>>>> effect. I think you can change: >>>>> schedule_delayed_work(&tty->buf.work, 1); >>>>> to: >>>>> flush_to_ldisc(&tty->buf.work.work); >>>>> And it will process it right then and there. But I'm not really sure >>>>> it's safe. >>>> >>>> I tried this, but it doesn't seem to have any effect either. Now I >>>> start to wonder if I'm doing something wrong with the patching, or is >>>> there really no effect? >>> >>> Are you sure that you are patching the subroutine which is actually >>> called? At least the 2.6.32 pty-code doesn't call tty_schedule_flip. >> >> That might be the problem! I did patch the tty_schedule_flip() >> function. My kernel is 2.6.31-16. Do you happen to know which function >> needs to be patched? Maybe tty_flip_buffer_push()? It's identical, >> except that it uses the low_latency flag to choose between >> schedule_delayed_work and flush_to_ldisc. > > The pty_write routine ('hardware write routine' for ptys) calls > tty_flip_buffer_push (at least in 2.6.32). But before changing that, > I'd try to enable low latency mode for ptys (by setting > tty->low_latency to something != 0 in pty_open, for instance). I patched the pty_open() function to set tty->low_latency=1. With this change, transfers are significant faster, but I also get a number of timeout errors in the test: $ socat PTY,link=/tmp/ttyS0,raw,echo=0 PTY,link=/tmp/ttyS1,raw,echo=0 & $ sx input.bin >>/tmp/ttyS0 </tmp/ttyS0 Sending input.bin, 4206 blocks: Give your local XMODEM receive command now. Xmodem sectors/kbytes sent: 462/57kRetry 0: NAK on sector Xmodem sectors/kbytes sent: 545/68kRetry 0: NAK on sector Xmodem sectors/kbytes sent: 956/119kRetry 0: NAK on sector Xmodem sectors/kbytes sent: 2369/296kRetry 0: NAK on sector Xmodem sectors/kbytes sent: 2657/332kRetry 0: NAK on sector Bytes Sent: 538368 BPS:15634 Transfer complete $time rx output.bin >/tmp/ttyS1 </tmp/ttyS1 rx: ready to receive output.bin Retry 0: TIMEOUT 206 Retry 0: TIMEOUT 335 Retry 0: TIMEOUT 188 Retry 0: TIMEOUT 655 Retry 0: TIMEOUT 975 Bytes received: 538368 BPS:17089 Transfer complete real 0m31.509s user 0m0.020s sys 0m0.130s The BPS varied between 9000 and 17000, but it is definitely an improvement over the 3000 I got without the patch. > Should > this help, I'd consider adding an ioctl (to pty_unix98_ioctl) to > enable/disable 'low latency mode' for ptys. I suppose the idea is then to call this ioctl from my userspace code? So the low latency mode is only enabled for my application?
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Linking problem using autotool Next: why do the Muslims bow down to ward the Ka' |