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

IPP backend performance issue #2548

Closed
michaelrsweet opened this issue Oct 5, 2007 · 2 comments
Closed

IPP backend performance issue #2548

michaelrsweet opened this issue Oct 5, 2007 · 2 comments
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

Version: 1.3-current
CUPS.org User: krumboeck

Between each queued job there exists a 10 second pause when ipp is used. Especially for very fast printers (label printers, etc.) this is a real problem.

In our environment we sometimes queue about 300 jobs at once. The time between the labels shouldn't be larger than 2 seconds.

The problem is caused by the 10-second polling loop in the ipp backend.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Fixed in Subversion repository.

The new code checks at varying intervals of 1 to 10 seconds, starting at 1 second.

@michaelrsweet
Copy link
Collaborator Author

"str2548.patch":

Index: ipp.c

--- ipp.c (revision 7008)
+++ ipp.c (working copy)
@@ -1055,7 +1055,7 @@

 _cupsLangPuts(stderr, _("INFO: Waiting for job to complete...\n"));
  • for (; !job_cancelled;)

  • for (delay = 1; !job_cancelled;)
    {
    /*

  • Build an IPP_GET_JOB_ATTRIBUTES request...
    @@ -1146,10 +1146,14 @@
    check_printer_state(http, uri, resource, argv[2], version, job_id);

    /*

  •  \* Wait 10 seconds before polling again...
    
  •  * Wait 1-10 seconds before polling again...
    

    */

  •  sleep(10);
    
  •  sleep(delay);
    
  •  delay ++;
    
  •  if (delay > 10)
    
  •    delay = 1;
    

    }
    }

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