| Thread Previous • Date Previous • Date Next • Thread Next |
On 05/31/2013 04:55 AM, Klaus Schürmann wrote:
May 31 10:33:08 swift-proxy1 proxy-logging 10.4.2.99 10.4.2.99 31/May/2013/08/33/08 GET /v1/AUTH_provider1/129450/829188397.31 HTTP/1.0 200 - Wget/1.12%20%28linux-gnu%29 provider1%2CAUTH_tke6408efec4b2439091fb6f4e75911602 - 283354 - txd4a3a4bf3f384936a0bc14dbffddd275 - 0.1020 - May 31 10:33:26 swift-proxy1 proxy-logging 10.4.2.99 10.4.2.99 31/May/2013/08/33/26 GET /v1/AUTH_provider1/129450/829188397.31 HTTP/1.0 200 - Wget/1.12%20%28linux-gnu%29 provider1%2CAUTH_tke6408efec4b2439091fb6f4e75911602 - 283354 - txd8c6b34b8e41460bb2c5f3f4b6def0ef - 17.7330 - <<<<<<<<<<<<<<
Something I forgot to mention, which was the basis for my TCP retransmissions guess. Depending on your kernel revision, the initial TCP retransmission timeout is 3 seconds, and it will double each time - eg 3, 6, 12. As it happens, the cumulative time for that is 17 seconds... So, the 17 seconds and change would be consistent with a transient problem in establishing a TCP connection. Of course, it could just be a coincidence.
Later kernels - I forget where in the 3.X stream exactly - have the initial retransmission timeout of 1 second. In that case the timeouts would go 1, 2, 4, 8, etc...
rick
| Thread Previous • Date Previous • Date Next • Thread Next |
