Linux as an OPI Server for the Graphic Arts Industry

A printing company finds that Linux servers speed up their pre-press work.

by Jeff Wall

Recent testing of high-performance file-sharing tools for the Graphic Arts industry has shown Linux to be the top performer. We tested Linux against the Macintosh OS X Server, the Sun Solaris and the Windows NT server. Linux came out on top, yielding a blazing average of 8800KB/sec throughput over 100Base-T Ethernet. We have been using an NT server in this role for two years, but it has been stumbling under the load placed on it in the last year. Now, we restart the server each day in order to avoid hanging the print services.

As a full-service commercial printing company, Mahaffeys' Quality Printing is one of more than 30 percent of the 44,000 U.S. printing firms which use or could use an OPI (open pre-press interface) server to generate and spool high-resolution PostScript output files to RIPs (Raster Image Processors). The OPI server, a vertical market application, could be described as an industrial-strength file and print server specific to the graphic arts industry. It costs from $5,000 to $25,000 or more to obtain one for use in a very large printing plant with up to 100 pre-press client workstations.

Using an OPI server allows a client station to offload the processor and I/O-intensive work of creating a high-resolution PostScript file. The OPI server creates and then forwards the PostScript file to the RIP. RIPs are powerful workstations that convert huge PostScript files into ultra-high-resolution laser recorder instruction sets. These files are imaged to film or plate and ultimately used on offset printing presses.

The need for an OPI server begins at the creative client machine. This is usually a Macintosh, since most content creation in the printing and publishing industry is done on Macintosh workstations. Most modern printing or publishing pre-press departments are multi-platform client/server-based, with a UNIX or Windows NT departmental workgroup server that serves Macintosh and Windows client workstations image files and pages as needed. It also consists of numerous PostScript output devices ranging from black-and-white laser printers, large format color proofers and laser film-to-plate imagesetters. The most modern plants opt to skip the film step and image directly to plate using very powerful thermal laser-imaging systems.

The most common network protocol is switched 100Base-T Ethernet, but some 10Base-T nodes still exist and gigabit Ethernet and fibre-based network protocols are becoming increasingly common as the file size and throughput requirements continue to grow unabated. The network server is vital for its ability to allow multiple operators to access portions of a project (known as a job) at the same time. Also, this server-based workflow allows for the job to be easily passed on to the next worker or team without requiring a huge amount of information to be copied to another location as it passes through the stages of typesetting, image scanning and retouching, design, proofing, imposition and finally PostScript output generation, ripping and imaging.

Figure 1. The Imposition and Output department. From left, Jimmy Carman, Jason Clifton and Doug Wilson flight check, impose and output to plate all sheetfed print work at Mahaffeys'. The tan machines with monitors atop at the left and right of the photo are Presstek thermal computer-to-plate imagers.

A recent 32-page color product catalog at Mahaffeys' exceeded 4GB of files when completed. It spent more than ten days on the server while being worked to completion. We average more than 800 print jobs per month, on a group of 17 offset and flexographic printing presses. Not all jobs are this large, but the need for a great deal of server space is a foregone conclusion in this business. It would be one thing if a fast, stable and scalable file server that could serve Macintosh and PC clients were all that was needed. However, these same machines are required to spool print jobs to the host of output devices that exist in the pre-press department.

The PostScript files they spool are typically imposed, multi-page, full-color printing forms and average 250 to 500MB each for a 32-page catalog consisting of eight 4-page forms. It is not unheard of for a single PostScript file to exceed 1GB in size. As you might imagine, a busy department with 10 or more employees working on and printing massive files to the server can choke a network in no time at all. The result might be slow print and serving times for all users, or a server crash--both cause expensive delays.

Several years ago, before the existence of the Windows NT server, the only choices for these machines were proprietary RISC UNIX servers such as Sun and SGI (Silicon Graphics, Inc.) or an AppleShare server from Apple. There was no middle ground. The high end was the high-priced domain of the big printing plants costing $75,000 and up, and the low end was low-powered and cost $15,000 or less for small companies with only a few employees.

The Windows NT server broke into the pre-press arena around 1995/1996 with version 3.x and SFM-Services for Macintosh. This is a Microsoft implementation of AppleTalk file and print services and is much slower than the AppleShare/IP protocol common in UNIX and Linux implementations. Intel processors of that era were ill-equipped to handle the extreme duress brought to bear in this big-file and high-system-I/O environment, but the Alpha 21064 and later the 21164 chips from Digital Equipment Corporation proved equal to the task. These systems began to proliferate in the graphic arts industry.

