/* As outlined in RFC 2525, section 2.17, we send a RST here because
* data was lost. To witness the awful effects of the old behavior of
* always doing a FIN, run an older 2.1.x kernel or 2.0.x, start a bulk
* GET in an FTP client, suspend the process, wait for the client to
* advertise a zero window, then kill -9 the FTP client, wheee...
* Note: timeout is always zero in such a case.
*/
Ok, so the RST is explained and well justified by the literature. But what are the “awful effects” of sending FIN instead? Can someone explain? > All in all, the pairs notion is redundant.
I hope you understand and appreciate what I have written above so the
following does not apply to you anymore. you see, I wrote it all because
I _really_ wanted to say that that sentence is the single most ignorant
and shallow-minded line that I have ever seen in any programming language
newsgroup or forum and I hope _never_ to see anybody display such utter
disregard for the brilliance and genius of people who came before them
just because they grew up in an age when "simple interface" is sneered
and laughed at in favor of "simple implementation" so any dumb fsck can
implement it right out of a "for Dummies" book.
From where I sit in 2025, I have nothing to add.
At some point during all my fiddling with this stuff, I discovered a correlation between GPU power consumption (as indicated by iStat Menus) and fan speed. For example, if I switched to high resolution, the power would increase, and at low resolution, power would decrease. And of course more power means more heat, which causes the fans to run. That kind of made sense: moving more pixels consumes more power.
But I also observed an effect caused by refresh rate. Oddly, I seem to recall 30Hz would cause increased power draw but 60Hz the power draw was reduced. Yes, this seems counterintuitive. Since I didn't have a good model for what caused the increased power draw, I decided to try all combinations of the settings. On a lark I tried inverting the image and it actually affected the power draw! Probably has something to do with the access order of memory, but I don't really know. And indeed it seems odd that running the image upside down actually pulled less power than right side up.
The cabling issue was a bit more complicated. My initial configuration was to run the video through a dock, with the dock's video output going to the monitor. That always resulted in high power draw. Connecting the computer directly to the monitor did have the effect of reducing power draw... but only in certain configurations.