Migration to Broadcast only

[Michael Sweet]

angelb at bugarin.us wrote:
> ...
> I noticed there are several users who posted the same issue with
> cupsd taking too much CPU when update/polling occurs. Is this issue
> addressed in 1.2?

CUPS 1.2 is certainly more efficient with large numbers of printers,
and in particular with large numbers of implicit classes.

> Some drawbacks in Broadcasting per my observations: a. When a
> broadcast update(sends out entire printers list) occurs some clients
> may or may not get all updates. For example, when a client is
> restarted the same time as the server, the client will most likely
> get all updates the first time. And if another client starts later,
> it will not receive all updates from that cycle and will wait for the
> next update for the rest of the printer queues.

This is true, which is why we recommend having a BrowseTimeout value
 > 2 times the interval.

That said, cupsd will not flood the network with browse packets, it
throttles them to N per second to limit the load on the network and
clients.  If you have 1200 printers with an interval of 30 seconds,
you'll see, on average, 40 packets per second.  Set the interval to
300 seconds and you'll drop the average to 4 packets/sec.

> b. The servers Broadcast function follow the same rule as the
> client's polling function. That is, it uses Broadcast interval to
> send out updates to the network. Setting the interval to a low
> setting, say very five minutes, will have an effect on CPU use on the
> client. Setting it to a higher setting, say every 60 minutes, will
> mean that changes will not be available to the clients until the
> update starts again.

Correct, however in CUPS 1.2 we actually save the remote printers
between runs.  A user that reboots their system will immediately have
the full list of printers available (no waiting after the initial
discovery)

> c. If you restart a client and the servers are not currently sending
> out updates or broadcasting, the client may end up not having any
> printer queues. And if the client is restarted while an update is
> occuring, it will only have the printer queues it sees on the network
> during the servers broadcast.

See above.

> We are now back in polling mode. Going back to polling means our
> clients will poll the servers only at night when there's little
> printing activity, but there are always print jobs from scheduled
> processes. Additionaly, any changes made in the servers for printer
> queues or even adding a new printer queue will not become available
> to the clients until the clients poll at night. This is also not
> desirable since when we make a change, we want the change to be
> available to the clients immediately, but this won't be possible
> because our BrowseInterval is set such that it will try to do it at
> night.
> 
> Is there a way to tell the cupsd to do polling at certain time, say
> at 11:00pm, instead of using interval; ie, every 4 hours, etc?

No, not directly anyways.  You could run cups-polld from a cron job,
however.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com