csrobe@icase.arpa (Charles S. Roberson) (07/11/87)
I help administer a SUN 3 system with 14 workstations running SUN release 3.3 of BSD 4.2 UNIX. We do a quite a bit of document preparation. (Mostly TeX and troff stuff). Anyway we just purchased a second laser writer and are in the process of integrating it into our system. What we would like to do is provide some form of loadsharing mechanism for our two printers. The two printers are identical so we can make them transparent to the applications. What experiences has anyone had with doing this. We have considered a sharing load based on accumulated page counts for both printers and also based on current queue size. The quickest way we can think of is to use a shell around lpr to determine which printer to use. Has anyone tried having one queue serve more than one printer? How were the daemons handled? Thanks in advance. Chip Roberson csrobe@icase.arpa ...seismo!gmu90x!wmcs!csrobe
eirik@tekcrl.TEK.COM (Eirik Fuller) (07/12/87)
In article <8258@brl-adm.ARPA> csrobe@icase.arpa (Charles S. Roberson) writes: > >I help administer a SUN 3 system with 14 workstations running SUN release > ... >What we would like to do is provide some form of loadsharing >mechanism for our two printers. The two printers are identical >so we can make them transparent to the applications. What experiences >has anyone had with doing this. We have considered a sharing load >based on accumulated page counts for both printers and also based >on current queue size. > >The quickest way we can think of is to use a shell around lpr to >determine which printer to use. Has anyone tried having one queue >serve more than one printer? How were the daemons handled? > ... Given that you have Suns, I doubt this will help you, unless Sun does this for you (I'm assuming you have no sources), but it may be interesting anyway. We are in the process of cleaning up a quick hack to lpd that does most of what you describe. The hack was done locally, and the cleanup is still more local, whatever that means. The net result of this cleaned up hack, so to speak, is a line printer daemon that understands a printcap with more than one device in a queue (:lp=/dev/lw0|/dev/lw1:). When handling print requests, the daemon forks one child per device, and each child scans the queue for the oldest job that isn't yet printing. Thus jobs get printed more or less in chronological order; the algorithm is essentially the same one banks use when there is one line feeding multiple tellers. Some day we might add some heuristics whereby the available printer gets only jobs below a certain size, so that long jobs tie up one printer and small ones get through on the other. With two printers going, that has rarely been "necessary" (whatever impatient users take that to mean :-). I suppose I should also mention that mdqs is likely a better way to solve your problem, particularly if you don't have lpd sources. I'll leave it to the net.experts to fill you in on where mdqs can be obtained, since I plead ignorance on this count. The only sources I have found have been modified to the extent that they won't compile under 4BSD any more (don't ask). Good luck.
dpk@sem.ARPA (Doug Kingston <dpk>) (07/26/87)
MDQS (Multi Device Queueing System) handles roundrobin scheduling
of resouces and many other things. The current version of MDQS
is 2.11. It is available for anonymous FTP over the ARPA/MILNET
from host vgr.brl.mil in the subdirectory "arch". It is also available
by sending mail to the following address if you are a U.S. site.
The procedure for foreign sites is far more convoluted. Send mail
for details.
Requests by mail should be addressed as follows:
Advanced Computer Systems Team
MDQS Distributions
Ballistics Research Lab
Attn: AMXBR-SECAD (ACST)
Aberdeen Proving Grounds, MD. 21005
Cheers,
-Doug-
PS. For those that care, I am leaving BRL for New York. dpk@brl.arpa
will work for the forseeable future.