The NT Alphas were not as scalable or stable as the UNIX machines, but they cost less, occupying the $20,000 to $50,000 middle ground. They were assumed to be easier to administer as well. Whether this was true is a subject worthy of debate.

Figure 2. The operator console of the five color Heidelberg MOF offset press shows a process color newsletter being produced for furniture manufacturer Lane. This two-sided 17x22 product exceeded 500MB in size.

In an OPI workflow, the imposition station (imposition is another vertical-market application that takes single pages and assembles them into press-ready flats) forwards a thin version of PostScript, one devoid of all high-resolution graphics, to the OPI server where the PostScript comments, instructions for placing high-resolution data, will be handled by the OPI application. The OPI leaders in the UNIX space are EtherShare OPI from Helios, a German firm with a long list of OEMs as customers, and FullPress from Xinet of Berkeley, California. The NT platform has several players with the largest and best-known being Color Central from Luminous.

We installed an NT Alpha 533MHz server with 256MB RAM and 60GB UW SCSI RAID in mid-1997, opting for Color Central for OPI serving. We also installed 3Com 10-100 switches and benchmarked our PowerMac clients at 2.3 to 2.6MB/sec file reads from the new server. This was almost triple the 900KB/sec we got over thin Ethernet to our AppleShare 4.2 server before the upgrade. We were pleased with the improvement. Around the same time, we began to experiment with Red Hat Linux version 4.0. The idea was to use Linux to determine if a UNIX system would be something we could administer ourselves. After struggling a bit with early installs on Alpha hardware, learning and working with Linux began to get easier and each new release seemed to make big gains in hardware support and usability. We implemented the first Linux server on our work LAN in late 1997 and used it for FTP and web serving at first. Later, we added DNS and proxy-server duty. We installed Netatalk and Samba and configured the little homemade $600 Pentium 166MHz 64MB machine to serve files to the Macintosh clients and talk to the NT server.

It was a good network citizen, and served files to and from our T1 Internet connection. We considered it a toy compared to the much more powerful Alpha hardware and PowerPC Mac workstations, but it was very stable and easily did its job. One day, while copying a large customer file that had been transferred via FTP, I observed an unusually short copy time. The file was around 25MB and it copied incredibly quickly to my workstation via the Macintosh finder. I copied it again and observed 7.5MB/sec throughput. I did this on two other machines and they all showed comparable speeds. It was unbelievable. This little toy that didn't even have SCSI drives was delivering three times the file transfer speed of $20,000 worth of Alpha Iron with Ultra-Wide Barracuda RAID.

The secret, of course, was Adrian Sun's AppleShare/IP Netatalk patches. That very day, I began questioning why Linux wasn't used in the network server role in pre-press operations. One reason was low industry awareness, but the biggest single obstacle was lack of an OPI package. We are past the volume at which we can operate efficiently without OPI services. This lack of support was a show stopper. I began polling industry newsgroups and mailing lists more than a year ago, and noticed a dismally low number of folks in the trade had any awareness or interest in Linux. I found a couple of people using it for Internet duty and several more for simple file sharing, but not one was using it as a primary network server in a high-volume printing plant.

I began to lobby the folks who I thought were best positioned to port to Linux, namely the UNIX OPI vendors Helios and Xinet. At first, they ignored my public pleas for a Linux version. Then I actually sparred on-line with an Xinet representative about whether or not Linux was a viable solution in this role. A representative for AGFA, a European industry heavyweight, claimed to have worldwide market research showing that their customers wanted only NT for servers and RIPs. The only country with a high interest in UNIX products was Germany. He stated that Linux wasn't even on their radar screens during the last survey. The entire industry was dismissive about Linux in the graphic arts at that time, despite the growing interest and market-share numbers I was reading. Linux was starting to look good to many people, and I knew with a little nudge it could display its ability to vastly outperform NT servers in stability and file sharing speed at a fraction of the price.

Figure 3. The Heidelberg Quickmaster DI is the most automated printing press in the world. It runs four-color process and mounts, images and cleans its own waterless offset plates while it presets ink keys for the operator.

We installed two more Linux machines, both SMP Pentium Pro 200MHz with UW SCSI, and set about using Linux in a meaningful role in pre-press. We were able to share files, but when it came to printing, we had to defer to the NT machine because of the OPI support. We were successful in setting up a ``back door'' OPI workflow where we used the Linux machine to serve files, but OPI spooled to the Alpha. Color Central made file calls to the Linux server and forwarded the PostScript files to the RIPs. This gave us the benefit of faster file access on the Macintosh clients, but the penalty was much higher network traffic. This was more of an experiment to see if we could do it than a real solution. The only way to make this work without beating up the network would be to set up a private Ethernet channel between the two servers, but I had no open slots on the Alpha and would be robbing a chunk of the aggregate I/O on this server as well--not a good solution.

