I don't think I see an advantage and would be curious as the speed/duplex settings on the attached PC and switchport when the customer experienced this drop in performance. I am not sure what kind of troubleshooting they performed but it was simply a matter opinion through use then I question the validity. Meaning, if I had a switchport or PC set to not auto-negotiate and the phone was set to auto-negotiate, the performance would be noticeably poor. Then I could modify the phone to use hardcoded speed and duplexity and the performance would improve. Of course, we know that the speed/duplex setting was the root cause. It was the difference in config on two sides of the same connection. I'd be curious if they looked at configs on the switchport and PC when they noticed the performance issue. I would also be curious if they monitored the switchport interface for any incremental error counts.

Now, all that said a good portion of the solution is software. So, there could be some weird defect with auto-negotiation versus hardcoding. Either in the firmware or the switch software (or PC network driver?). I don't recall ever stumbling across a defect that would explain this. But if I did, it was a while back.

I'd recommend actually doing a validity test of this theory. You would want to use the same PC, phone, switch port, and test station. You would probably want the test station on the same switch, VLAN, and (depending on the switch type) same group of ports. Come up with a large file and then do a file copy. Maybe even use TTCP so you can get measurements other than elapsed time. Execute a test for auto/auto on everything and then repeat for 100/full (or 1000/full as the case may be).

I think it would be worth doing the test because I recall back in 2000 when I had a customer go the route of hard coding everything it was a nightmare on a daily basis. Someone would place a phone and always forget to hard code one side of the connection.

HTH.

Regards,

Bill