Your link describes disabling SNMP in the driver before it gets to the registry edit and you were in there in your 2nd post where you tried to enable LPR but didn't fill in the queue name.
Start > Devices and Printers
right-click the printer and go to Printer Properties > Ports > Configure Port
You cannot change the name but can change the IP but neither is necessary as there are radio buttons or check boxes for everything RAW/LPR/SNMP. RAW will always be port 9100 on printers without multiple print queues
LPR should have the queue named lp
LPR Byte Counting should always be disabled
Disabling SNMP here is step 1, if it works, then the issue is the SNMP traffic and this might be possible to fix by changing the SNMP name as shown in my previous post from the default "public" in a case where the traffic might be duplicated or trapped on the network or in the OS as some sort of conflict. So in that case change it on the device, then reenble it in the driver and change the Community Name to whatever you put on the copier. But this would then need to be done on each PC as the OS won't auto update it from the Windows default of "public". This is where the Wireshark trace would come into play, to find out where the issue is, but reading the trace is not a simple task, you would need to have a strong networking background to understand the trace. Xerox has engineers that can, and you could probably get them to read them through 2nd level contact. But they would be fairly limited in narrowing down the exact cause since it would just be IP addresses and responses, they have no way of knowing what each IP belongs to or what software is running on them, or even if they are computers/servers/routers/switches/printers etc etc.
Hi Leon,
What kimzi proposed would be a fix if it resolves the issue. A workaround would be to go into that same port and disable the SNMP option all together as it would fix it at a cost in that case where Kimzi's suggestion would break nothing and would also be better than the current setup in every possible way as LPR is far better in all regards than RAW.
The issue you are seeing is likely an issue with SNMP traffic, which would be easily verified by removing SNMP as an option in the port.
But if the SNMP is disabled it stops bi-directional communication so it is a workaround where you are choosing to have speed over functionality (Toner and paper levels will be unavailable in driver and the Job notifications will get disabled)
Finding the SNMP issue takes way more than could be done on the forum, but a good method is to :
1. Disable SNMP, if the speed goes to normal after a reboot
2. Install locally to eliminate the Server and the multiple driver/queues on it (32bit and 64 bit) and the extra hop (client PC looks for info on server, which looks for info on printer, then printer tells server and server tells printer)
3. If it works fine locally installed on client check that it works locally on server.
4. If it works locally on the client and the server, check to see if it is cross architecture (64 bit server and 32 bit client)
5. Now that you have the proper layout and know what setups do not have the issues do a wireshark trace of the driver use from client to printer to see the issue as the network sees it, everything has a timestamp so you will see exactly where the lag is.
If for some reason things are being intercepted you could likely just change the SNMP settings on Centerware Internet Services via Properties > Connectivity > SNMP > Edit and try making public be public2
Then go back to the driver and turn SNMP back on and add the 2 at the end.