On Fri, 9 Sep 2011 09:38:31 -0400
Matthew Mondor wrote:
> On Fri, 9 Sep 2011 00:26:43 + (UTC)
> chris...@astron.com (Christos Zoulas) wrote:
>
> > Please file a PR about this. I've been meaning to fix it.
>
> Thanks, I will.
For reference and to close this thread, the relevant PR was kern/
On Fri, Sep 09, 2011 at 05:11:17PM -0700, Erik Fair wrote:
>
> ... unless they're using jumbo frames. Potentially 9Kbytes, depending upon
> NICs and switches.
...which reminds me that someday, I will eventually finish my "9k MTU
demonstrated harmful" informational RFC.
The original research whi
On Sep 8, 2011, at 14:45, Thor Lancelot Simon wrote:
> On Thu, Sep 08, 2011 at 11:26:29AM -0400, Matthew Mondor wrote:
>>
>> It would be nice to for instance be able to use an MTU of 3000 so that
>> there are less context switches, but unfortunately tracing the
>> processes show that 1024 bytes
On Fri, Sep 09, 2011 at 09:37:08AM -0400, Matthew Mondor wrote:
> and OpenBSD with it being absent on Linux. But pppd also uses the
> in-kernel ppp support I think, which is probably different than Linux's.
The IP payload traffic should never go to userland, so I don't see how the
pty limit could
On Fri, 09 Sep 2011 08:30:51 +1000
matthew green wrote:
> > I looked at the various tty(4) termios(4) and pty(4) without finding an
> > option to change the buffer size. Is there a way at all to change it?
>
> there's no option. infact, it's all hard coded as magic 1024 constants
> in about 4
On Fri, 9 Sep 2011 00:26:43 + (UTC)
chris...@astron.com (Christos Zoulas) wrote:
> Please file a PR about this. I've been meaning to fix it.
Thanks, I will.
--
Matt
On Thu, 8 Sep 2011 17:45:38 -0400
Thor Lancelot Simon wrote:
> On Thu, Sep 08, 2011 at 11:26:29AM -0400, Matthew Mondor wrote:
> >
> > It would be nice to for instance be able to use an MTU of 3000 so that
> > there are less context switches, but unfortunately tracing the
> > processes show that
On Fri, Sep 09, 2011 at 08:38:59AM +0200, Rhialto wrote:
> > There's also a possible issue with direct selection data transfer
> > versus INCR data transfer, but in xterm's case that is unlikely to be
> > what's behind your problem. It's hard to be sure; you outline
> > conditions under which
On Thu 08 Sep 2011 at 22:56:29 -0400, Mouse wrote:
> There's also a possible issue with direct selection data transfer
> versus INCR data transfer, but in xterm's case that is unlikely to be
> what's behind your problem. It's hard to be sure; you outline
> conditions under which you see misbehavio
> I wonder if the pty buffer size is what is limiting my pastes in
> xterms.
Could be. But there is another possible culprit.
I've long had issues with pastes in my own terminal emulator. Every
once in a while I ahve a look. The most recent look led to this
fragment of the main .c file, in the
In article <201109081526.p88fqt1q002...@ginseng.pulsar-zone.net>,
Matthew Mondor wrote:
>Hello,
>
>I've been wondering if it was possible to change the pty(4) internal
>buffer size, as I noticed that ppp tunnels cannot use a larger frame
>size. Because of this, it seems that the optimal MTU be 8
> I've been wondering if it was possible to change the pty(4) internal
> buffer size, as I noticed that ppp tunnels cannot use a larger frame
> size. Because of this, it seems that the optimal MTU be 856, which is
> so small that context switches become the bottleneck.
>
> It would be nice to fo
On Thu, Sep 08, 2011 at 11:26:29AM -0400, Matthew Mondor wrote:
>
> It would be nice to for instance be able to use an MTU of 3000 so that
> there are less context switches, but unfortunately tracing the
> processes show that 1024 bytes are read from the pty devices at most.
Are you sure using an
I wonder if the pty buffer size is what is limiting my pastes in xterms.
I notice them when pasting more than a few text lines (about 23 medium
filled lines is the limit in a quick test I just did; wc tells me 1025
characters including an extra newline to terminate the final partial
line) into vi
14 matches
Mail list logo
