We have been receiving complaints of slow printing services on and off for the last couple of months at the centre, but had been unable to nail down any problems. Endless combing through documentation and reviews of the settings turned up nothing. Today I happened to recognized the problem while doing some other network configuration work.

It turns out the server that handles the print queues had its interface locked at 100Mbs full-duplex. The switch was set to auto-negotiate, resulting in it setting the connection at half-duplex. This is a recipe for exactly the kinds of problems we were experiencing - poor performance under load. Once the server was configured to auto-negotiate the link (since it will be moving to a new switch soon), printing performance drastically improved. Printing a PDF with graphics that took several minutes at times now prints in seconds.

This quote excerpt from Critical Networks Advanced Ethernet pages explains netter than I could how the duplex mismatch occurs:

So how does a duplex mis-match occur? The process below describes just one common scenario where one device is auto-negotiating but the other device is hard coded for full duplex:

1. The hard coded device is configured for 100baseTX full duplex (100FD) operation. It does not listen for FLPs sent by the other device, it simply waits for the correct idle signal before making the link active
2. The auto-negotiating device will notice the absence of FLPs and will see the 100baseTX idle signal using parallel detection. It will make the link active as 100baseTX half duplex (100HD).
3. Now link is active on both devices and data will be transmitted, but there will be performance problems
4. The hard coded 100FD device can send data at any time regardless of whether the 100HD device is transmitting. This causes the 100HD to detect both excess and late collisions and to abort the current frame in mid-transmission. This in turn causes the 100FD device to see many runts, alignment, CRC and FCS errors.