All printers printing slow.

[UniPrintLad]

As seen above many print jobs are taking +30 seconds regularly to print.  Printer acknowledgement time is oddly high in this case but among other printers (we have +50 using universal print, all very slow when compared to operating on local network) the time delay may be more due to upload/download.  The larger file sizes on average take longer as expected but not in all cases, some times very small 1 page print jobs just take a long time despite the printer not doing anything when the job was issued.

[#2]

Hello, I on the other hand think your time from Created to Final are fast or at least what to be expected compared to many of the regular times I have seen.

From what I have seen the total time can increase depending on the bandwidth of the office and the physical distance between the office and the, in our case, connector server.

There will of course be more of a delay when using MS UP compared to using a local network solution since you are introducing several steps, most notably uploading the print job to and downloading it from Azure.

You can check of the full steps used by UP on the below link and then compare it to a local network setup.
https://learn.microsoft.com/en-us/universal-print/fundamentals/universal-print-troubleshooting-print...

[#3]

Thank you for the response and documentation.  While it does grant me insight into the process, my goal is to improve these time metrics as the business which is piloting Universal Print prints thousands of pages a day; many individual user workflows will exceed 100+ individual print jobs per day.  So, going from a 2 second response to a 45 second response for each one is simply not viable to sustain their workflow.  Naturally we can try to reduce the need for such high printing traffic, but the point of Universal Print is...to print, I believe - and the organization is very interested in continuing to print at the same rate for now.

Universal Print is failing to "keep up" with their printing traffic needs, essentially.

The printer management benefits on the other hand are quite useful to the organization so if I am able to improve the print times in any manner then it is still possible to retain their use of Universal Print.

While I know you have implied that we cannot expect any improvement in performance from Microsoft's end on this in the near future, I am hopeful that you can disclose what type of network traffic Universal Print uses so that we may attempt Quality of Service and traffic shaping measures to improve these slow print times.

Any other tactics which you may recommend beyond "don't use the connector" would also be welcome; I only use the connector for models which do not support universal print, however, in my experience the print times are not noticeably different regardless of whether the connector is in use or not.

[#4]

Here is an article published by Microsoft themselves which discusses the topics I linked previously but more in depth.

To be more specific the article goes through each step of the "print job journey" and the impact each step has on the latency of a print job which in turn points you to where you can make improvements to reduce the bottlenecks.

Keep business going with Universal Print - Microsoft Community Hub

[#5]

@AndreasAsander 

I really appreciate your response.

[#6]

@UniPrintLad - you pose interesting questions :). To summarize the articles that Andreas shared, Universal Print has two phases:

1. Service Processing time: Job going from Client to Universal Print service and getting processed in the service - this is usually very quick - within a couple of seconds. This part of journey is reflected with "upload time".
   1. Can you confirm how are you printing? Are you printing from Windows or have your own application that uses Graph APIs? Graph APIs can add some more time. At the end of this stage, Universal Print would have tried to inform the printer (or Connector) about job available for printing.
2. Printer (or Connector), then download the job, print and update status in Universal Print. Timer for the printer/Connector starts from upload time onwards.
   1. Wait time: Even though the job is ready in service, in some cases printer/connector has to wait before it can process the next print job. Difference between acknowledge time and upload time indicates this wait. For e.g., in case of Connector if a printer has many jobs submitted at the same time, then jobs will be processed one-by-one at the printer. If each first job takes 7 seconds, then second job has to wait for 7 seconds. Similarly third job at the same time will have to wait for 7+7=14 seconds and so on. Having said that, concurrency of many jobs on the same printer is very rare - but it does happen!
   2. Printer processing time: Printer starts processing the job at "acknowledge time". Universal Print waits to hear back about job status from the printer. When printer responds saying it Completed the job, Universal Print stores that as the final time. Sometimes final time can be a bit deceptive as printer performs some finishing tasks even after printing the job.

To see the throughput of the Universal Print service, I typically look at difference between acknowledge time and created time. From your screenshot, I do not see much delays there and its usually within 3-5 seconds.

Can you confirm if you are using Connector or are you using Universal Print ready printer? Some printers can take upto 30 seconds to process a job.

P.S. - Thanks @AndreasAsander for taking the lead in responding to these questions.

[#7]

Hello,

We have a Kyocera TASKalfa 2554ci. This shows the same behaviour....

check out the crazy times... it is really random. and when I reboot the printer, the times are normal again....

Office personel is quite annoyed by this behaviour. Hope we can find something. We use Office applications mainly.

[#8]

@dacken - Can you confirm if you are using a Connector for registering printers or the Kyocera printer you mention is a Universal Print ready printer?

[#9]

@dacken - if you are using Kyocera's Universal Print ready printer, have you opened a Support case with them? From your screenshot, I find no reason why printer would take so much time to acknowledge the job. Also, you mentioned that restart of the printer helped - so it seems like the printer was stuck in an unexpected state which got cleared post the reboot.

[#10]

@Saurabh_Bansal Yes confirmed. I used a printer   'unviersal printer ready'

We bought the printer because it says "Universal Print ready" on the box. We have migrated to O365 a few years ago and I literally had the old domain controller being a printer server... so I was glad to got rid of it.

it's either the pritner or the service... the big downfal is I have nothing to troubleshoot it. At least when I had a server I could look at the spool service or whatever... now it's a blackbox.

[#11]

@dacken - This seems like a bug and needs to be investigated. This thread does not have enough information to start an investigation.

I recommend starting with Kyocera. 

[#12]

Hi,

This is Kevin from Kyocera Document Solutions Development America.
We are currently investigating this issue.
We will provide an update regarding this issue after ongoing investigation, and will also provide an update on how to contact the correct communication channel with Kyocera support soon.

Regards,

Kevin

[#13]

Hi Kevin, thanks for taking the time to reply. I eagerly await your response. I did contact Kyocera in the Netherlands and they have registered my question under 12330130. No response yet though.

regards,
Christiaan

[#14 · Accepted solution]

All,

After much back-and-forth between MS and Kyocera I can confirm this painful issue has been solved.... it was indeed a firmware issue on Kyocera side. The printer was not able to communicate with the queue during sleep mode.

Not fixed yet in official firmware but will be soon I hope. I got an onofficial one...

Kr
Christiaan