On stardate Wed, 10 Dec 2003, the wise Mark Terribile entered:

> When something is slow, the first thing to learn is _why_ it is slow.
> With it running, call up  systat 1 -vmstat  (systat-one-dash-vmstat) and
> look at the bar graph from the lhs to the center of the display.  If you
> see lots of dashes or angle brackets, the problem is with user-level code
> such as  ghostscript .  If you see lots of equal signs, then something in
> the kernel (a driver?) is eating the time.  If you see lots of plus signs,
> then a lot of time is being spent fielding interrupts, which suggests that
> the communication between the computer and the printer is not well handled.
> (Parallel ports are horrible in this way.)  If there is not a lot of CPU
> being used, then the problem lies in the printer or in the precise
> instructions is is being given -- or else in some other source of delay in
> the computer.  In an extreme case, heavy disk I/O could do this; you'll see
> that in the display on the bottom left to bottom center.
> Once you know where the bottleneck is, or at least where it ISN'T, you
> can look for the precise problem and the real fix.
> systat -vmstat may be the best thing a performance-concious developer
> will find in FreeBSD.  Apart, that is, from a system which wants to run
> fast if only you'll let it.

I did the test:
- When ps is busy processing the document, a lot of angle brackets are
visible in the middle of the graph (under user). But only for a second or
- When the data is sent to the printer, a split second one plus sign is
visible under sys.

After that everything returns to "normal" as if nothing is busy and the
data is being sent to the printer and the printer starts printing.

At first I thought the bottleneck is the speed of my network and the speed
the data is sent tot the printer. But it has to be something else because
when I attach a laptop to my network (with Win2000) it's printing 10 ppm.

I got the impression that the printer is processing the data coming from
Windows a lot faster than when the data is coming from FreeBSD.

A [golf] ball hitting a tree shall be deemed not to have hit the tree.
Hitting a tree is simply bad luck and has no place in a scientific
game.  The player should estimate the distance the ball would have
traveled if it had not hit the tree and play the ball from there,
preferably atop a nice firm tuft of grass.
                -- Donald A. Metz
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to