Subject: Re: random ip_id must be configurable
To: Jun-ichiro itojun Hagino <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/11/2003 18:23:55
In message <20030912011355.ADE988B@coconut.itojun.org>Jun-ichiro itojun Hagino writes
>> * There are environments where the computational cost does not justify
>> deploying this fix.
> have you measured it? i mean, not on the userland but macro benchmark
> like scp/ftp/whatever. i there *any* noticeable difference?
> (if you use vax/pdp, yeah, maybe...)
1. Itojun, you're asking the wrong question. You committed the change.
You changed the status-quo-ante. The onus is on you to measure
the performance. (This goes for seveal recent changes, too.)
2. In compute-intensive environments, any additional CPU load is a
change for the worse. (See what Thor said about compute cluster interconnects).
3. This is NetBSD. Yes, we support vaxes. We support sun-3s.
4. *BSD gets used in embedded environments which can also (given
that gigabit ethernet has become a commodity) every cycle counts, where
CPUs cannot keep up with the network.
One example: Jason Thorpe recently optimized how we fill in the MAC
address for IP over Ethernet, because it made a measurable (and to him or Wasabi,
worthwhile) improvement for StrongArm over gig-e.
5. I have bencmarked similar prng code on Pentium IV. Turns out shifts are
particularly slow on P4s, and for (smiilar but diffeerent) code: and yes,
the overhead is measurable.