[9fans] man is really slow on a terminal

[9fans] man is really slow on a terminal

[john]

I've been using a nice speedy machine with lots of ram and a fast network interface as
a terminal, pulling root off a Plan 9 server in the next room. Everything works fine,
applications load pretty much immediately, but when I try to read a man page, it
takes forever to print the manual. Although man is pretty slow even when connected
via drawterm, that's nothing compared to the way my terminal is acting. Is there
something with the way man pages are looked up that is slowing stuff down? That
and the really poor performance that comes when I have overlapping windows and
try to bring one forward are the only things that are bugging me on the terminal.

John

Re: [9fans] man is really slow on a terminal

[ron minnich]

On Jan 16, 2008 10:19 AM,  <john@csplan9.rit.edu> wrote:
> That
> and the really poor performance that comes when I have overlapping windows and
> try to bring one forward are the only things that are bugging me on the terminal.
>

That can be fixed via mtrr patches. You can find them in here:
/n/sources/patch/saved/mtrrsupport

We've seen a big improvement in graphics performance with these
patches. They make the graphics memory write back cached.

ron

Re: [9fans] man is really slow on a terminal

[erik quanstrom]

> 
> We've seen a big improvement in graphics performance with these
> patches. They make the graphics memory write back cached.
> 

you mean write combining?

- erik

Re: [9fans] man is really slow on a terminal

[ron minnich]

On Jan 16, 2008 11:05 AM, erik quanstrom <quanstro@coraid.com> wrote:

> you mean write combining?

:-)

I always do that. yes write combining.

ron

Re: [9fans] man is really slow on a terminal

[erik quanstrom]

> On Jan 16, 2008 11:05 AM, erik quanstrom <quanstro@coraid.com> wrote:
> 
> > you mean write combining?
> 
> :-)
> 
> I always do that. yes write combining.
> 
> ron

okay.  sometimes i'm dense.
i'm glad someone beat me to this one.
is there a problem with the generality of this patch?

it would also be nice if the kernel kept it's own copy
of the frame buffer.  nvidia^wmodern graphics cards are just not
designed to be read from.

- erik

Re: [9fans] man is really slow on a terminal

[ron minnich]

On Jan 16, 2008 3:14 PM, erik quanstrom <quanstro@quanstro.net> wrote:

> is there a problem with the generality of this patch?

Note that the patch is saved, and I'm guessing there is a reason: it's
arguably gross to expose the MTRRs to the world. I was thinking about
this. It seems to me that MTRRs could really be managed in mmu.c (but
it's a headache). You would need to know when a device mapped physical
memory that it ought to be cached, and set the MTRRs up properly.

>
> it would also be nice if the kernel kept it's own copy
> of the frame buffer.  nvidia^wmodern graphics cards are just not
> designed to be read from.

I know that is true on AGP, but had understood it to be less true on
PCIe. Is it really so bad on PCIe now?

thanks

ron

Re: [9fans] man is really slow on a terminal

[erik quanstrom]

> On Jan 16, 2008 3:14 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> 
> > is there a problem with the generality of this patch?
> 
> Note that the patch is saved, and I'm guessing there is a reason: it's
> arguably gross to expose the MTRRs to the world. I was thinking about
> this. It seems to me that MTRRs could really be managed in mmu.c (but
> it's a headache). You would need to know when a device mapped physical
> memory that it ought to be cached, and set the MTRRs up properly.

i would think that either aux/vga or the kernel driver for the card in
question could set this up.

> 
> >
> > it would also be nice if the kernel kept it's own copy
> > of the frame buffer.  nvidia^wmodern graphics cards are just not
> > designed to be read from.
> 
> I know that is true on AGP, but had understood it to be less true on
> PCIe. Is it really so bad on PCIe now?

as i understand it, the problem is not the bandwidth of the link.
the problem is that firmware running on the graphics card'is not
set up to handle read requests quickly.  i think they assume that
you're not going to do that.

as one data point, my pcie-based nvidia card raises windows much
more slowly than the older agp one that i have.  and the pcie card
has every advantage.  the agp card runs in a intel celery system.

- erik

Re: [9fans] man is really slow on a terminal

[ron minnich]

On Jan 16, 2008 3:42 PM, erik quanstrom <quanstro@quanstro.net> wrote:

> as i understand it, the problem is not the bandwidth of the link.
> the problem is that firmware running on the graphics card'is not
> set up to handle read requests quickly.  i think they assume that
> you're not going to do that.

I hope, hope, hope that nobody is really setting up firmware to
respond to PCIe reads of the framebuffer. I don't see how this could
be.

"The enormous bidirectional bandwidth of the PCI Express-based NVIDIA
Quadro FX family allows us, for the first time, to utilize the full
power of its graphics processors without any restriction to accelerate
our hybrid, GPU/CPU-based, photo-realistic rendering software, mental
ray," said Rolf Herken, CEO and CTO of mental images. "

Mental images eh?

I like this quote:

"PCI Express blows the server side wide open," says Beth Loughney,
general manager of the NVIDIA Digital Film Group. "

Geez, I thought my old lab was the one that blew stuff up. Ah well.

>
> as one data point, my pcie-based nvidia card raises windows much
> more slowly than the older agp one that i have.  and the pcie card
> has every advantage.  the agp card runs in a intel celery system.

What OS? are you sure this is not an os setup issue?

thanks

ron

Re: [9fans] man is really slow on a terminal

[erik quanstrom]

> 
> I hope, hope, hope that nobody is really setting up firmware to
> respond to PCIe reads of the framebuffer. I don't see how this could
> be.

to read directly from the framebuffer, the video memory in the card
would have to be directly attached to the pcie interface on the card.
i believe that would require a general memory bus & coherency protcol
arbitrating between memory, pcie, and the gpu.

(the old-fashioned solution to this was dual-ported ram.)

of course, this is speculation.  but i think that it's safely not as simple
as just reading video memory.

also, even with the mtrr the reads are not read combining.  it's uncachable
for reads, so it's 32bit pio.  

> >
> > as one data point, my pcie-based nvidia card raises windows much
> > more slowly than the older agp one that i have.  and the pcie card
> > has every advantage.  the agp card runs in a intel celery system.
> 
> What OS? are you sure this is not an os setup issue?

uh, plan 9.

- erik

p.s. i found this link from nvidia on how to make textures faster.
one thing they're concerned about is the *latency* of downloading
textures.  that might apply to reading the fb as well.

http://download.nvidia.com/developer/Papers/2005/Fast_Texture_Transfers/Fast_Texture_Transfers.pdf