Hello,
Just for my information, on what version of, I think, Ghostscript, Plan9
PostScript rendering is based?
Because, under Plan9, the rendering for example of the AMS-TeX
guide (the package AMS-TeX for kerTeX has been added) is absolutely
beautiful, while the same thing rendered on an Unix wit
> Just for my information, on what version of, I think, Ghostscript,
> Plan9 PostScript rendering is based?
It seems to be Ghostscript 8.53 (2005-10-20).
--
David du Colombier
On Tue, Mar 06, 2012 at 10:39:32AM +0100, David du Colombier wrote:
> > Just for my information, on what version of, I think, Ghostscript,
> > Plan9 PostScript rendering is based?
>
> It seems to be Ghostscript 8.53 (2005-10-20).
And on my NetBSD, Ghostscript 8.71 (2010-09-05).
I still wonder if
> if i force polling, it's a little faster: 0.01u 0.45s 17.70r
That's interesting - it shouldn't make a difference unless there's something
wrong with the controller or the driver. What did you do to force polling?
> holding a second, time wouldn't show interrupt-handling time, correct?
Yes, I
> if you could temporarly run a 9atom kernel,
cpu% dd -if /dev/sdU0.0/data -of /dev/null -count 1024 -bs 65536
/dev/irqalloc yields
trapirq delta count delta cyclestypename
35 3 27648 510854000 i8259 usbehci
which doesn't seem extraordinary. and n
> my working theory is that i'm getting all the interrupts, but not soon
> enough... the fascinating piece is that the olpc and the pc with intel
> ehc take just about the same amount of time.
indeed, if i set the interrupt threshold control to 1 micro-frame (they
default to 8), i get 10-11 sec dd
> indeed, if i set the interrupt threshold control to 1 micro-frame (they
> default to 8), i get 10-11 sec dd, say, half as slow.
That seems a good change to make. Particularly for usb mass storage,
which for some reason emulates a scsi transaction with three usb
transfers and therefore three int
On Tue Mar 6 10:37:06 EST 2012, 9p...@imu.li wrote:
> > my working theory is that i'm getting all the interrupts, but not soon
> > enough... the fascinating piece is that the olpc and the pc with intel
> > ehc take just about the same amount of time.
>
> indeed, if i set the interrupt threshold c
I've been taking the time to finally setup pxeboot for a few new projects.
Oddly, or maybe not, I'm wanting to run dhcpd and tftpd on /net.alt instead of
/net. Doing so highlights a subtle point that I've clearly missed in the whole
namespace documentation and network configuration.
ip/dhcpd
> ip/dhcpd -x /net.alt works perfectly well but ip/tftpd -x /net.alt will fail
> unless you've got a custom /lib/namespace or /cfg/$sysname/namespace that
> includes something similar to the following:
>
> # alt networks
> bind -b '#l1' /net.alt
> bind -b '#I1' /net.alt
> mount -a /srv/cs_net.a
i tried another device a bit ago. openrd (kw). with and without setting
the interrupt delay to 1 microframe. i get just about the same times (a
little higher). does anybody get less than 10 sec for
dd -if /dev/sdU0.0/data -of /dev/null -count 1024 -bs 65536 ?
or even less than 20 sec?
that is, i
a little reading later.
the usb mass storage bulk only spec stipulates that only one request may
be active at a time.
wince.
so, bigger buffer? yup, 32k reads double the speed again. 64k reads
aren't quite right, something clips it's tail. now i'm up to ~11 MB/s.
except that it crashes the pc
> anybody messed with devmnt's Msgsize successfully?
make that devmnt's MAXRPC, in usbfs.h it's Msgsize.
enjoy,
tristan
--
All original matter is hereby placed immediately under the public domain.
13 matches
Mail list logo
