Subject: Re: Extremely slow printing from Mac to Linux/netatlk

From: Marc Miller <[email-masked]>
Date: Sun, 10 Sep 2000 16:38:41 -0700 (PDT)

Or maybe it has to do with the speed of the machine of the network, and of
the printer.  I'm not even using papd; I'm using a beta of PPR (to be
tested soon with the NATALI patches in 1.5) but it seems to me that a HP
LaserJet 5Si attached to a 100BT network and a 800MHz server and G4 MacOS
machines would process the job much faster than a HP LaserJet II on a 10BT
network, a 200MHz server, and a 6300 series Mac workstation.  Especially
if you add one of the -O# optimization flags to papd on the faster server.

It's just an idea; as I said, I don't even plan to use papd.  But it could
explain 30 seconds vs. 5 minutes.  Still, it shouldn't take 5 minutes to
run it through the queue even if you have a 133MHz netatalk server.

On Sun, 10 Sep 2000, Matthew Keller wrote:

> andrew morgan wrote:
> 
> > Yeah, papd is slower than samba, but I don't see anything as slow as you
> > guys are talking about...  A "print desktop" command takes about 30
> > seconds from when you click print to when it starts printing.  Maybe there
> > is something else wrong?
> 
> 	I have several different clients running Netatalk, not to mention
> several of our school's servers - And I can replicated this problem with
> a myriad of versions and configurations. My "IF" script in printcap
> doesn't even SEE the print job for quite a bit after the job is
> "sent"... 
> 
> -- 
> 
>  Matthew Keller
>  WebMaster & Lead Programmer/Analyst
>  Distributed Computing/Telemedia
>  Information Services Division
>  State University of New York at Potsdam
>  
>  Website: http://mattwork.potsdam.edu/
>  PGP: http://mattwork.potsdam.edu/crypto/
>  Webcam:  http://webcam.mattwork.potsdam.edu:85/
> 

============================================================
	/\/\arc ._|. /\/\iller ([email-masked])
	Computer Room Consultant
	Information Technology/Lab Management
============================================================
I can be contacted through the Communication Center link from
http://www.mother.com/~mjmiller/

---

From: Matthew Keller <[email-masked]>
Date: Sun, 10 Sep 2000 19:54:06 -0400

Marc Miller wrote:
> the printer.

I'm running 100mb switched everywhere, ATM backbone, on new G4's (some
G3's) and HP4000's. :) BTW: PPR runs at "normal" speeds, and quite
nicely. 

-- 

 Matthew Keller

---

From: Ron Chmara <[email-masked]>
Date: Sun, 10 Sep 2000 19:33:35 -0700

> G3's) and HP4000's. :) BTW: PPR runs at "normal" speeds, and quite

I didn't say anything when this popped up, I figured it would get sorted
out on it's own (and it has "flamewar" written all over it).

Since it didn't, here's some reasons _why_ there's often a speed difference
between Mac and PC printing, which is *often* unfairly stacked in one direction
or another, usually moreso in a netatalk environment.

1. Native OS printing engines. When a machine seeks out a printer to output
to, it will often use or select a printing engine (i.e., on a Mac,
Postscript or Quickdraw, on a PC, ASCII, HPGL, Postscript). Some engines
are faster than others due to their complexity and capability. This means
that a simple text page is a good measure of the simplist printing engine
available for a given printer "entity" on an OS. The performance of these
engines will also be different depending on the size and complexity of a
print job.

2. Printer queuing settings. On Macs and PCs there are various settings to
tune print drivers for foreground and background printing, print as spooled
or print after spooling is completed, etc. Since most folks don't navigate
all the way through, their settings may be differently optimized for
forground and background printing. So, in a given printer "test", a PC
which puts printing as the highest priority may be put up against a mac
where printing is at an extremely low priority. (Which is pretty close
to the respective OS's defaults).

3. Data formatting. This messes with a lot of people, who assume that
TCP/IP printing is always faster than appletalk printing. In this case,
they're usually dead wrong. TCP/IP printing on the Mac formats data for
7-bit clean data streams, usually making the job bigger, and slower,
than leaving it as appletalk (as re-parsing an entire job may add a
whole lot of time to an output job).

4. TCP/IP vs. Appletalk. First see #3. Then add in the general packet
window sizes of TCP/IP vs. Appletalk, and you come up with a whole set
of odd speed issues. 8-bit clean TCP/IP printing streams from a PC will
always be faster on 100Mb than Appletalk on that 100Mb or even TCP/IP
from a mac.

5. Print driver "features". Macs are big on features, some of which
the PC world has, some of which it doesn't. A Mac taking a simple
text document, running it through a desktop printer stream, remapping
all the data for color matching, formatting the data for a universal
Postscript PC printer driver, and than printing that, is going to be
much slower than a PC spitting ASCII out over a virtual port.

So how do you fix this, in, oh, say, a print-heavy-prepress-workflow
where print jobs _aren't_ single page text notes, but 1.2GB print
jobs? Easy. For the small print jobs from a Mac, print in the
foreground. For massive jobs, print to a postscript file, and then
send it into a hot folder, or use Appletalk/NetBeui streams on a highly
switched, highly zoned, network. I've set up high-data volume
service bureaus, who do 5-10Gb of printing per day, from 10 machines,
with 4 different *physical* network segments, to keep data pipes
available. That's 100Mb switched ports to _every_ desktop. If your
livelihood depends on print speeds, switched 100Mb to the desktop 
isn't a feature, it's a requirement.

To summarize: Macs will always print much slower, *if* the test
is a simple wordpad ACSII file vs. A PostScripted teach-text file.

To truly compare speeds, you'd need to use a variety of documents,
using printers which were *designed* for their respective
environments, rather than ones that had appletalk or NetBeui or HPGL
tacked on to a "native" print mode, and you'd have to use whatever
applications are used most frequently in the environment (did the
test compare a Corel doc vs. a Teachtext doc? No? Why not? :-) )

