Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cups-polld introduces unnecessary delays in first round of polling #3574

Closed
michaelrsweet opened this issue May 1, 2010 · 5 comments
Closed
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

michaelrsweet commented May 1, 2010

Version: 1.4-current
CUPS.org User: ebroder

When cups-polld polls a remote server for printers, it avoids sending all of the discovered printers to the local cupsd at once, supposedly to avoid overwhelming the local server.

To do this, it will only send "(number_of_remote_queues / value_of_BrowseInterval) + 1" queues per second.

However, if BrowseInterval is sufficiently large and the CUPS server has just been started, this causes a long delay while polld slowly feeds all of the queues to the cupsd.

In our environment, we set BrowseInterval to 600 to avoid unnecessary load on our central print server. However, this means that the first tiem we start CUPS, our workstations only discover 1 printer per second.

I haven't seen any obvious issues that look like the local cupsd gets overloaded if I set BrowseInterval to 1. What exactly is the concern with overloading the server? Could the code to throttle requests be dropped these days?

Alternatively, could cups-polld be modified to not throttle discovered queues the first time it runs?

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented May 2, 2010

CUPS.org User: mike

Ok, so the issue is that cups-polld uses the CUPS browse protocol to relay remote queues to the local cupsd. Since that is UDP, it is possible to lose printers if cupsd doesn't process the packets fast enough.

That said, we certainly can enforce a higher minimum number of printers per second. 10 or 20 shouldn't be a problem.

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented Oct 2, 2010

CUPS.org User: jp107

Looking at the code I'm puzzled.

The code in cups-polld.c says:

max_count = max_count / interval + 1;

while a similar piece of code in dirsvc.c which I think does the sending of broadcast adverts does:

/*
* Throttle the number of printers we'll be updating this time
* around based on the number of queues that need updating and
* the maximum number of queues to update each second...
*/

max_count = 2 * cupsArrayCount(Printers) / BrowseInterval + 1;

so it seems at first glance that cupsd is happy to send broadcasts at twice the rate that cups-polld will send them to the local cupsd, and as BrowseInterval goes up the rate of adverts per second goes down by it's square (since there are fewer adverts sent each time and spaced further apart).

Also the rate goes up for servers with more printers.

Am I completely misunderstanding what the code does?

Would it not make sense to just have a fixed number of adverts it will send in each interval? Perhaps a user configrable option (say) BrowseAdvertsPerInterval or similar?

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented Oct 2, 2010

CUPS.org User: jp107

See also #3685 which is not directly related but...

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented Jan 11, 2011

CUPS.org User: mike

Fixed in Subversion repository.

@michaelrsweet
Copy link
Collaborator Author

michaelrsweet commented Jan 11, 2011

"str3574.patch":

Index: scheduler/cups-polld.c

--- scheduler/cups-polld.c (revision 9461)
+++ scheduler/cups-polld.c (working copy)
@@ -310,7 +310,7 @@
fprintf(stderr, "DEBUG: %s Found %d printers.\n", prefix, max_count);

 count     = 0;
  • max_count = max_count / interval + 1;
  • max_count = 2 * max_count / interval + 1;

/*

  • Loop through the printers or classes returned in the list...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant