Annotation of wikisrc/projects/project/kernel_udp_timestamping.mdwn, revision 1.3

1.1       jmmv        1: [[!template id=project
                      2: 
                      3: title="Socket option to timestamp UDP packets in the kernel"
                      4: 
                      5: contact="""
                      6: [tech-kern](mailto:tech-kern@NetBSD.org)
                      7: """
                      8: 
                      9: mentors="""
                     10: [Christos Zoulas](mailto:christos@NetBSD.org)
                     11: """
                     12: 
1.2       jmmv       13: category="kernel"
                     14: difficulty="easy"
1.1       jmmv       15: duration="3 months"
1.3     ! wiki       16: status="done 2012"
1.1       jmmv       17: 
                     18: description="""
                     19: Many applications that use UDP unicast or multicast to receive data, need to store the data together with its reception time, or time the arrival time of packets as precisely as possible. This is required for example in order to be able to replay the data in simulated real-time to be able to do further performance analysis or quality control. Right now the only way to do this is to call [recv(2)](http://netbsd.gw.com/cgi-bin/man-cgi?recv+2+NetBSD-5.1+i386)/[recvmsg(2)](http://netbsd.gw.com/cgi-bin/man-cgi?recvmsg+2+NetBSD-5.1+i386)/[recvfrom(2)](http://netbsd.gw.com/cgi-bin/man-cgi?recvfrom+2+NetBSD-5.1+i386) to grab the data, followed by [gettimeofday(2)](http://netbsd.gw.com/cgi-bin/man-cgi?gettimeofday+2+NetBSD-5.1+i386)/[clock_gettime(2)](http://netbsd.gw.com/cgi-bin/man-cgi?clock_gettime+2+NetBSD-5.1+i386). This is undesirable because:
                     20: 
                     21: * It doubles the number of system calls limiting the effective maximum reception rate.
                     22: * The timing of the packet is imprecise because there non-deterministic delay from the time that the packet hit the network adapter till the time userland received it.
                     23: 
                     24: Linux provides a socket control message to add timestamp ancillary data to the the socket, which can be controlled by 2 different socket options SO_TIMESTAMP and SO_TIMESTAMPNS, using [setsockopt(2)](http://netbsd.gw.com/cgi-bin/man-cgi?setsockopt+2+NetBSD-5.1+i386). Recently linux added more [SO_TIMESTAMPING_*](http://lwn.net/Articles/325929/) options to provide even more precise timestamps from NIC cards that support them. This project is about implementing those options on NetBSD. Their implementation should be done as close to the code that does reception as possible to minimize timestamp delay. The SO_TIMESTAMP option is already done in the kernel (perhaps only partially): [kern](http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/uipc_socket.c), [ip](http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/ip_input.c), [raw](http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/raw_ip.c), [udp](http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/udp_usrreq.c), [ip6](http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/ip6_input.c), [sys](http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/socket.h). A good reading would also be [timestamping.c](http://alinux.tv/Kernel-2.6.34/networking/timestamping/timestamping.c)
                     25: 
                     26: This project is to finish implementing SO_TIMESTAMP in the kernel, test it, add SO_TIMESTAMPNS (both very easy, should be a few hours of work), and then design and implement the SO_TIMESTAMPING_* options, get at least one driver working with them and test them.
                     27: 
                     28: """
                     29: ]]
                     30: 
                     31: [[!tag gsoc]]

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb