NetBSD-Bugs archive

[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

On Sep 25,  9:45am, (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
|  that...

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!


Home | Main Index | Thread Index | Old Index