It’s true. For the first time in my life, I am head over heels in love. I’m not even sure what to write; words are about as inadequate to express love as a glass is to contain the ocean. But since this is mainly a technology blog, it may be useful to explain it like this.
When I receive a SYN packet from her IP address, every other packet in my outbound queue is deferred for the reply SYN+ACK. When I receive the inevitable ACK the PSU voltage is slightly increased, and the CPU frequency accelerates a bit (sometimes increasing the error rate). The GPU starts blurring and desaturating irrelevant portions of the output video buffer. Every packet transferred in this connection is logged to disk. For the life of the connection, the RTC fires much less often, sometimes as little as a fifth of what it should, requiring frequent synchronization of the system clock using an external time server. Existing connections may be randomly disconnected, and incoming SYNs have a greater chance of being ignored (based, of course, on the importance of the remote host). Most processes are reniced to 19 or sent SIGSTOP.
When the FIN is received, the reply FIN+ACK is placed at the very end of the outbound queue and delayed as long as possible. Then the ACK response is received. The CPU frequency and PSU voltage drop a bit, but remain higher than usual. Incoming connections are again accepted, and processes are gradually restored, being reniced back to 0 or sent SIGCONT. The RTC begins firing normally, while the GPU still blurs the output buffer for some time, eventually returning to normal operation.
Several times a day, the kernel inexplicably assigns real-time scheduling to a process whose only job is to analyze the logs of previous connections. Some of the effects described above may be experienced while this process executes. Interrupting this process or altering the scheduling may take several minutes. When this finally occurs, the inbound packet buffer may have overflowed due to the lack of time slices given to the networking stack, resulting in varying degrees of packet loss on established connections, and possibly a missed connection or two.
Periodically a SYN will be sent to her IP address. If no connection is established within several hours, the PSU voltage may drop below normal and the CPU error rate may increase dramatically.
That’s about as close as I can get. Don’t bother calling me a geek; I already know.
I love you, De.
6 Replies to “Love according to a geek”
chris i feel dumber now that i read this
Thanks, I think?
Be glad you don’t understand it; that would put you in the camp with a higher probability of having no life. 🙂
Glad to hear from you, Nick! It’s been too long.
You make my PSU voltage increase, too.
I love you, too, Chris Howie!
I LOL! You are so creative!! Glad to see you can express your feelings in your “heart” language…. and I feel dumber now, too. 🙂 m
You may want to up the VDIMM a bit if you’re experiencing some instability. Just make sure you’ve got enough airflow to negate the increased thermal output.
You’ve really got it bad! And, I’m afraid there is no cure.
Comments are closed.