Garrett D'Amore writes: > Peter Memishian wrote: > > Documentation is useless as a programming interface, which is what e.g., > > Fishworks needs this for. The application can account for its own > > overheads and provide whatever clues are necessary to help the driver work > > together to find the right value, but leaving it to the documentation just > > doesn't cut it. > > > > -- > > meem > > > How do you programmatically handle this? 8150 is almost always > *wrong*. The only thing its good for is a benchmark special, or an > isolated network with just these kinds of devices on it. Everyone > everywhere else will use 9000 as that is the de-facto standard.
Indeed. I think the intended usage is with networks that are even more of a "walled garden" than your garden-variety walled garden. ;-} The question is: for those who don't care about normal interoperability and *do* care about wringing out the last bit of performance from these drivers by customized network-wide tuning (one hopes that _all_ the other avenues of performance improvement have already been explored, so we're not just talking about mere hackery), how do we make this information available? I still agree with you, Garrett, that this is fundamentally a documentation issue, because the administrator of most such systems is almost certainly going to need to deal with multiple devices with different capabilities and configuration needs. That means "planning" -- a task that, in networks at least, the CLI isn't well suited to solving. If we really want to automate it, then I think the right answer is to make the performance details available to a network management tool that will help the user meet all of the constraints of his network. I still think that implies that exposing this on the command line will be at best misleading, and at worst actively harmful -- it'll send confused users down some dark alleys. It's a bit like trying to "tune" a disk for the optimum transfer size based only on the disk's parameters, and without thinking about whether the OS supports that size or what sort of workload the application will offer. Great ... it works best with 9371 bytes per transfer. Now what? -- James Carlson, Solaris Networking <[email protected]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
