4 ms·

> That is, instead of having the ping be processed by an ASIC, the ping gets processed by the router's CPU. I wonder how true that is anymore, with ICMPv6 proc

> That is, instead of having the ping be processed by an ASIC, the ping gets processed by the router's CPU. I wonder how true that is anymore, with ICMPv6 processing being a mandatory part of IPv6. I could totally see ICMP processing being a low-priority task, but am far less certain that it would not be done by dedicated hardware these days. On top of that, I've never, ever, ever noticed the behavior he's observing with either my cable ISP connection, or the terrestrial microwave link provided by my local WISP. I don't have enough data to say that I'd never see that behavior if I happened to ping some router powered by a potato... but I've pinged a whole bunch of systems over the years, and have never seen variation like what he describes.

lxgr 2y ago
I’ve seen ping latencies of up to 30 seconds (yes, 30 000 milliseconds!) with a certain cable ISP, while at the same time VoIP (RDP over regular Internet IP, not “cable voice” or ISP-provided SIP, which often has its own QoS class) was borderline usable. Could have been traffic shaping or prioritization (their network was in complete shambles after all), but ICMP was definitely taking some lower priority queue or path.
- kkielhofner 2y ago
  *RTP
  - simoncion 2y ago
    I'd expect many fewer folks use RTP than use RDP, so I'd expect that "RDP" was absolutely not a typographical error.
    - lxgr 2y ago
      I did indeed mean RTP! Almost everybody uses RTP these days, whether they realize it or not. It’s the basis for WebRTC and most proprietary VoIP solutions.
toast0 2y ago
> I wonder how true that is anymore, with ICMPv6 processing being a mandatory part of IPv6. ICMPv6 may be mandatory according to specs, but you can still drop most of it with no ill effects. You probably shouldn't drop needs fragmentation packets, but everyone has adapted to those being dropped sometimes, so... If you ignore neighbor discovery, you'll have trouble reaching your neighbors, though. But neighbor discovery is low volume mostly, and can be handled by the cpu, not the asic. Needs frag likely won't be directed at the router ip, the asic can forward them just fine though. I've certainly seen much more variable ping times for routers than for the hosts behind them. If the router's cpu is less busy, ping times are usually a bit more than a host that's right there, and as the router's cpu gets more busy, the rtt increases or pings get dropped. It's not usually a factor of how busy the links are either; routers tend to have a pretty limited amount of cpu and if they're getting a lot of traffic, it's easy to overload them. I haven't seen it happen quite in the bands like in the article, but sometimes it varies quite a bit. The results tend to be much more consistent if you can get a rtt from full host and not a router.
- deleted 2y ago
  [deleted]

lxgr 2y ago

I’ve seen ping latencies of up to 30 seconds (yes, 30 000 milliseconds!) with a certain cable ISP, while at the same time VoIP (RDP over regular Internet IP, not “cable voice” or ISP-provided SIP, which often has its own QoS class) was borderline usable. Could have been traffic shaping or prioritization (their network was in complete shambles after all), but ICMP was definitely taking some lower priority queue or path.

kkielhofner 2y ago
*RTP
- simoncion 2y ago
  I'd expect many fewer folks use RTP than use RDP, so I'd expect that "RDP" was absolutely not a typographical error.
  - lxgr 2y ago
    I did indeed mean RTP! Almost everybody uses RTP these days, whether they realize it or not. It’s the basis for WebRTC and most proprietary VoIP solutions.

toast0 2y ago

> I wonder how true that is anymore, with ICMPv6 processing being a mandatory part of IPv6. ICMPv6 may be mandatory according to specs, but you can still drop most of it with no ill effects. You probably shouldn't drop needs fragmentation packets, but everyone has adapted to those being dropped sometimes, so... If you ignore neighbor discovery, you'll have trouble reaching your neighbors, though. But neighbor discovery is low volume mostly, and can be handled by the cpu, not the asic. Needs frag likely won't be directed at the router ip, the asic can forward them just fine though. I've certainly seen much more variable ping times for routers than for the hosts behind them. If the router's cpu is less busy, ping times are usually a bit more than a host that's right there, and as the router's cpu gets more busy, the rtt increases or pings get dropped. It's not usually a factor of how busy the links are either; routers tend to have a pretty limited amount of cpu and if they're getting a lot of traffic, it's easy to overload them. I haven't seen it happen quite in the bands like in the article, but sometimes it varies quite a bit. The results tend to be much more consistent if you can get a rtt from full host and not a router.

deleted 2y ago
[deleted]