The first positive sign that someone was listening came when I was contacted off-line by Tom Hallinan of European MikroGraf Corporation (http://www.ugraf.com/), the North American distributor for Helios. He said he was gauging industry interest in a Linux port on behalf of Helios. I went on at length about how great it would be, but didn't get any kind of commitment. One good thing I learned was that Helios was about as steeped in UNIX experience as you could get--running on a stunning nine UNIX platforms. I was told the main issue was not the technical end, as their engineering staff had more than a couple of Linux fans on it, but whether the product had a commercial market on Linux.

Over the next several months, I didn't miss an opportunity to request Linux versions of printing industry applications. As the computer trade press started giving more coverage to Linux and eventually the mainstream press, I received an increasing number of requests from interested end users. I had also drawn the ire of several industry vendors who had thrown their weight behind Windows NT or seemed blindly tied to other platforms like AIX. One marketing representative from a very significant industry player, when discussing Linux growth in popularity, stated: ``That's all we need--another platform to support.'' I won't be doing any business with them until they change that attitude. This is the split I see as a Linux advocate in the graphic arts. I am getting an enormous number of requests for information from end users and industry associations--almost all positive. I am considered a pariah by the vendors who haven't figured out Linux' potential or seen its growth curve. For at least a year, I have been telling folks in my industry that this is big.

I attended the Seybold Publishing trade show in Boston this past March and directly lobbied Helios and Xinet representatives for Linux support. Helios was tight-lipped; Xinet was dismissive. I was rather disappointed, but ventured over to the Adobe booth and started asking about a port of Acrobat Distiller, another tool we could use on Linux. I was directed to a technical marketing representative who said he used Linux at home. He had asked the developers for that very application himself, because he used it constantly and had to go to Macintosh or Windows machines when he needed it. I recounted my talks with the UNIX vendors, and he said, ``an employee of Helios told me they already had it running in the lab.'' Wow, what a gem. This is the kind of stuff one developer might tell another, but not share with any end users. I left convinced that Helios would deliver the goods.

Two weeks later, they announced the port of their entire suite of high-end printing tools--the whole package. I actually found out from a Slashdot posting. I doubt that this was a big deal to the average user, but it was big to me. The last major obstacle to deploying Linux as a network OPI server had been removed. I contacted Helios and talked to Jim Davison who answered several questions, including the prices of the software I would need. He also pledged to give me access to their FTP server (Linux-based) when they got the Helios binaries, if I would like to test the software before the new CDs were pressed.

Figure 4. The Network Server and SeeColor Proofing RIP at Mahaffeys' are shown here. A digital workflow requires an accurate digital proof. An Imation Rainbow Proofer at left has been nearly idled by the SeeColor-driven HP2000CP at the left. Linux could idle the NT Departmental Server in the near future.

This happened about a week later. They sent us temporary keys for 30 days of use and I downloaded the gzipped binaries from their server. I intended to test the performance of Helios Ethershare AppleShare/IP file sharing, and stated so on a computer-to-plate mail list. Xinet, not wanting to be left out, and several end users encouraged me to expand the testing beyond just EtherShare on Linux.

We decided to test Apple's new OS X Server, a BSD UNIX-based server product, since we could do a head-to-head comparison of Xinet and Helios on that platform. We had just received a copy and had two blue and white G3 Macintoshes that were able to run the server OS. I was also encouraged to add x86 Solaris to the test, since we would be doing the server test on an SMP P-II 333MHz IBM Intellistation M Pro. We had to throw the NT Server into the mix, as it represented what we were using and would show what kind of improvement in throughput we might expect.

I was contacted by a representative from Intergraph Computer in Huntsville, Alabama, who said they had a product about to go into beta testing that would allow Windows NT to perform AppleShare/IP serving. I told him I was interested and later signed a non-disclosure agreement before receiving the software for testing. The stage was set.

The decision to perform these tests off the pre-press LAN was based on the sheer number of operating systems and network services to install, and the fact that it was likely to disrupt work if done there. We decided to run the tests on a smaller test LAN with no PostScript printers. Since our test machines do not have the Ultra-Wide SCSI RAID that would be found in any normal pre-press installation, we decided the first round of tests would be limited to file sharing throughput speeds.

We attempted to keep the variables limited just to OS and AppleShare/IP stack, but the Mac OS X server runs only on Apple G3 hardware so those tests were run on a G3 300. We ran all the x86-based software tests on the same IBM hardware.

The primary test box running NT server, Solaris 7 and Linux is a dual P-II 333 IBM Intellistation M Pro with 192MB RAM and a 6GB Ultra ATA drive. The machine has UW SCSI on board, but this was not used in any of the testing. In the case of the Macintosh OS X server, the machine was a G3 300 with 192MB RAM and a 6GB Ultra ATA drive.

The Macintosh client used was a G3 350 with 128MB RAM and a 6GB Ultra ATA drive. The onboard 100Base-T was used on the Macintosh client and a 3Com 3C905TX was used on the IBM box. The network is running on a generic 8-port 100Base-T unswitched hub.

The test application was Helios LanTest 2.01. This is a test suite that runs the server through a grueling series of activities designed to simulate vigorous Macintosh client use. The test settings far exceed normal client activity for any user short of a maniac. LanTest first creates 100 20KB files, then opens and closes 100 files, removes 100 files, writes 3000KB to file, reads 3000KB from file, locks and unlocks the file 4000 times, reads a directory of 320 files and finally prints a 3000KB file. The default test settings of 3000KB reads and writes with printing disabled were used. This is a small file size for graphic arts, but was used so that the servers could cache the reads and writes if they were capable. Thus, disk hit delays would not be brought into the picture, since the drives in all the test machines are inferior to UW SCSI RAIDs that would be used in a real network server install.

Figure 5. This Rack houses three computers. Two are Harlequin RIP that drive the Presstek platesetters and Quickmaster DI. The third is an SMP Intel machine running SuSE Linux 6.1 that houses Quality's web site (http://www.qualityprinting.com/), e-mail, FTP, DNS and proxy server for the company LAN. The network switches, T1 and DSL routers are seen behind the monitor. Pre-Press Manager Jason Clifton is shown at right.

The goal was simply to hammer the network cards and wire and see how the OS handled the hammering and how fast. What I found fascinating was how widely the results varied on the exact same hardware when the only things changed were the OS and Appleshare stack.

When I reveal that SuSE Linux 6.0 with kernel 2.2.5 and Helios EtherShare was the top performer, I hope the readers of this article will realize the significance of this announcement. Eric Morris, one of the network engineers in my Linux Users Group (http://www.lugoj.org/), and I expected Solaris 7 to beat Linux--but it did not.

I was surprised at how much the test taxed the processors on Solaris/Xinet. It appeared to me that the reads and writes were not fully cached; the result was very inconsistent test data. The numbers were quite different each time I ran them, covering the range from 4000KB/sec to 8700KB/sec for reads. The test suite runs ten times consecutively, then shows an average. The number I am representing is this average. I actually got spikes of 9000KB/sec or better on all the UNIX flavors, but none was able to average that throughput over all ten iterations of the test.

When I reveal that Windows NT Server 4.0 SP4 native SFM was the slowest performer, surely no one is surprised. NT, like Linux, cached the reads and writes and took the load in stride. The processors never broke a sweat and no significant disk activity was observed. A single client, no matter how vigorous the activity level, was light work for these operating systems.

The same hardware/software was tested with Intergraph's ExtremeZ-IP, but as I stated earlier, I have signed an NDA and therefore cannot publish the results.

Test Numbers

Ironically, things have become even more interesting since I posted these results to three mailing lists. I have gotten all kinds of positive feedback from end users. Two people from Xinet contacted me regarding the original poor test results on the OS X Server. It seems this resulted from the Xinet test running in AppleTalk mode with IP support disabled. I agreed to rerun the test, and the numbers above reflect the new test.

An Apple engineer e-mailed to ask why I had chosen not to run the tests with their faster G3 400MHz server model. Because we didn't have one to run the tests on, I replied. He arranged to fix that with a loaner we can use for three weeks.

I have been contacted by another vendor about testing their hardware with Linux, but was asked not to name them. Access to this true server hardware should enable us to step up the next round of testing to the work LAN and include real-world benchmarks such as multi-client testing and OPI PostScript file creation.

At this point in our testing, Linux is ``King of the LAN'' and is looking like an excellent choice for file and print servers in a graphic arts firm.

Jeff Wall is Production Manager of Mahaffeys' Quality Printing in Jackson, MS. He helped found the Linux Users Group of Jackson ``because they didn't have one''. Happily married, he has a yellow Labrador dog and entirely too many computers. He'll discuss his Linux performance testing at the drop of a hat at jefferson1@speedy.linuxman.net.