[ntp:hackers] easy memory savings in NTP's sockaddr_u

Dave Hart davehart at gmail.com
Mon Mar 1 10:08:50 UTC 2010

Looking at the definition of monlist entry structure, I tried to
estimate the size manually.  I guessed around 64 bytes and saw close
to three times that on a 32-bit platform.  The reason my estimate of
the monlist (or MRU list of most recently seen remote addresses in
incoming packets) entry size was so far off was due to
misunderstanding the size of struct sockaddr_storage.  I discovered
the recommended portable socket programming practice of using struct
sockaddr_storage as the generic form capable of handling IPv4, IPv6,
or any other supported protocol took a toll on ntpd in terms of memory
consumption.  We use a union of sockaddr, sockaddr_in, sockaddr_in6,
and sockaddr_storage in a number of places to hold either a v4 or v6
address in one type, including the MRU list.

It turns out sockaddr_storage's extra space for protocols we don't use
is substantial.  I removed sockaddr_storage from the union and changed
our references to it to use sockaddr instead (to sas_family/sa_family
and on some platforms sas_len/sa_len).  Here's the result in terms of
number of MRU entries that fit in 4MB before and after, on Windows and
on OpenSolaris:

Windows before: mru_maxdepth=24966, mru_maxmem=4096 (168 bytes each)
after: mru_maxdepth=61680, mru_maxmem=4096 (68 bytes)

OpenSolaris before: mru_maxdepth=14169, mru_maxmem=4096  (296 bytes)
after: mru_maxdepth=58254, mru_maxmem=4096 (72 bytes)

sockaddr_u is also part of our per-association and per-local-address
structures, but neither one adds up to much compared to the MRU list.

Dave Hart

More information about the hackers mailing list