多跳路徑的rtt 用ping 命令來測量，ping 命令功能是傳送icmpecho 數據包[5]。本文將基於hmcp 多跳路徑的rtt 與單信道下多跳路徑的rtt 進行比較。由於單信道中沒有信道切換，比較這兩種情況有助於理解信道切換延遲對多跳路徑的rtt 影響。單信道網路中，不同路徑的rtt 差距只有數毫秒。而在hmcp 實驗中，信道切換延遲決定了路徑的rtt。
首先，在源節點和目的節點間建立一條正向和反向的單一路徑，即從目的節點到源節點的反向路徑與正向路徑中的節點是相同的，只是節點順序為逆序。在這種情況下，無論何時路徑中信道改變，每箇中間節點的信道切換延遲決定了rtt。在混合多信道協定中，信道改變意味著路徑上的連續節點監聽著不同的固定信道。對於這種路徑，中間節點在不同信道上（固定信道在下一跳）傳送數據到目的節點並且在不同信道上（固定信道在前一跳）回傳給源節點。由於每個節點上只有一個可換信道接口，因此，多跳信道轉換中，每箇中間節點在傳送數據到目的節點和回傳給源節點的過程中不得不切換信道。正如前面所提到的，可換接口每切換一次信道時，在信道上停留的時間至少為chan_min_time（目前設定為20ms）。當可換接口上的其他信道接收到數據幀時，chan_min_time 定時器開始計時。
因此，多跳路徑的rtt 每增加一跳，rtt 要增加chan_min_time*2。因為中間節點要傳送數據到目的節點， 可換接口需要連線到下一跳的接收信道， 在這之前要等待chan_min_time。之後中間節點要回傳數據到源節點，需要切換信道到前一跳的接收信道上，這也要等待chan_min_time。因此，每跳rtt 都要增加chan_min_time*2（=40ms）的延遲。表1 顯示的是單信道和多信道下的rtt。在hmcp 實驗中多跳路徑的最小rtt 也符合前面討論的結論。平均rtt ≈ chan_min_time*2（number_of_hops-1）,這裡number_of_hops＞1。
在hmcp 實驗中，多跳路徑的最大rtt 值稍微偏高，主要是在網路中廣播hello 信息的原因。每個節點廣播一條hello 訊息，這條hello 信息包含了它的固定信道和鄰節點信息。
這些信息每hello_time_interval（默認設定為5s）傳送一次。因此，每5s 每個節點都會廣播一條信息出去。在hmcp 中，所有信道都會傳送廣播信息。目前，每個節點使用5 個信道，固定接口傳送數據包到固定信道上，可換接口傳送數據包到其他四個信道上。每hello_time_interval 節點需要在可換接口上切換3 個信道廣播hello 數據包。因此，如果一個數據包在某個信道上要被轉發，此時此信道正在傳送廣播訊息，那么這個數據包可能要等3 個信道切換完後才被傳送。因此，在某個節點上，如果數據包排列在廣播信息後傳送，數據包可能會有3*20=60ms 的延遲。最大rtt 之所以偏高的原因就在此。由於在一條路徑的不同節點上廣播hello 訊息，icmpecho 或者icmpechoreply 可能會延遲。ping數據包每分鐘傳送一次，而hello 訊息每5 分鐘傳送一次。因此，平均每5 個ping 數據包被hello 訊息影響一次。其他4 個ping 數據包的rtt ≈chan_min_time*2*(number_of_hops-1),這裡number_of_hops＞1。
而多跳路徑的最小rtt 比理論值稍微低點。這也是由於受hello 訊息機制的影響。雖然路徑中的節點在可換接口上通過切換信道來廣播hello 訊息，但是可能有這樣一種情況發生：