Mike Chaney's Tech Corner
November 15, 2024, 07:50:16 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Qimage registration expired? New lifetime licenses are only $59.99!
 
   Home   Help Login Register  
Pages: [1] 2
  Print  
Author Topic: Slow print processing  (Read 21590 times)
TerryZ
Newbie
*
Posts: 10


« on: November 04, 2014, 06:47:01 PM »

Hi Folks,
For some reason qimage doesn't seem to be able to use my workstation's power - jobs are taking a very long time to process, but the system doesn't seem to be taxing itself at all. Qimage behaves as if it's using the full system resources (pausing/locking frequently while it's working), but the system itself seems to be barely lifting a finger...

 i7 4770k processor, 32GB Ram, system on SSD, working files on a traditional HDD, Windows 8.1, CPU sits between 5 and 10% while processing, RAM use is minimal, HDD transfer rates are a fraction of capacity.

In Qimage multi-core processing is enabled, changing sharpening to vector certainly speeds it up but still slow and does not increase resource use. Happens on both my canon and epson printers, from all tested file formats. Recently upgraded from a few months old version to the latest with no change

I can't seem to find the bottleneck - any ideas?

Terry
Logged
Terry-M
The Honourable Metric Mann
Forum Superhero
*****
Posts: 3251



WWW
« Reply #1 on: November 05, 2014, 07:50:43 AM »

Quote
jobs are taking a very long time to process,
We need some more information regarding the number and size of prints in the queue and the time it's taking for QU to complete the processing.
Look at the print queue tab and tell us how many MB are reported, see attached screen shot.
Note there are various stages in the processing that are reported in the progress bar at the bottom right of the screen: Loading, Processing, Print driver finalizing page and Finished processing.
Is there a particular stage that is taking the time? QU will have finished it's work when "Print driver finalizing page" appears.

Terry
Logged
Fred A
Forum Superhero
*****
Posts: 5644



WWW Email
« Reply #2 on: November 05, 2014, 10:14:52 AM »

Quote
Note there are various stages in the processing that are reported in the progress bar at the bottom right of the screen: Loading, Processing, Print driver finalizing page and Finished processing.

Hi Terry,
I see that Terry answered Terry.
I should give you numbers too.

Terry asked for excellent necessary information that can affect speed.
A little more info would help too.
Size of the typical file in the queue (waiting to print in pixels)  (example: 4000 x 3000)
See attached screen snap, and note some settings that might affect your printing.

In the Print spooler column, the DELAY is turned off?  


Again back to the print spooler column, if your prints are not too large, you can use EMF instead of RAW. Try it.

How many images in the queue? Is the setting in the Interpolation column set to Spool all at once?
Are there duplicates in the queue?
Are your printers networked?

Ok, that's all I can think of at the moment
Fred
« Last Edit: November 05, 2014, 07:08:21 PM by Fred A » Logged
TerryZ
Newbie
*
Posts: 10


« Reply #3 on: November 05, 2014, 05:26:09 PM »

Thanks for the responses! Here is a bunch more info and some screenshots:

This is a "light" duty typical example with JPEGS only
This took exactly 5 minutes to process.
44x47in page size, 3 individual images
3000-6000pixels on the long side
The vast majority of that time shows as "processing" image... other states flash through in seconds.
Load times were fast - a few seconds per image.
Attached system resource charts are identical from job to job regardless of format/settings/page size - only time needed changes
Qimage RAM use peaked briefly at 180mb but averaged much lower
EMF vs RAW had no impact on processing times - both 5min
Increasing resolution from 300 to 600 to match driver setting quadruples processing times
Files are local & though the printers are networked this example was done offline (transfer speeds to printers are not an issue)
I rarely do multi-page layouts and use a 5 sec time delay for multiples. 

Smiley
Terry
Logged
TerryZ
Newbie
*
Posts: 10


« Reply #4 on: November 05, 2014, 05:32:25 PM »

This performance chart may be more relevant:
Logged
admin
Administrator
Forum Superhero
*****
Posts: 4218



Email
« Reply #5 on: November 05, 2014, 07:21:14 PM »

Bring up Task Manager and right click on the Qimage.exe and select "Set Affinity...".  See if only one CPU is checked.  I'm guessing something happened and maybe only one CPU is checked which would mean Windows will only allow Qimage to use a single CPU.  If that's the case, you should be able to fix it by allowing all CPU's for the Qimage process.

Regards,
Mike
Logged
TerryZ
Newbie
*
Posts: 10


« Reply #6 on: November 05, 2014, 08:06:53 PM »

No Joy - all cores checked already...
Logged
Fred A
Forum Superhero
*****
Posts: 5644



WWW Email
« Reply #7 on: November 07, 2014, 11:36:20 AM »

Terry Z,
Welcome again!

How about one more quick test.

Click the Help drop down menu in Qimage, HOLD DOWN THE SHIFT KEY, and click Analyze Current settings.
Please report on the numbers you see.

I have an old Q8200 processor 2.33 speed, and timing one 6000 pix wide 47 x 44 print is 3:01 second from click Print to the pop open of the Print Preview

Fred
« Last Edit: November 07, 2014, 01:04:27 PM by Fred A » Logged
admin
Administrator
Forum Superhero
*****
Posts: 4218



Email
« Reply #8 on: November 07, 2014, 12:56:35 PM »

No Joy - all cores checked already...

It still looks like something (potentially the OS) is not allowing processes to use more than 1 core.  Type "msconfig" in the Windows search bar on the start menu and in MSConfig, click the "Boot" tab, go to "Advanced" and make sure the box for "Number of processors" is unchecked.

If that doesn't fix it, check BIOS settings at start-up and look at the multi-core options.

There are lots of hits on Google for "i7 only using 1 core".

Mike
Logged
Terry-M
The Honourable Metric Mann
Forum Superhero
*****
Posts: 3251



WWW
« Reply #9 on: November 07, 2014, 04:43:05 PM »

Hi Terry Z
Please clarify something about the print sizes you mentioned: -
Did you mean 3 prints on one page of 44"x47" or 3 44x 47 prints on 3 pages?
It makes a difference of course. Let us know please so some of can do comparative tests.

Also, when you say "slow" what are you comparing with?

When you say the printer was "off line" how was the PC it connected to the printer, USB?

One thing different about QU printing is that it does not merely dump the image data onto the driver but interpolates, on the fly, to the optimum resolution of the printer determined from the driver. This is 720ppi for Epson printers and 600 for Canon and HP. This is the secret of QU's high quality printing because it uses an advanced algorithm to do this. Very large prints may not need the maximum resolution so half values (360 or 300) can be selected to speed up the process.
The other thing that QU does with data sent to the printer batches to avoid traffic jams.
In the past I have done various tests to check what affects print processing speed. They are, print size in inches (or mm); print resolution (720ppi/360ppi) and processor GHz and cores.
I have a 3.6GHz i7 processor with 6GB of RAM. The 4 cores typically work at 40% to 50% and the RAM at about 30%.

We look forward to hearing from you again soon  Wink
Terry (the other one)
Logged
TerryZ
Newbie
*
Posts: 10


« Reply #10 on: November 07, 2014, 07:39:03 PM »

Whew getting tricky eh! Thanks everyone for keeping at it Smiley

Updated bios, checked settings, and verified all cores are working correctly for other apps (hit 100% in prime95, 60% in BF4). Qimage doesn't seem to be using even 1 core fully - 5-10% usage typical, so even a full 25% that a full core would utilize would be a big boost. I'm wondering if its a RAM issue? TerryM is qimage actually using 30% or your RAM? The 50MB average I'm seeing seems really low...

Qimage analyze current settings found nothing.

These 3 tests all run with identical settings to the initial tests @ 300dpi except the final vector test for comparison with Fred's single image test times as I didn't know what his setting was for his 3min reference: The surprising bit for me was the single image scale test taking substantially longer than the 3 tiled images with the same settings:

3 images, x1 ea, tiled on a single 44x47 page, Fusion 5min
Single image from same job scaled to fill 44x47 page, Fusion 20min+
Single image from same job scaled to fill 44x47 page,  Vector 6min

"Off-Line" = paused windows print queue to prevent test from printing. Identical results with "live" printer & printer connection is gigabit ethernet. This should only be an issue during actual printing, not during qimage's processing stage, as no data is sent to printer until after qimage has finished up.

"slow" has no direct basis for comparison, It just felt slow compared to what I remember from my old shop where I was running older workstations, and when I saw the resource use that really got me wondering if something was awry...

Logged
Terry-M
The Honourable Metric Mann
Forum Superhero
*****
Posts: 3251



WWW
« Reply #11 on: November 07, 2014, 08:00:48 PM »

Quote
TerryM is qimage actually using 30% or your RAM?
Yes, I checked with task manager again and it was around 2.6GB

More questions I'm afraid: -
Quote
Qimage analyze current settings found nothing.
Did you do it with the shift key down, that gives memory available information?
Quote
These 3 tests all run with identical settings to the initial tests @ 300dpi
When you say that, is that PPI what was reported above the page preview on the main screen, see screen shot below, the numbers in brackets? Or is it what the image was sized to by other software?

Quote
Single image from same job scaled to fill 44x47 page, Fusion 20min+
That is slow I think!
I did a test on my R2000 with 8  x A3+ prints in the queue to simulate the same area and at 360ppi it took 144 seconds - and my processor is slower than yours. I think Fred has done some similar tests and they confirm more or less what I get.
Back to Mike I think.
Terry

Logged
Fred A
Forum Superhero
*****
Posts: 5644



WWW Email
« Reply #12 on: November 07, 2014, 08:05:45 PM »

Quote
Qimage analyze current settings found nothing.

Hold Shift Key down when you click Analyze Current settings, Please!

Quote
Single image from same job scaled to fill 44x47 page, Fusion 20min+

My test was a print 44 x 47 inches using a 6000 pixel image, just to simulate your condition, although it really doesn't matter.
That took 3 minutes on my old computer.
You took 20 minutes>>??
I think Mike probably has the closest line to locating what is wrong.
It is something in the OS. Any reputable computer gurus near you who might have come across this before.?
Got loads of people running 8.1 and no complaints....
Hey, I just remembered.  I have 8.1 Windows. I just have to reboot into it.

I will try it, and see what I get.
Fred
Logged
Terry-M
The Honourable Metric Mann
Forum Superhero
*****
Posts: 3251



WWW
« Reply #13 on: November 07, 2014, 08:13:44 PM »

Correction
Quote
Yes, I checked with task manager again and it was around 2.6GB
I'm not sure if that is correct as that's the total; I looked in Task manager again at processes; QU was running at about 95,000k
Terry
Logged
TerryZ
Newbie
*
Posts: 10


« Reply #14 on: November 07, 2014, 08:42:14 PM »

With shift Qimage reports more believable numbers:
Start: 2146MB
Addl: 1536MB
Now: 2146MB

NOTE there seems to be a bug in windows CPU reporting - the details tab in performance manager reports processor use at 18-25%, where the main tab reports as 5-10%...  Angry  So it's possible it is purely a multi-core issue I suppose...

"300dpi" was the "High-300 PPI" Interpolation setting in qimage (driver is 600)

Yes 20+ minutes with Fusion scaling! I gave up half way through and retested with vector scaling to get the 6min result.
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Security updates 2022 by ddisoftware, Inc.