From: Soeren Sonnenburg <kernel@nn7.de>
To: Kenneth Johansson <ken@kenjo.org>
Cc: Mike Fedyk <mfedyk@matchmail.com>,
Willy Tarreau <willy@w.ods.org>,
szonyi calin <caszonyi@yahoo.com>,
azarah@nosferatu.za.org, Con Kolivas <kernel@kolivas.org>,
Mark Hahn <hahn@physics.mcmaster.ca>,
Linux Kernel Mailing Lists <linux-kernel@vger.kernel.org>,
gillb4@telusplanet.net
Subject: solved (was Re: xterm scrolling speed - scheduling weirdness in 2.6 ?!)
Date: Fri, 02 Apr 2004 20:22:12 +0200 [thread overview]
Message-ID: <1080930132.1720.38.camel@localhost> (raw)
In-Reply-To: <1073296227.8535.34.camel@tiger>
On Mon, 2004-01-05 at 10:50, Kenneth Johansson wrote:
> On Mon, 2004-01-05 at 00:47, Mike Fedyk wrote:
> > On Mon, Jan 05, 2004 at 12:33:12AM +0100, Willy Tarreau wrote:
> > > at a time. I have yet to understand why 'ls|cat' behaves
> > > differently, but fortunately it works and it has already saved
> > > me some useful time.
> >
> > cat probably does some buffering for you, and sends the output to xterm in
> > larger blocks.
>
> you can try with "ls |dd bs=1"
>
> I also see this problem but it is not constant. I noticed that "ps ax"
> sometimes takes like 10 times longer than usual. But I can only get this
> in a gnome-terminal not in xterm. The problem is that it should really
> not be that big difference when the load of the system is the same.
Ok, there is indeed an issue in the *terminals. As above pointed out
buffering the programs output helps. Also a usleep of 5ms in the read
loop of the *terms would help.
I fixed this issue in multi-gnome-terminal by using a buffer of 32kb.
It is filled as long as there is input comming in within 10ms.
If the buffer is full or 10ms passed the buffer is written out to the
screen. This makes it also 2-3 times faster on kernel 2.4.
So in my eyes it is definitely not a scheduler bug, but in every single
terminal out there. However it seems as if kernel 2.6 s scheduling is so
fast that data can be continously outputted. And the busy loop in the
terminal makes it eat up all cpu time instead of jump scrolling take
place.
static void
zvt_term_readdata (gpointer data, gint fd, GdkInputCondition condition) {
[...]
+ while ( (count>0) && (select_retval==1) && (total_count<32768) )
+ {
+ count=0;
+ int maxread=32768-total_count;
+ if (maxread>4096)
+ maxread=4096;
+
+ count = read (fd, &buffer[total_count], maxread);
+ saveerrno=errno;
[...]
+ if (count>0)
+ total_count+=count;
+
+ FD_ZERO(&rfds);
+ FD_SET(fd, &rfds);
+ tv.tv_sec = 0;
+ tv.tv_usec = 10000;
+ select_retval = select(fd+1, &rfds, NULL, NULL, &tv);
[...]
+ }
Soeren.
next prev parent reply other threads:[~2004-04-02 18:27 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44.0401031439060.24942-100000@coffee.psychology.mcmaster.ca>
2004-01-03 20:19 ` xterm scrolling speed - scheduling weirdness in 2.6 ?! Soeren Sonnenburg
2004-01-03 21:00 ` Con Kolivas
2004-01-03 21:10 ` Soeren Sonnenburg
2004-01-03 21:15 ` Con Kolivas
2004-01-03 23:35 ` Willy Tarreau
2004-01-04 0:11 ` Soeren Sonnenburg
2004-01-04 1:42 ` Con Kolivas
2004-01-04 3:32 ` Tim Connors
2004-01-04 5:58 ` Con Kolivas
2004-01-06 1:09 ` Peter Osterlund
2004-01-06 1:37 ` Nick Piggin
2004-01-06 2:28 ` Peter Osterlund
2004-01-06 2:50 ` Nick Piggin
2004-01-06 6:27 ` Nick Piggin
2004-01-05 22:25 ` Bryan Whitehead
2004-01-04 8:09 ` Soeren Sonnenburg
2004-01-04 8:49 ` Con Kolivas
2004-01-04 11:13 ` Martin Schlemmer
2004-01-04 11:24 ` Soeren Sonnenburg
2004-01-04 12:45 ` Con Kolivas
2004-01-04 14:42 ` Martin Schlemmer
2004-01-04 18:40 ` mikeg
2004-01-04 22:58 ` szonyi calin
2004-01-04 23:33 ` Willy Tarreau
2004-01-04 23:44 ` Valdis.Kletnieks
2004-01-04 23:47 ` Mike Fedyk
2004-01-05 8:39 ` Soeren Sonnenburg
2004-01-05 20:38 ` Martin Schlemmer
2004-01-05 9:18 ` Soeren Sonnenburg
2004-01-05 17:20 ` Martin Schlemmer
2004-01-05 17:21 ` Willy Tarreau
2004-01-05 9:50 ` Kenneth Johansson
2004-01-05 10:17 ` Soeren Sonnenburg
2004-04-02 18:22 ` Soeren Sonnenburg [this message]
2004-04-03 5:35 ` solved (was Re: xterm scrolling speed - scheduling weirdness in 2.6 ?!) Tim Connors
2004-04-03 6:06 ` Tim Connors
2004-04-03 14:11 ` Jamie Lokier
2004-01-05 8:26 ` xterm scrolling speed - scheduling weirdness in 2.6 ?! Soeren Sonnenburg
2004-01-04 8:54 ` Lincoln Dale
2004-01-04 9:17 ` Nick Piggin
2004-01-04 10:24 ` Soeren Sonnenburg
2004-01-04 11:12 ` Mike Fedyk
2004-01-04 11:17 ` Soeren Sonnenburg
2004-01-04 11:20 ` Mike Fedyk
2004-01-04 11:19 ` Willy Tarreau
2004-01-05 0:48 ` Nick Piggin
2004-01-04 11:46 ` Nicks's scheduler's OK [was Re: xterm scrolling speed - scheduling weirdness in 2.6 ?!] Willy Tarreau
2004-01-04 12:07 ` xterm scrolling speed - scheduling weirdness in 2.6 ?! Willy Tarreau
2004-01-05 0:51 ` Nick Piggin
2004-01-05 18:37 ` Willy Tarreau
2004-01-06 0:33 ` Nick Piggin
2004-01-04 10:11 ` Soeren Sonnenburg
2004-01-05 10:31 ` venom
2004-01-03 21:18 ` Willy Tarreau
2004-04-03 20:53 solved (was Re: xterm scrolling speed - scheduling weirdness in 2.6 ?!) Soeren Sonnenburg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1080930132.1720.38.camel@localhost \
--to=kernel@nn7.de \
--cc=azarah@nosferatu.za.org \
--cc=caszonyi@yahoo.com \
--cc=gillb4@telusplanet.net \
--cc=hahn@physics.mcmaster.ca \
--cc=ken@kenjo.org \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfedyk@matchmail.com \
--cc=willy@w.ods.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox