Well, as you may guess I have echo replies working, so the server can now be pinged :) Oh, and this might be interesting... Top is our new "stack", below is existing net_server. .133 is a tulip card under our stack, .134 is a 3Com under net_stack, in the same machine, pinged from the same machine (FreeBSD 4.4) over a 100Mb half-duplex network. Worth noting is that the net_server results don't show the initial delay of dealing with an arp cache as this was the second attempt in under 20 minutes so the value was already stored. In our results the initial delay is us sending/processing the arp request :) And now, without further ado, the results... bash-2.04$ ping 192.168.0.133 PING 192.168.0.133 (192.168.0.133): 56 data bytes 64 bytes from 192.168.0.133: icmp_seq=0 ttl=64 time=1.043 ms 64 bytes from 192.168.0.133: icmp_seq=1 ttl=64 time=0.374 ms 64 bytes from 192.168.0.133: icmp_seq=2 ttl=64 time=0.393 ms 64 bytes from 192.168.0.133: icmp_seq=3 ttl=64 time=0.399 ms 64 bytes from 192.168.0.133: icmp_seq=4 ttl=64 time=0.378 ms 64 bytes from 192.168.0.133: icmp_seq=5 ttl=64 time=0.379 ms 64 bytes from 192.168.0.133: icmp_seq=6 ttl=64 time=0.369 ms 64 bytes from 192.168.0.133: icmp_seq=7 ttl=64 time=0.380 ms 64 bytes from 192.168.0.133: icmp_seq=8 ttl=64 time=0.565 ms bash-2.04$ ping -c 9 192.168.0.134 PING 192.168.0.134 (192.168.0.134): 56 data bytes 64 bytes from 192.168.0.134: icmp_seq=0 ttl=255 time=1.227 ms 64 bytes from 192.168.0.134: icmp_seq=1 ttl=255 time=2.400 ms 64 bytes from 192.168.0.134: icmp_seq=2 ttl=255 time=1.515 ms 64 bytes from 192.168.0.134: icmp_seq=3 ttl=255 time=2.974 ms 64 bytes from 192.168.0.134: icmp_seq=4 ttl=255 time=2.185 ms 64 bytes from 192.168.0.134: icmp_seq=5 ttl=255 time=0.548 ms 64 bytes from 192.168.0.134: icmp_seq=6 ttl=255 time=1.261 ms 64 bytes from 192.168.0.134: icmp_seq=7 ttl=255 time=1.109 ms 64 bytes from 192.168.0.134: icmp_seq=8 ttl=255 time=1.836 ms Now, I'd like to ask everyone with a degree of knowledge of C to go through the code and look at whether it can be improved (I know it can be). Why now? This is probably as fast as the stack will ever go and changes now gain us a lot. Also the code we have will more than likely be used as templates for what follows, so we get this right and what follows will be better :) david