Administrative

Compatibility Testing Submission Generated by Support System ...
 

Compatibility Testing Submission Generated by Support System ...
 

Good morning. I have a doubt about the test environment.
Do I need to create an operating system image, with the backend already activated, and send it to Ricoh? If so, where can I submit this image?
In this image, we will use the trial license from Microsoft, which is 180 days, as we do not have a Windows Server license.
Another point is about WMware.
We don't have VMware here. Would I need to purchase WMware to generate this image? Does the license mentioned in the Compatibility Testing Program Form need to be purchased by us or does Ricoh just need to know the OS version?
Thanks in advance for your attention.

Compatibility Testing Submission Generated by Support System ...
 

Compatibility Testing Submission Generated by Support System ...
 

Hi Team,

Hoping you might be able to help with a problem we're seeing when using PaperCut Hive on Ricoh IM C2000, C3000, C4500s devices, where reports of poor printing performance in the field are increasing, particularly when using IPP.

From a high level, when we release multiple jobs to a particular device, we have seen the device effectively lock up and in some cases we observe that the device doesn't properly respond to an ipp-get-attributes requests from other edge nodes (an edge node is part of the PaperCut Hive solution design).  We will give a bit more information on the architecture in the details below.

Customers have been reporting issues in the field with these series of devices and we have investigated internally within PaperCut and we believe we are seeing issues with the devices, rather than the embedded software.  We have also tested without the embedded software installed and we are seeing the same problems manifesting. 

Over the past few months we have been working with our Ricoh UK partners, in particular our main contact in relation to a problem at Kernow Schools (UK) -  Joshua Watkins Joshua.Watkins@ricoh.co.uk and technical colleagues Martin Ashcroft martin.ashcroft@ricoh.co.uk and Craig Wakefield craig.wakefield@ricoh.co.uk.  

We've also spent some time recently in the Ricoh Melbourne (AU) lab with Jason Jordan jjordan@ricoh.com.au, and we were able to reproduce the issues reported by our customers.  In addition, Jason also had Peter Buckham pbuckham@ricoh.com.au who was able to extract logs from the device (attached) which may be helpful for debugging.

Could you please have a look at the issues described in more detail below, in addition to a packet capture and the logs collected from the device (in the attached zip file), and hopefully advise of next steps for potentially collaborating on a solution to this problem that is impacting our customers.

There are multiple teams collaborating internally at PaperCut on this issue, and I'm happy to be the point of contact for all of those teams - via RiDP if this is the correct location to raise the issue.  If RiDP isn't the correct forum to raise the issue, could you please advise how we can raise the issue with the appropriate team and provide all necessary contact details?

Thanks

The issues noted below are occurring with or without the PaperCut embedded app installed on the device.

Papercut Hive architecture

Hive have multiple printing nodes in a single network (LAN) called 'edge nodes' (EN - this is a PC with papercut software used to print via IPP). When a user releases a list of jobs, one EN will get them and start printing one by one. However, during this time, other nodes can access the printer for get-printer-attributes. Any EN in the local LAN can access the printer simultaneous via IPP.

IPP Get Attribute not responding/failing on devices

When the printer is fairly busy i.e. They don’t seem to be so overwhelmed with jobs that they can’t cope, but also not usually in a state where they haven’t printed anything for a long time and so are in deep sleep.

When another EN tries to reach the printer to get-printer-attributes, the printer returns a network error.

During investigations, we found out several reasons for these failures:

• IPP connection establishment timeout happens

• printer is resetting the TCP connection in the midst of the get-printer-attributes transaction. See tcp-reset-from-printer-after-connection-established.pcapng

Note - when using ipptool, it retries multiple times in these scenarios, sometimes takes more than 10sec to finish the call. In our case, to finish a print job quickly we are unable to wait that long in this step.

Example:

​​​​​​​2023/03/13 13:40:09 pc-printjob-processor.exe: STDERR|ERROR: ipp command failed: { Type: 33, Args: get-printer-attributes:[ipps://172.30.3.58:443/ipp/print] \ failed err: Post "https://172.30.3.58:443/ipp/print": net/http: TLS handshake timeout, elapsed:10.0709126s route[0.0.0.0 0.0.0.0 172.30.1.1 172.30.1.213 271] } 

Printer’s IPP stack went to a state where it didn’t respond at all. Needed a hard reboot.

See PXL_20230323_005807871.jpg

Recreated two times during testing, specially running back to back or parallel print jobs, the printer went to a state where it didn’t respond to any IPP URIs, admin page was frozen as well. There’s no 100% reliable method to reproduce this. So far, this has happened when we printed about 5 simultaneous jobs.

Slow printing

https://www.ricoh.co.uk/product-feed/uk/docutech-office-solutions.html?Product=31901 From above:

First output speed: B/W 4.5 seconds First output speed: full colour 6.9 seconds Continuous output speed 30 ppm

Customers have complained of slow IPP printing on Ricoh.

The logs seem to indicate that we send the job to the Ricoh pretty quickly (3-5 seconds), but then there is a significant delay of the printer processing the job (20-40 seconds).

Two of sample cases:

Doc 1 first page was 22 seconds Doc 2 First page was 16.89 seconds Each subsequent page of doc 2 was 4 seconds.

According to the Ricoh spec sheet the first page should take 4.5 seconds. With the current timings it roughly equates to 10 pages per minute not the 30 as advertised. Even without the first page time we’re looking at 15 ppm.

Test at Ricoh Melbourne lab

We did a test with a C2000 at Ricoh lab.

• test-report.md - Details on test performed, results and log analysis.
• C2000-MachineInfo_3088RC20387_20230328_150542.tar - ricoh device logs.

Test details

We Sent 20 parallel jobs (same 7-page color, double sided document was used) to the printer from the same PC via IPP. This test was repeated 2 times and got the same behaviour. The idea of this test is to test the printers ability to handle multiple jobs and while the jobs are printing, how it replies to get-printer-attributes calls from other nodes.

The summary of observations and issues:

When a number of parallel jobs created with the printer.

• The printer accepts about 3 jobs first.
• Then the printer starts printing/processing them.
• During this time the printer's responses to ipp-get-attributes is not reliable, sometimes it doesn't responds, some cases it responds with media-low-warning.
• The first 3 jobs takes about 10mins to print, during this time the printer is in a state where:
  • It doesn't respond or respond with media-low-warning or doesn't respond at all.
  • During this time the printer doesn't let other job creation
  • Get-Job-Attributes for the above created jobs is properly replied.
  • Queue print working.
  • Scanning working.
  • All other printer operations are seems to be working, and visually no indication of it being busy.
• After the first set is printed, the printer accepts the next 3 and starts the same cycle again.

Compatibility Testing Submission Generated by Support System ...
 

Compatibility Testing Submission Generated by Support System ...
 

Softlog Systems has been brought out by Dynamic Software Solutions and has updated invoicing details - is it possible to gethm reissued

New Contact person is: Andrew Tsiorvas <andrew@dssolutions.net.au>

Compatibility Testing Submission Generated by Support System ...