На самом деле время пинга складывается из нескольких составляющих. Основные две из них:
- время, которое тратится промежуточными узлами на передачу до пингуемого узла и обратно;
- время, которое пингуемый узел тратит на обработку запроса и формирование/отправку ответа.
Именно это порождает порой забавные артефакты. Смотришь трассировку, и видишь, что пинг промежуточных узлов в основном медленно растёт по мере их удаления, но встречаются случаи, когда время пинга следующего узла меньше, чем предыдущего. А всё просто - предыдущий узел перегружен функциями, ответ на пинг имеет наименьший приоритет, потому узел сперва сделал всё нужное, и только потом ответил. А порой и не ответил вообще, или отвечает через раз.
Что самое противное, ни одну из этих составляющих нельзя измерить надёжно. А тебя по большому счёту, интересует только первая из названных составляющих. Даже на время реакции целевого, конечного, узла можно начхать - на TCP/UDP он будет реагировать гораздо шустрее, чем на пинг, а если будет тормозить, то отвечающий софт, а не передача.
А на скорость передачи не заморачивайтесь. Пакетики в пинге короткие, частота передачи высокая, так что время передачи пакета от узла к узлу по медному или оптическому кабелю в подавляющем большинстве случаев просто меньше точности измерения времени.