j de boyne pollard

SOHS> I really don't understand why Windows should
SOHS> grind to a halt spooling print output, even if it
SOHS> is using the CPU to generate the raster.

Then read Microsoft KnowledgeBase articles 810908, 175893, 163219,
237597, 216905, 840371, and 182333 and gain enlightenment. Note that


Server_. SPOOLSS is a complex beast. It supports a variety of
printing systems, both local and remote printing, plug-ins for third
party print management mechanisms, and quite a few options for both
spooling and status reporting for queued and in-progress jobs. The
architecture for doing that is not trivial. Visualizing the operation
of the spooler as just read-from-file-then-write-to-port is to
visualize it highly incorrectly.

j de boyne pollard

SOHS> I really don't understand why Windows should grind
SOHS> to a halt spooling print output, even if it is using the
SOHS> CPU to generate the raster.

j> Oh, I know. It cannot chew gum and salivate at the same time.
[...]

It's amazing how many statements of this sort there are in this
thread, considering that the very first post in this thread is from a
person who was wondering why xyr Windows NT 5 machine was using almost
zero CPU time (with the CPU spending almost all of its time just
executing the system idle thread) to copy approximately 4GiB of files.

charlton wilbur

JdBP> It's amazing how many statements of this sort there are in
JdBP> this thread, considering that the very first post in this
JdBP> thread is from a person who was wondering why xyr Windows NT
JdBP> 5 machine was using almost zero CPU time (with the CPU
JdBP> spending almost all of its time just executing the system
JdBP> idle thread) to copy approximately 4GiB of files.

Consider the source. Barb, aka BAH, is probably 25 years out of date
with regard to computers; not only has she not kept current with the
state of the art, she refuses to, on the theory that the best way to
understand what the average person will need to cope with is to use a
version of Windows that's more than a decade old. Further, her
commentary tends to boil down to "It's not done the way TOPS-10 did
it, so it's bad," "It was invented by a Democrat, so it's bad," and
"It's not the way DEC did it, so it's bad." When caught out on errors
in fact, sometimes she uses vulgarity to distract, and sometimes she


She has repeatedly refused to actually use a Unixlike or a version of
Windows newer than 3.11 before actually commenting on them, leading to
some spectacular errors in fact and concomitant vulgarity, although
someone (William Pechter?) actually sent her a Linux box that she
appears to have played with a little bit. Among other things, she
insists that she can precisely diagnose a Windows crash by paying
attention to the modem lights and hard drive light and sounds.

If she weren't so consistent I could only conclude she was a troll.
Still, I wouldn't give much credence to anything she says about
computers not manufactured by DEC or manufactured after the mid 1980s.

Charlton


--
Charlton Wilbur
cwilbur@chromatico.net

steve ohara-smith

On Thu, 20 Sep 2007 11:50:53 -0700

That sounds like an excuse - Unix print spoolers never bring the
system grinding to a halt even when using fancy filters like apsfilter to
convert files first to PostScript and then rasterising that PostScript and
spitting it out of an interrupt driven byte by byte centronics port.


So does lpd - take this as an existence proof that the job can be
done better. --
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

stanb45@dial.pipex.com (stan

Exactly. Even this slow old Linux computer will do the above without
noticeably affecting anything the user is doing. You can hear the printer
pause* for a while at times when you're doing something that requires a
lot of resources, but you never have to wait on the printer.

* especially when printing postscript to a 9-pin dot-matrix printer!
--
Cheers,
Stan Barr stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)

The future was never like this!

j de boyne pollard

JdeBP> I also recommend reading Boswell's _Inside Windows 2000
JdeBP> Server_. SPOOLSS is a complex beast. It supports a
JdeBP> variety of printing systems, both local and remote printing,
JdeBP> plug-ins for third party print management mechanisms, and
JdeBP> quite a few options for both spooling and status reporting for
JdeBP> queued and in-progress jobs. The architecture for doing that
JdeBP> is not trivial. Visualizing the operation of the spooler as
just
JdeBP> read-from-file-then-write-to-port is to visualize it highly
incorrectly.

