Интересная трассировка

Если перевести 4294967292 ms в нормальные человеческие единицы времени то получится примерно 50 суток (sic!). Интересно, чтобы это могло означать... :-)

Лично мои предположения о возможностях такой ситуации...

• Авария у апстрима провайдера с последующей работой по резервному каналу
• Авария в конкретном доме/районе на активном оборудовании, проблемы с линией
• Некорректная отработка биллинговой системы провайдера
• Превышен порог трафика, в следствие чего упала скорость
• Вирусы, черви на компе абонента
• Глюки сетевой карты на компе абонента
• Глюки многоядерного процессора AMD [*SOLVED*]
• Время на компе абонента, узлах провайдера не синхронизировано по NTP

UPD 2010/01/04 18:20 MSK Нашел статью Using the traceroute Command on Operating Systems (Document ID: 22826).

ICMP unreachables are limited to one packet per 500 ms (as a protection for Denial of Service (DoS) attacks) in a Cisco Router. From Cisco IOS Software Release 12.1 and later, this rate value is configurable. The command introduced is:

ip icmp rate-limit unreachable
 [DF] <1-4294967295 millisecond>
 
no ip icmp rate-limit unreachable [DF] (DF limits rate for code=4) 

Refer to Cisco bug ID CSCdp28161 ( registered customers only) for further details.

This limitation is for the aggregate rate of all the ICMP unreachables, as this output shows. Refer to RFC 792  for more information.

type = 3, code 
0 = net unreachable; 
1 = host unreachable; 
2 = protocol unreachable; 
3 = port unreachable; 
4 = fragmentation needed and DF set; 
5 = source route failed.

This limitation does not affect other packets like ICMP echo requests or ICMP "time exceeded" messages.

Статья конечно интересная, в плане защите роутеров от DoS, однако я пока не понял почему же всётаки такие значения на трассировке появляются.

UPD 2010/01/05 02:02 MSK [*SOLVED*] Нашел статью How to fix negative ping times on AMD dual-core CPUs подтверждающую одно из моих предположений. Процитирую:

Problem: When using ping or tracert on dual-core AMD CPUs such as the AMD64 X2 on Windows you may see millisecond counts above 4,000,000,000, which are negative 32-bit numbers displayed as unsigned.
Explanation:
This problem shows up on the AMD64 dual-core CPUs because the power management may slow down or otherwise put to sleep one of the CPU cores when load is low to save power. This causes low-level counters to get out of sync between the two cores. If an application reads those low level counts in order to measure short intervals and gets run on alternate cores, the return values become erratic and may appear to go back in time.
Solution:
Install the a fix called "AMD Dual-Core Optimizer" from the AMD website. Note that you will have to reboot your machine to activate it.

Перевод Google Translate:

Проблема: При использовании пинг или TRACERT на двухъядерных процессорах AMD, такие как AMD64 X2 на Windows вы можете увидеть милисекунда выше 4 млрд, которые являются отрицательными 32-разрядных чисел, отображаемых как беззнаковое.
Объяснение:
Эта проблема появляется на AMD64 двухъядерные процессоры, поскольку управление питанием может замедлить или иным образом усыпить одного из ядер процессора при низкой загрузке для экономии энергии. Это приводит к низким уровнем счетчики, чтобы выйти из синхронизации между двумя ядрами. Если приложение считывает эти низкие показатели уровня для того, чтобы измерять короткие промежутки времени и запускается на альтернативных ядер, возвращаемых значений стать неустойчивой и может показаться, вернуться назад во времени.
Решение:
Установите исправление называется "AMD Dual-Core Optimizer" с веб-сайта AMD. Обратите внимание, что вам придется перезагрузить компьютер, чтобы активировать его.

То есть как раз это подходит, т. к. конфигурация компа, как оказалось, была следующей (цитирую):

ЦП DualCore AMD Athlon 64 X2, 1900 MHz (9.5 x 200) 3600+
Системная плата ECS C51GM-M (2 PCI, 1 PCI-E x1, 1 PCI-E x16, 2 DDR2 DIMM, Audio, Video, LAN)
Сетевой адаптер NVIDIA nForce Networking Controller
Операционка ХР home edition , лицензионная , 32bit система ,роутера не имею.
time shift показывает 2-3 милисекунды

time shift - это как раз время рассинхронизации между ядрами процессора, которое можно измерить с помощью ICEAffinityTest, о котором я уже писал. Там же как раз даны рекомендации по устранению проблемы.
Если верить SYNACK то настоящий отклик можно получить путем вычитания значения на трассировке из 2^32. К примеру:
4294967295-4294967292 = 3 ms
4294967295-4294967293 = 2 ms
Это кажется правдоподобным, т к такие отклики вполне могут наблюдаться на внутренних узлах провайдера.

ЗЫ Теперь это можно давать как олимпиадную задачку по end device troubleshooting :-))