I've seen PC's print 5-10 times slower than Macs on the basis of
8-bit vs. 7-bit data on Appletalk.... but that's not an issue
of raw print capability, that's an issue of a stacked test. If your
numbers are closer to PC's being 120-130% faster (that's 10 seconds
vs 12-13 seconds), that's when you are seeing the age of Apple's
print architecture. Much more than that, and it's a stacked test,
where you need to take a closer look at why you're getting those
numbers.

-Bop

--
Brought to you from iBop the iMac, a MacOS, Win95, Win98, LinuxPPC machine,
which is currently in MacOS land.  Your bopping may vary.

---

From: Sak Wathanasin <[email-masked]>
Date: Mon, 11 Sep 2000 10:09:56 +0100

In reply to Ron Chmara's message of the 10/09/2000 at 19:33 -0700,

>8-bit vs. 7-bit data on Appletalk.... but that's not an issue

I don't know what you're doing but simple back-of-the-envelope 
calculations will tell you that the difference between 7 & 8 bits is 
at most 100% (each byte is sent in ascii as a pair of hex digits 
which doubles its size). 5-10 times difference is way off beam, so 
something else is involved.

papd is slow is because it is layered on ATP which is slow. Most 
people don't notice because most of the time is spent in the RIP (and 
PS RIPs are at their worst with v large pixmaps). Like the difference 
between using a fileserver over AppleTalk vis ASIP. If you're 
spooling, however, you'd really notice the difference.

It's been several years since I worked in this area (OPI servers), 
but is there some reason why you can't send 8-bit data over TCP/IP 
using the lpr protocol?

-- 
Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [email-masked]
Phone: (+44) 24 76 41 99 96        Mobile: (+44) 79 70 75 19 12 
Fax: (+44) 24 76 69 06 90

---

From: Matthew Keller <[email-masked]>
Date: Mon, 11 Sep 2000 08:46:22 -0400

> is a simple wordpad ACSII file vs. A PostScripted teach-text file.

	My qualm isn't with the speed Mac's print - I can get the same Mac to
print faster to a PPR print server, or to the printer native or even to
the printer that is caputured by an NT box (*shudder*) - PAPD seems to
be introducing gobs of latency. I'm not getting into any Windows vs. Mac
warz here- Just stating that PAPD's performance is inconsistant with
other packages.
	BTW: did some packet watching last night- The packets are getting to
the Printer server running PAPD in normal speeds, but the delay between
when PAPD gets all of the packets and when the printing subsystem SEE'S
the job is enormous.

-- 

 Matthew Keller

---

From: Stephen Lubbs <[email-masked]>
Date: Tue, 12 Sep 2000 18:05:38 -0400

Hi Marc,
You've piqued my interest. What is PPR and where can I find it?

Regards,
Steve

--
//
// Stephen Lubbs
// [email-masked]
// "An Equal Opportunity Developer"
// "Supporting Java, CTOS, Linux, Unix, Mac OS, NT, and OS/2"
//

---

From: "Marc J. Miller" <[email-masked]>
Date: Tue, 12 Sep 2000 18:31:26 -0700

The PPR home page is here:  http://ppr.trincoll.edu/

Though I haven't been able to get a hold of a printer for my test server
yet, I'm told that it's much faster than papd.  You will also need the
NATALI library from the same location
(http://ppr-dist.triscoll.edu/pub/ppr/).

A word about the 2.1.4+asun and developer 1.5 netatalk releases:

The author has been made aware of the problems with using PPR with netatalk
1.5, and he suggested I make a couple of changes to the netatalk code
(changing a static int to an int, and a couple of other equally minor
adjustments) which I did.  If you can't get the latest stable release to
work with PPR, try the test release, and if that doesn't work either, try
the PPR mailing list and either the author or one of the other capable
people on the list should be able to help you out.  :)  If you want to know
how I got it to work (assuming it tests okay when I get a printer), just
e-mail me.