Is anyone else running with this? Does it help?
On Sat, Dec 24, 2011 at 08:15:54AM +, Nicholas Marriott wrote:
> Hi
>
> Here is a new diff with a window option (rate-limit, 0 is off) and man
> page bits.
>
> I'd like to be able to fix this in a way where we can turn it on by
> default but
Hi
Here is a new diff with a window option (rate-limit, 0 is off) and man
page bits.
I'd like to be able to fix this in a way where we can turn it on by
default but I don't want to do it now.
Even with rate-limit of 100K, running "top" is visibly slower than with
rate-limit disabled. I don't thi
So far, no problems.
I actually left yes running in another window for 15+ minutes, and
ctrl-c was caught in a second or so.
No problems with interactive behaviour that I can see.
\o/
Do you have a wishlist somewhere? :)
-Robin
On Fri, Dec 23, 2011 at 01:37:00PM -0800, Robin Lee Powell wrote
That works wonderfully!
I've only done basic testing with "yes $(seq 1 1000)". The highest
value I found where the response to ctrl-c was instant was
#define BYTES_MAX 10
That happens to be about the total on-screen characters of my
terminal times 5. If it was me, I'd set it to that or som
Ok ssh changes the game quite a lot. Can you try the diff I sent and see
if that helps and if so what value for BYTES_MAX is acceptable?
If it doesn't help let me know, I have another diff to rate limit
outgoing data that might help instead. Or if not that, there is other
stuff we can try.
On Mo
On Tue, Dec 20, 2011 at 12:04:28AM +, Nicholas Marriott wrote:
> On Mon, Dec 19, 2011 at 03:59:39PM -0800, Robin Lee Powell wrote:
> > I've never had this level of problem with screen, at all, and I
> > used it for many many years for everything.
> >
> > On Mon, Dec 19, 2011 at 11:43:04PM +000
This is all over SSH, via PuTTY from windows, to a new/fast linux
box in the same house. I'll give you more details on the terminals
in a bit.
-Robin
On Tue, Dec 20, 2011 at 12:29:27AM +, Nicholas Marriott wrote:
> They are much the same on the Linux console too as far as I can tell
> with y
They are much the same on the Linux console too as far as I can tell
with yes. I guess you are doing something different, either using tmux
over ssh, or using a relatively old machine.
On Tue, Dec 20, 2011 at 12:20:57AM +, Nicholas Marriott wrote:
> I thought it might be xterm, so I tried rxv
I thought it might be xterm, so I tried rxvt. And indeed now screen can
terminate yes pretty much instantly.
But so can tmux. So no help there.
On Mon, Dec 19, 2011 at 03:59:39PM -0800, Robin Lee Powell wrote:
> I've never had this level of problem with screen, at all, and I used
> it for many
On Mon, Dec 19, 2011 at 03:59:39PM -0800, Robin Lee Powell wrote:
> I've never had this level of problem with screen, at all, and I used
> it for many many years for everything.
>
> On Mon, Dec 19, 2011 at 11:43:04PM +, Nicholas Marriott wrote:
> > screen does not successfully rate limit eithe
I've never had this level of problem with screen, at all, and I used
it for many many years for everything.
On Mon, Dec 19, 2011 at 11:43:04PM +, Nicholas Marriott wrote:
> screen does not successfully rate limit either or if it does
> nobody has yet to clearly demonstrate a case where it does
screen does not successfully rate limit either or if it does nobody has
yet to clearly demonstrate a case where it does. It's response times for
running eg "yes" and hitting ^C or creating a new window are roughly the
same as tmux, give or take a few seconds.
On Mon, Dec 19, 2011 at 03:22:29PM -
For example, try this which rate limits input from each pane down to
19200 bps.
You'll notice that interactive commands like "top" will noticeably
pause.
But it will have no real impact on a fast output command such as "yes"
- this is because scrolling is expensive so "yes" can do a lot of damage
On Mon, Dec 19, 2011 at 11:20:29PM +, Nicholas Marriott wrote:
> This is actually quite a hard problem.
;( I thought it might be. Steal the code from screen? :D
> The issue is that it is difficult on a fast machine to rate limit
> vast, continuous amounts of data quickly enough and to a sl
This is actually quite a hard problem.
The issue is that it is difficult on a fast machine to rate limit vast,
continuous amounts of data quickly enough and to a slow enough rate that
tmux can remain responsive, without affecting interactive programs which
need to send a lot of data quickly in bur
I have literally been watching the output of "perl -d:Trace" for
more than 10 minutes, waiting to be granted control of my terminal
again. :( I can't do any tmux commands at all.
-Robin
--
http://singinst.org/ : Our last, best hope for a fantastic future.
Lojban (http://www.lojban.org/): The
16 matches
Mail list logo
