Seems the Google Chrome dev 11.0.686.1 is out with a fix for an HTML5 issue about playing videos on Vimeo.com. I guess they had to plug it into their Flash player or something. It's sad they dropped the embedded video tag, but they did, and I'm guessing this is collateral damage. So they quickly pushed out an update that fixes this issue. No surprise there.
This morning I noticed that Google Chrome dev 11.0.686.0 was out and with it a few really nice features: the V8 engine is now 3.1.6.1, and the accelerated compositing is on by default. They also fixed some bugs in the Mac code related to the new infobar. In all, a nice upgrade and I'm hoping to see a little bit of that faster rendering, but we'll have to wait and see.
Now that I have good results with the UDP-based delivery protocol, I thought I'd take the time to go back and see if the master branch of ZeroMQ at GitHub was working yet. The problem I've been having in the past is that there were some significant changes in ZeroMQ post-2.1.0 release that broke the OpenPGM protocols. I've been working with the maintainers to try and fix these things, but the best I can do is test as I haven't dug into the code and unraveled all the changes they made.
Last time I checked, it was still broken, and then I started on the UDP-based transport and haven't looked back - until now. It's pretty easy:
$ git pull $ ./autogen.sh $ ./configure --with-pgm $ make clean $ make
and then in src/.libs I have all the libraries I need. I simply put them into the LD_LIBRARY_PATH before the installed libraries and I'm in business.
I'm very pleased to say that as of this morning, it's working again! Yup, working like a champ. I'm not positive what all the changes include, but they are significant, and possibly much needed. There's still the issue of everything being so "hidden" in ZeroMQ, but that's nothing new. It is, however, a downside when we have a competing transport that we can use that's not so heavily encapsulated.
Still... I haven't made the UDP transport reliable, and I know that's needed. So the question will be, what's the effect of swapping out the UDP-based transport with the latest ZeroMQ transport? I'll have to wait until everyone is happy with the UDP-based transport, and then swap back in the ZeroMQ one and see the difference.
If I had to bet, I'd say the difference will be minimal. I believe all the problems were really mine. Humbling to admit, but I believe it's the case.
This morning I noticed that a significant new upgrade had been made to WordPress to bring it up to version 3.1 - so I had to go to HostMonster and upgrade my installs. Since my last upgrade, SimpleScripts has adopted the "update all at once" idea for multiple installs of the same piece of software. I haven't had any problems with SimpleScripts to date, but I didn't want to start this morning. Still... I knew they made backups, so I went ahead and upgraded them all at once.
Worked out just fine.
The new WordPress has a menu bar at the top of the page when you're logged into the site. It's not bad, but it's not the same style as the blog, and I'm sure it's only a matter of time before the artists get things going and make that, too, in-sync with the theme of the site.
I spent a few minutes looking over the new features - some are nice, others have a few bugs in them, but I'm sure will get worked out with the release. In all, it's a nice improvement, and while I really just use this for my journal, it's nice to know it's got the room and capabilities to be much more.
It really breaks my heart to see problems with ZeroMQ that aren't being addressed. For instance, I've been trying to work with the guys on IRC about the fact that the GitHub master doesn't receive messages when using OpenPGM. I've talked to the guys on IRC about this, and it seems that some of the more recent changes really messed this up, and there were no checks on the code to make sure it was still working. Sad, but true.
I've tried several times to jump-start this several times, but I didn't get very far on any occasion. This makes it hard to use, as I can't use it without OpenPGM, but I'd like to get some of the newer features they are talking about.
But that's not the worst.
I think ZeroMQ is either delaying, re-ordering, or retrying with excessive delay, some of my messages - and it's only when I'm really hammering the data rate. For example, I know that the ZeroMQ send() method is asynchronous. So it buffers up the data and then sends it. But what if it gets messed up?
The delivery seems to get worse and worse as the day goes on, and it seems to be based on a zmq::socket_r getting into a "bad state" and never getting itself out. I believe that it's in the receiver, because two apps on the same box have different reception profiles after a time.
In any case, I can't trust it and I can't build the latest code. It's just no longer a really workable solution. I have to find some kind of solution that doesn't include ZeroMQ.
This morning I noticed that Google Chrome dev 11.0.672.2 was out and with it quite a few changes. While the major version number doesn't mean a great deal, in my experience, the additions of the new V8 engine as well as a few nice Mac specific features makes this nice to have. I'm sure there's more to it than just this, but this is enough.
This morning I got an error that looked like this:
*** glibc detected *** tpClient: double free or
corruption (fasttop): 0x0...b0 ***
and after a bit of googling, it appears that this problem is in the C++ runtime checking on the calls to free(). It seems that the default behavior is to check the argument to free() to see if it's a double-free. Sounds nice, in theory, but if we're hammering the system, it seems like this might not be a good thing to do.
Thankfully, the solution is easy - don't check. To turn it off, simply say:
export MALLOC_CHECK_=0
and the checks will not be done. Good enough for me. I'm still going to try out the TPMalloc from google, but that's a previous post. Still don't have it built for x86_64 yet.
This morning I was looking into the problem with my ticker plant clients and the older kernel shipping with CentOS 5. Basically, when I increased the message rate, we crossed over some threshold on CentOS and we started getting a lot of heap corruptions manifesting themselves as malloc() or free() problems in ZeroMQ. On Ubuntu 10.04.1 everything was fine, most likely because the kernel in Ubuntu 10.04.1 was significantly newer than the one in CentOS 5. So I went on a search for a better malloc() and free().
What I came across was the google-perftools. This is pretty amazing stuff. It's a thread-cache replacement for malloc() and free() that is as simple as adding a -ltcmalloc to the build line. It's got profiling tools as well, but that's not what interests me as much, it's the amazing speed gains that it provides. The graphs on the paper how about a 4x increase in operations per second when using this.
It's not conceptually hard - the TCMalloc library grabs a large block of memory from the system and then offers it up to the application. This puts the calls in user space, and the control of memory there as well. Because their design has the smaller blocks held in the thread, it's possible to see no locking contention on the malloc() and free() which should be a major boon to me.
I have to get it built by the Unix Admins for Ubuntu 10.04.1 - I've already built the x86_64 RPMs for CentOS 5 and installed them on a test box I have access to, but I really want to start on the Ubuntu boxes. Simple change, should see major improvement. Very exciting.
UPDATE: it's built on all my boxes and ready to go for tomorrow. I'm excited about the possibilities.
This morning I saw that Google Chrome dev 10.0.648.82 was out with a stability release update. It's worded a little strangely, but then again, these guys re engineers not english majors, so you have to cut them a little slack now and again.
Nice to see the improvements. It's getting better and better.
I had a few development boxes restaged from CentOS 5 to Ubuntu 10.04.1 as The Shop is moving away from CentOS and to Ubuntu. As it turns out, the code I've been working on has pointed out a bug in the kernel that ships with CentOS 5 related to a lot of very fast malloc and free cycles. But that's not the point. On Ubuntu, I wanted to get the bitmapped font Misc Fixed Semicondensed, and by default, it's not allowed.
But that's only the default. Here's how to enable it.
The key is to remove the font config rule that says "no bitmapped fonts". To do this, we simply:
$ sudo rm /etc/fonts/conf.d/70-no-bitmaps.conf
this was a link to /etc/fonts/conf.avail/70-no-bitmaps.conf anyway, so it's not like anything was really "lost". Then we need to re-run the font config to pick up this change:
$ sudo dpkg-reconfigure fontconfig
Now you should have bitmapped fonts for Vim. Excellent.