[c-nsp] A puzzle: what could explain this?

[Furnish, Trever G]

Ok, I wouldn't have believed this was possible, but the following
behavior seems to be 100% reproducible.  Can anyone offer any possible
cause?

In the ping responses below, every other response is a high time.
That's not the really remarkable thing -- the really remarkable,
mystifying thing is that the high response times COUNT DOWN TOWARDS
ZERO, THEN START OVER.

To make the pattern more obvious I've cut the first few characters off
of each of the responses that have follow the pattern.  As noted above,
this seems to be 100% reproducible for packets that are generated by
this particular host (a Cisco WS-C3750G-24TS running C3750 Software
(C3750-I9-M), Version 12.1(19)EA1d, RELEASE SOFTWARE (fc1)):

#  ping 192.168.72.29
PING 192.168.72.29: 64 byte packets
---.29: icmp_seq=0. time=86. ms
64 bytes from 192.168.72.29: icmp_seq=1. time=951. ms
---.29: icmp_seq=2. time=54. ms
64 bytes from 192.168.72.29: icmp_seq=3. time=886. ms
---.29: icmp_seq=4. time=70. ms
64 bytes from 192.168.72.29: icmp_seq=5. time=829. ms
---.29: icmp_seq=6. time=56. ms
64 bytes from 192.168.72.29: icmp_seq=7. time=757. ms
---.29: icmp_seq=8. time=127. ms
64 bytes from 192.168.72.29: icmp_seq=9. time=724. ms
---.29: icmp_seq=10. time=73. ms
64 bytes from 192.168.72.29: icmp_seq=11. time=624. ms
---.29: icmp_seq=12. time=73. ms
64 bytes from 192.168.72.29: icmp_seq=13. time=560. ms
---.29: icmp_seq=14. time=63. ms
64 bytes from 192.168.72.29: icmp_seq=15. time=493. ms
---.29: icmp_seq=16. time=55. ms
64 bytes from 192.168.72.29: icmp_seq=17. time=428. ms
---.29: icmp_seq=18. time=175. ms
64 bytes from 192.168.72.29: icmp_seq=19. time=362. ms
---.29: icmp_seq=20. time=76. ms
64 bytes from 192.168.72.29: icmp_seq=21. time=296. ms
---.29: icmp_seq=22. time=78. ms
64 bytes from 192.168.72.29: icmp_seq=23. time=233. ms
---.29: icmp_seq=24. time=55. ms
64 bytes from 192.168.72.29: icmp_seq=25. time=165. ms
---.29: icmp_seq=26. time=55. ms
64 bytes from 192.168.72.29: icmp_seq=27. time=137. ms
---.29: icmp_seq=28. time=71. ms
64 bytes from 192.168.72.29: icmp_seq=29. time=118. ms
---.29: icmp_seq=30. time=1018. ms
======== Here's where it starts over... ==============
---.29: icmp_seq=31. time=88. ms
64 bytes from 192.168.72.29: icmp_seq=32. time=944. ms
---.29: icmp_seq=33. time=103. ms
64 bytes from 192.168.72.29: icmp_seq=34. time=878. ms
---.29: icmp_seq=35. time=89. ms
64 bytes from 192.168.72.29: icmp_seq=36. time=801. ms
---.29: icmp_seq=37. time=71. ms
64 bytes from 192.168.72.29: icmp_seq=38. time=742. ms
---.29: icmp_seq=39. time=54. ms
64 bytes from 192.168.72.29: icmp_seq=40. time=654. ms
---.29: icmp_seq=41. time=55. ms
64 bytes from 192.168.72.29: icmp_seq=42. time=588. ms
---.29: icmp_seq=43. time=55. ms
64 bytes from 192.168.72.29: icmp_seq=44. time=521. ms
---.29: icmp_seq=45. time=54. ms
64 bytes from 192.168.72.29: icmp_seq=46. time=459. ms
---.29: icmp_seq=47. time=73. ms

The same weird behavior is NOT shown by pings of other switches "behind"
this switch.  In fact I can't replicate this behavior using any other
switch in my possession.

The switch has routing enabled, but I wanted to rule out any uncertainty
there so I've gone so far as to remove the routing protocols and switch
to static routes on every device in that site.  We noticed this while
debugging slowness in the LAN at that site after making some routing
changes, but it may have behaved this way all along.  I'm almost
convinced the two "problems" are completely unrelated.

Anyone have any ideas?
 
--
Trever Furnish,
Herff Jones, Inc. Unix / Network Administrator
Phone: 317.612.3519
Any sufficiently advanced technology is indistinguishable from Unix.