A new tool for low level testing...

[Julian Elischer]

Julian Elischer wrote:

> 
> cd /usr/src/sys/modules/netgraph/ether_echo
> make
> make install
> kldload ng_ether
> kldload ng_ether_echo
> ngctl mkpeer em0: ether_echo lower echo
> 
> should work for 7 and 6 without any change.
> 
> It's not hooked to the build yet but I'll do that when I've seen it loop 
> back into my system via the mirrors..
> 

Now hooked into -current
  in my not so quick machines:

This is recorded from the pinging machine, so this includes
2 x rx delay and 2 x xmit delay and 2 x "on the wire" time. (1GB 
ethernet...) on top of the echo time for the module on the far end.

======

07:42:36.380924 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6
07:42:36.381077 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP 
(0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6

153usecs

07:42:37.408370 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6
07:42:37.408465 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP 
(0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6

95 usecs


07:42:38.436187 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6
07:42:38.436312 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP 
(0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6

125 uSec

07:42:39.464488 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6
07:42:39.464582 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP 
(0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6

94 uSec

07:42:40.492874 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6
07:42:40.493024 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP 
(0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6

149 uSec

=========
vs for an actual ping:

=========
07:47:50.589232 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 
(0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 
64053, seq 0, length 64
07:47:50.589347 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 
(0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 
64053, seq 0, length 64

115 uSec

07:47:51.616851 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 
(0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 
64053, seq 1, length 64
07:47:51.617192 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 
(0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 
64053, seq 1, length 64

343 uSec

07:47:52.644629 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 
(0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 
64053, seq 2, length 64
07:47:52.644741 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 
(0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 
64053, seq 2, length 64

112 uSec


07:47:53.672976 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 
(0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 
64053, seq 3, length 64
07:47:53.673179 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 
(0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 
64053, seq 3, length 64

223 uSec

07:47:54.700774 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 
(0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 
64053, seq 4, length 64
07:47:54.700868 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 
(0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 
64053, seq 4, length 64

94 uSec

========

so a bit faster but not hugely.

to get rid of the transmit times etc:

on the echoing machine tcpdump shows:

about 14uSec for ether_echo  (with an occasional 16 or 19uSec)
vs
varying between 26usec and 46uSec for icmp echo.

now even that isn't 'optimal'
we can probably do better than that, as netgraph does have some
overhead..

anyhow it's gotta be better than libpcap and a user program...