[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/45352: pty(4)/tty(4) have a 1024 bytes transfer limit
The following reply was made to PR kern/45352; it has been noted by GNATS.
From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost,
Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
Subject: Re: kern/45352: pty(4)/tty(4) have a 1024 bytes transfer limit
Date: Sun, 25 Sep 2011 11:33:02 -0400
On Sep 25, 9:45am, mm_lists%pulsar-zone.net@localhost (Matthew Mondor) wrote:
-- Subject: Re: kern/45352: pty(4)/tty(4) have a 1024 bytes transfer limit
| I had some trouble with the patch then noticed that there were actually
| -current commits; so reverted to the -current files, then rebuilt a
| kernel and booted it.
| The sysctl setting works great, and with an actual MTU of 3000 this
| time, performance was over 800KB/s for the same file and my pty-udp
| software, vs the max ~170KB/s I was getting with the 1024 bytes limit!
| However, there still seems to be a problem with the ioctl(2), as that
| one doesn't seem to have an effect, somehow:
| opt = (int)buffer_size;
| if (ioctl(fd, TIOCSQSIZE, &opt) == -1)
| err(EXIT_FAILURE, "Couldn't set tty(4) buffer size");
| There is no error but the reads are still reaching the sysctl-set limit
| despite trying to set a larger buffer (that's of course still between
| 1024 and 65536).
I made your test program do the setting on both the master and the
slave and that seems to work.
| Also, would there be a problem with setting the tty buffer size to 4096
| by default, rather than 1024? This would then match the default Linux
| limit, and allow tools like rp-ppoe with common MTU sizes to work
| properly as-is as well.
I don't think that it is a big deal, since it can be set via sysctl.
We can surely change it.
| BTW, for those who wondered how rp-pppoe could have worked, note that
| it was previously possible with our 1024 limit, if not exceeding it too
| much (write size), to read in non-blocking mode until EAGAIN to obtain
| all bytes, yet at the expense of more syscalls and I/O, and the
| occasional loss of a few ending bytes depending on packet size. I've
| not checked the rp-pppoe code in a while, but it might have done just
Yes, that is what bugged me the most; the lost of trailing bytes. I think
that I fixed that (I committed your test program and it does not seem
to lose anymore).
| Interestingly, when doing earlier searches about the problem I was
| having before posting the initial PR, OS/X would also have the 1024
| limit, and Solaris would have an even worse 255 limit; I'm not sure if
| those are defaults or hard-coded, though.
Yes, they seem to be hard-coded.
| Thanks again,
Thanks for the test program which made testing easy!
Main Index |
Thread Index |