GM> OTOH there is a difference betwen generating the bytes to be
GM> sent to the printer and then actually sending them. It makes
GM> lots of sense to spend considerable cpu-time on the former
GM> but not the latter. It seems to me "spooling" is transmitting
GM> bytes to the printer, not computing them.

Then you are making the very error that I described above. Go and
read the book and gain understanding. SPOOLSS does a lot of things.
It is _not_ as simple as read-byte-from-file-then-write-byte-to-port.

Your hypothesis about bugs in the parallel port driver is surmise that
is based upon this erroneous foundation that you have, and is
fallacious. There's no need for guessing like this. Read the book,
and the Microsoft KnowledgeBase articles, that I pointed to, and
learn. There are _actually do***ented and explained_ reasons for
SPOOLSS to be consuming CPU time that have _nothing whatsoever to do
with parallel ports or kernel-mode code_. MSKB article 216905
do***ents a case where _network print clients keep issuing the same
RPC request to the server over and over again_ causing it do keep
doing the same work over and over again, for example.

j de boyne pollard

SOHS> I really don't understand why Windows should
SOHS> grind to a halt spooling print output, even if it
SOHS> is using the CPU to generate the raster.

JdeBP> Then read Microsoft KnowledgeBase articles
JdeBP> 810908, 175893, 163219, 237597, 216905, 840371,
JdeBP> and 182333 and gain enlightenment. Note that nearly
JdeBP> half of these are problems caused by softwares


SOHS> Unix print spoolers never bring the system grinding to
SOHS> a halt even when using fancy filters like apsfilter to
SOHS> convert files first to PostScript and then rasterising
SOHS> that PostScript and spitting it out of an interrupt
SOHS> driven byte by byte centronics port.

You didn't read the rest of the paragraph, let alone the articles
mentioned. Here is the rest of the paragraph again:
JdeBP> I also recommend reading Boswell's _Inside Windows
JdeBP> 2000 Server_. SPOOLSS is a complex beast. It
JdeBP> supports a variety of printing systems, both local and
JdeBP> remote printing, plug-ins for third party print management
JdeBP> mechanisms, and quite a few options for both spooling
JdeBP> and status reporting for queued and in-progress jobs.
SOHS> So does lpd [...]

No, it doesn't. "lpd" doesn't do even half of the things that SPOOLSS
does. For starters, LPD is but _one_ of _five_ network printing
protocols that SPOOLSS acts as a server for, and the LPD protocol
doesn't provide a mechanism for obtaining the completion status of in-
progress jobs. Then there are things like print routing; deciding
when exactly to convert from EMF to a page description language, based
upon client and server capabilities; and monitoring in-progress jobs.
As I said above, read the book and the articles, and learn what tasks
SPOOLSS actually does. The architecture for doing all that it does is
not trivial. Visualizing its operation as just read-from-file-then-
write-to-port, or even as just read-from-file-pass-through-filter-then-
write-to-port is to visualize it highly incorrectly. It's a multi-
function service for heterogeneous environments with potentially
complex requirements, not a single-protocol limited-function service
for homogeneous environments.

jmfbahciv

A professional does not have to use all hard/software to know
how it works.

Grow up.


Unless physical laws have changed, you also are constrained by them
just as we were when we doing our work.

/BAH

charlton wilbur

BAH> In article <87hclpqdmj.fsf@mithril.chromatico.net>,


BAH> A professional does not have to use all hard/software to know
BAH> how it works.

A professional also refrains from making inaccurate comments about the
operation of hardware and software she has never used, especially when
trivial usage of that hardware and software would improve her accuracy
significantly.

Charlton


--
Charlton Wilbur
cwilbur@chromatico.net

scott@slp53.sl.home (scott

J de Boyne Pollard <j.deboynepollard@tesco.net> writes:

If I may speak for Greg, I think his point was more that SPOOLSS
_shouldn't_ be doing all those things. It should simply stream
bytes to the printer, and track the status of the stream. How
complicated can that be?

Even assuming that all the functionality provided by SPOOLSS is
necessary and required, why does it consume so many resources
to simply print a single file?

Other print spooling systems, just as functional (e.g. CUPS,
Unisys DEPCON etc) don't exhibit the same performance issues,
so perhaps there is something in the implementation of SPOOLSS
that was not implemented as well as it could have been?

fault of the server too. scott