Reading computer manuals without the hardware is as frustrating as
reading sex manuals without the software.
Arthur C. Clarke
Where do I begin. I am forced further and further from BSD land into Linux. Where completely messed up ways of doing things seem to be the norm.
Work queues, kernel threads, and the like seem fundamentally wrong to me. We just dealt with a dead lock condition in the USB Gadget driver last week. Still struggling to understand what is causing spurious interrupts on the MMC driver in this 2.6.15 Linux Kernel we are running on an ARM platform. Odd think is that it's fine in debug mode, just happens in non-debug. Murphy's law certainly applies here. This whole Initrd business is just messy also.
But it's not all griping about Linux, I just set up a New 1TB FreeBSD 6.3 based server. Somehow I feel like that project has taken a turn for the worst. As much as I didn't really care much for Jordan Hubbard, he did manage to do a good job of things overall.
I thought I'd try some new tricks on the box, since it's in a CoLo some 500 miles from home it's a little hard to operate, and rebooting and moving cables or pressing F1 at boot time is just not going to happen.
So I installed Xvnc, very cool thing, usually I'd just open X-terms across the net to work, or more lately tunnel Xterms over ssh, ssh -R 6001:127.0.0.1:6000 sokol@192.168.1.116 http://x.unixprogram.com/ Someday I will make a real site out of that.
Then I bring up olvwm and Firefox. Now overall this is very cool, since I can leave all my Xterms open and connect using VNC and my whole desktop is right where I left it even though I changes locations and computers, even screen resolutions.
My gripe is FireFox on FreeBSD is just 1/2 operations compared to where it's at on Linux.
Or maybe I should say the FireFox is fine, but lacking operational plug-ins.
I just haven't been able to get Java and Flash, or Acrobat working right, in Ubuntu this is a no brainer. In addition Firefox is spewing a stream of error messages at the console that I opened it with. I am not a happy camper, that's for sure.
Now overall I swear by firefox, and the fact that none of these companies or Firefox itself is really paying much attention to FreeBSD is disturbing, maybe even a lack of diplomacy that used to exist under Jordans participation. Mozilla used to do a good job with FreeBSD support including most plugins. Maybe I Need to turn on Linux Support in the BSD kernel and run all linux binaries. Yuck.
On another note. I have found it interesting at the response I get from Linux people. I find I can still run circles around most of them even being someone out of place in the Linux Kernel, but already I have my name in the 2.6.17 kernel and later on the ViVi driver. I have done about half a dozen driver since then. And having had come from a Pre-threaded kernel world, I can do much better jobs at driver interrupts and getting things to work better for real time stuff.
Oh there is also some really interesting TCP/IP socket call stuff I came across to, specifically how long a process spends doing a "write" or "Send" call. It's very different then I had expected. and Both FreeBSD and Linux exhibited similar behavior. This was that even Non-blocking calls can take a very long time to write. Something on the order of 200+ uS. Didn't seems to matter if it was blocking or non-blocking either. And it took even longer with Nagel disabled!.
Blocking was only fast if the socket was really going to block, then the non-blocking would return in 1uS or less even!
200 Micro Seconds, heck that a long time. What the hell is the kernel doing for that time, and it seems to be burning up CPU that whole time no less. I alway just assumed it would take that buffer and put it in some queue and return immediately.
Anyhow that for was 100 to 1000 bytes sends at 1 second intervals.
When I started sending data full out at 10Mbps or higher, this delay for the write calls dropped down to 2ouS or less even. How is that for odd. the more data I send the faster the send call gets! Exactly opposite of what I would have expected.
