[9fans] drawterm strangeness

[9fans] drawterm strangeness

[andrey mirtchovski]

I'm observing some strangeness in drawterm on Linux. I know it's not
supported at all, but I'd like to take this out in the open, just in case
somebody can think of an off-hand solution.

It has to do with updating the image, but I'm not sure whether it's not
related to Russ Cox' latency observation from few weeks ago:

When displaying graphics-heavy programs under drawterm-linux I observe that
the screen updates in bursts occuring exactly one second one after another.
For example, dragging a new window (especially enlarging it rapidly) would
result in the screen updating only a single, or at most two times per
second.

When running the same few draw()-intensive programs I measured the
connection utilization to peak at 20mbit/s (100mbit link). Starting new
programs to separate the load between them did not result in any increase in
throughput to the linux box. The load on the server was not max-ed out, but
the ethernet counters in 'stats' were.

On the other hand an scp of a very large file resulted in transfer speeds of
97mbit/s (as measured on the Linux side).

No writing or reading from disk was involved (writing same file to kfs
instead of /dev/null or ramfs caused the transfer speed to drop down to
10-20mbit/s, but that's not an issue).

I did the same test with Plan 9 running under vmware of the exact same
hardware and observed the same behaviour. I do not observe this behaviour
when connecting from a plan9 terminal or from the same vmware session.

The reason I'm having trouble with this is that the brand spanking new cpu
server is hardly usable with drawterm -- especially when heavy editing is
involved..

thanx for any help with this: andrey

ps: one suggestion I heard was to blame nagel's algorithm for this, but the
9fans archives suggest that plan9 doesn't do nagel at all...

Re: [9fans] drawterm strangeness

[Russ Cox]

> ps: one suggestion I heard was to blame nagel's algorithm for this, but the
> 9fans archives suggest that plan9 doesn't do nagel at all...

yes but linux might be delaying the responses.
make sure the devip-unix.c you are using says
something about TCP_NODELAY.

Re: [9fans] drawterm strangeness

[andrey mirtchovski]

You were completely right -- linux' nagel was delaying it. Apparently the
binary I was using wasn't compiled with TCP_NODELAY. In FreeBSD there's a
sysctl to turn Nagel off, but not in Linsux.

I recompiled drawterm with TCP_NODELAY in and the speed went up to 50mbit/s
with very smooth display of images, scrolling and the like.

Here's a buglet for drawterm if you're interested (compiled on
Linux/RH8.0/2.4.20/gcc3.2):

    - ifdef-ed "#include <linux/tcp.h>" in devip-unix.c (that's where
      TCP_NODELAY is defined now for Linux)

    - mk 'CONF=Linux' would not succeed because of unresolved symbols. It
      needs '-ldl -lpthread' now to compile.

    - interestingly enough mk 'CONF=FreeBSD' works just fine in Linux,
      (apart from the fact that linux/tcp.h needs to be in devip-unix.c)

    - doprint.c:530 -- change to:

            rune = (Rune)va_arg(*arg, unsigned int);

      reason: va_arg() doesn't accept shorts as the second argument anymore.

cheers: andrey

On Fri, 6 Jun 2003, Russ Cox wrote:

> yes but linux might be delaying the responses.
> make sure the devip-unix.c you are using says
> something about TCP_NODELAY.
>

Re: [9fans] drawterm strangeness

[andrey mirtchovski]

On Thu, 5 Jun 2003, andrey mirtchovski wrote:

> No writing or reading from disk was involved (writing same file to kfs
> instead of /dev/null or ramfs caused the transfer speed to drop down to
> 10-20mbit/s, but that's not an issue).
>

bah! i take that back! with dma on i can transfer between linux and plan9
(writing to kfs) at 90+mbits/s on a 100baseT connection...

feels like i've been asleep for three years and just woke up -- i see the
light!

i urge you to turn dma/rwm on.

Re: [9fans] drawterm strangeness

[ron minnich]

On Tue, 24 Jun 2003, andrey mirtchovski wrote:

> i urge you to turn dma/rwm on.

This seems like something that just "ought to be" on. Why would it not be?

ron

Re: [9fans] drawterm strangeness

[andrey mirtchovski]

On Tue, 24 Jun 2003, ron minnich wrote:

>
> This seems like something that just "ought to be" on. Why would it not be?
>

there must be a reason -- otherwise why would they put it in the bugs
section of the sd man page?

from http://plan9.bell-labs.com/magic/man2html?man=sd&sect=3

	ATA(PI) units come up with DMA and multi-sector read/write capability
	disabled.

Re: [9fans] drawterm strangeness

[boyd, rounin]

> ATA(PI) units come up with DMA and multi-sector read/write capability
> disabled.

gawd, give me a massbus rm03 anyday.

Re: [9fans] drawterm strangeness

[jmk]

On Tue Jun 24 09:46:25 EDT 2003, rminnich@lanl.gov wrote:
> On Tue, 24 Jun 2003, andrey mirtchovski wrote:
>
> > i urge you to turn dma/rwm on.
>
> This seems like something that just "ought to be" on. Why would it not be?
>
> ron

The reason it's not on by default is that the driver currently does not do any
DMA configuration by itself. In order to set up a DMA mode, both the ATA controller
and the drive have to be configured appropriately. Setting the drive is
straightforward, but setting the ATA controller is chip-specific. Instead, the driver
makes the assumption that if you enable DMA, you know that the BIOS has configured
both the drive and the controller correctly and that is not always the case. Plus,
there are combinations of drives and controllers and DMA modes which don't work
correctly, so the driver errs on the side of safety by default. If you know it's OK,
it's easy to put the enable in cpurc.

I did do some work on restructuring the ATA driver to make some of this possible,
but it is incomplete.