Proprietary v open source software: more on removable features

Here's the third in a series of four short pieces by the IPKat's friend Keith Braithwaite (read the prologues to pieces one and two for the background) on the delicate balance between proprietary and open source models for the development and adoption of computer software.

More on Removable Features

Prologue


Last time we looked at the hidden downsides, for users, of spurning patented technology.
Now we return to the question of removing patented technology from existing products. This time we will look at a very low-level technology, buried deep inside the operating system, but which has a big impact on users’ experiences.

Despite its origins as a means of publishing scientific papers the web has become a rich visual medium. Almost every webpage has many graphical elements and graphics files tend to be large, particularly the high-resolution, rich colour images that we have become used to. Viewing this sort of content would be a much less satisfying experience without the application of two technologies from the proprietary world.

Zero-copy I/O

Many applications spend much of their time copying large chunks of data from one place in memory to another. For example, a web server delivering a page has to first retrieve the content from disk which involves copying it from a disk i/o buffer into the application’s memory space. The content is then copied into the buffer of a network socket to transmit it to the web browser. But doing that copies the content yet again to a network card buffer ready for serialisation on to the network itself.

An alternative is to copy the data into memory once and then pass around the system a “pointer” (or reference) to that data. The pointer is very small and requires much less effort to handle. Imagine the difference between sending a colleague a reference to a book in a note versus sending them the whole book. This is called (somewhat misleadingly) “Zero-Copy I/O”
The Apache 2 web server, for example, has a configuration option which means that when handling a request for a file requires no access to the data within a file – such as when delivering a file to a web browser as a download – Apache delivers the file contents without ever reading the file. But this is only possible if the operating system upon which Apache is running supports this feature.

The advantages can be significant. Sun Microsystems published a benchmark (showing measurements taken using ftp servers with a 1MB file) showing an improvement of 40% in the throughput and 20% less CPU utilization in servers that use Zero-Copy I/O. Removal of this functionality would make an impact on both users and operators of the server:
• The end user will perceive poor performance while using the resources of the server;
• The server owner will have to expend more to support the same number of users.
“Latency matters. Amazon found every 100ms of latency cost them 1% in sales. Google found an extra 0.5 seconds in search page generation time caused traffic to drop by 20% . A broker could lose $4 million in revenues per millisecond if his electronic trading platform is 5 milliseconds behind the competition.”

Data from IBM show how using a traditional approach instead of Zero-Copy I/O can almost triple the response time of an example application serving static files of various sizes . Such a slowdown could have a very serious impact on sales from a retail website – or drive away users to a faster competitor.

Even in your day-to-day work, you are probably benefiting from Zero-Copy I/O without being aware of it. Every time you request a large file – be it a photo, a software download, an audio track or a hospital x-ray – Zero-Copy I/O saves anything from seconds to minutes of your valuable time.

Zero-Copy I/O is becoming more widespread and the introduction of that technology into a range of products is being managed well. Let’s look at an older example of a key technology being mismanaged.

Image compression

Ever since the first NCSA Mosaic browser let webpages contain images, the Graphics Interchange Format (GIF) had been used as the standard encoding for simple pictures such as icons and page backgrounds. The authors of web servers and browsers thought little about this until 1994, when the owner of the intellectual property in the GIF standard, Compuserve, sought to collect royalties from companies incorporating that technology in their products. How could this have happened?

Computer manufacturer Sperry patented the Lempel-Ziv-Welch compression algorithm (LZW) in 1986. Unfortunately, LZW was published in a computer journal without reference to the fact that Sperry held a patent on it.

Not long after this Compuserve needed an efficient graphics representation for distributing images to their (pre-web) users and saw LZW as an ideal way to compress the graphics content of images. The resulting technology, GIF, was used widely by Compuserve users to share images. When the web arrived it seemed only natural to use GIF there, too. Sperry, merging with Burroughs to form Unisys, forgot that it owned the LZW patent until 1994. Unisys belatedly felt that it was obliged to assert its rights by demanding royalties from users of LZW – including the vendors of software that encoded or decoded GIF images, which included web server and browser makers.

Unisys quickly came to an agreement with Compuserve, letting it continue using LZW in the GIF format. Initially, both Compuserve and Unisys insisted that they only wanted to charge vendors of commercial software that employed the GIF algorithms. However, they soon had to retract this guideline because vendors started distributing the GIF support module as a “free add-on” to their commercial packages. Soon, only genuinely charitable organizations were able to avoid the payment of at least $0.10 per copy of any software that encoded GIFs.

Despite handing free licences to hundreds of non-profit organizations, schools, governments and so on, Unisys continued to generate only negative publicity. Anyone using a content management system or website authoring tool, or even an image editing application, was either deprived of the facility to use the web’s most popular image format and/or ran the risk of being found liable for infringing Unisys’s patent.

The worldwide patents on LZW expired in 2006. By then the GIF controversy had led directly to the formulation in 1995 of a new image encoding standard called Portable Network Graphics (PNG). However, PNG is still not fully established, largely due to the initial unwillingness of the leading browser vendors to invest in supporting it – even when it became an official standard of the WorldWide Web Consortium. Most webmasters continued to use GIFs, even though they were covered by patents, rather than lose readers.

Next article

My fourth and final article, which will wrap up the whole series with a summary, will look at the proposition that product designers don’t need to use proprietary technology because no real progress has been made in many areas for several decades. The conclusions may surprise you.

Proprietary v open source software: more on removable features Proprietary v open source software: more on removable features Reviewed by Jeremy on Tuesday, May 18, 2010 Rating: 5

6 comments:

  1. are you referring to this?

    (WO/2007/019316) ZERO-COPY NETWORK I/O FOR VIRTUAL HOSTS

    ReplyDelete
  2. "However, PNG is still not fully established, largely due to the initial unwillingness of the leading browser vendors to invest in supporting it"

    Did you mean: "Microsoft", singular? More specifically did you mean versions of IE prior to IE7?

    Did you hear about "browser wars?" I understand it attracted a little legal activity at the time.

    Have you noticed current browser market shares?

    http://news.bbc.co.uk/1/hi/technology/10095730.stm

    http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0


    And PNG support?

    http://www.statowl.com/web_standards_png_alpha_support.php

    ReplyDelete
  3. Hi Gentoo,
    Since we're being snarky, have you been inside a large corporate recently?

    Of course, you are right: this article has, shall we say, had time to mature since it was written. As of today (19 May 2010) there is no technical reason for anyone to use a browser that does not support PNG.

    Personally, I've never owned a mchine that would run any version of IE out-of-the box, so that's never been a problem for me...except...a lot of people spend most of their browser-facing time in front of a desktop machine running some ancient version of Windows, and over which they have no control. I work with some folks in a corporate right now who aren't even using the most up-to-date version of IE 6. The browser war might as well not have happened for them.

    Since you mention IE7, it came out in 2006. PNG was approved as a standard ten years before that. How did the browser market share look during that 10 year period?

    ReplyDelete
  4. "Most webmasters continued to use GIFs, even though they were covered by patents, rather than lose readers."

    Most of the web content creators/providers I talked to at the time were not actually afraid of losing readership, but simply couldn't be bothered to go to the effort of switching to PNG in the face of what they perceived as a very minor risk. Remember the format was designed at a time when colour rendering on screen didn't require chips to handle accelerated graphics, and bandwidth management was still of major importance. This importance, and the dependence on low spec hardware, have been eroded with the explosion in developments of hardware during the 90's and the general increase in bandwidth that followed the expansion of the internet into our daily lives. It is however, one very clear example of the active enforcement of patented software technology causing a direct development of an alternative, open and freely accessible one.

    ReplyDelete
  5. The real issue with the first point is that the use of pointers is obvious if not anticipated from computer and software architectures developed in the 60's, when saving time and memory was an issue that people really cared about. If in doubt consult the Manchester University computer science group where there are stacks of detailed theses on early computer architecture.

    The second is resolved through acquiescence/antitrust.

    Personally I don't see the problem here.

    ReplyDelete
  6. The GIF mess must surely be the greatest mutual IPR disaster in history.

    On the proprietor side it sure says something about a company that it had forgotten about the patent, and I am being charitable here and not implicate it was a thin excuse to slip out of passivity/estoppel/laches troubles. Following up with a land mark disaster in licensing really takes the cake. I thought it was well established that one should consider the case very carefully before going after end users. Embedded market, like cell phones and media players, seem like a more fruitful approach. And "bad publicity" must be the understatement of the month.

    The software community did not impress me either. Calling it the GIF patent actively confused the issue when only the compression was the issue. I do remember a proposal to replace the LZW with alternative compression (gzip?) but that was shot down, possibly as lacking in autistic qualities, as the burn all gifs movement gathered steam (or froth if you wish).

    The PNG was a disaster in itself too: at a time when animated GIFs were all the rage it did not help that PNGs were static, and the promise of alpha blending was insufficient compensation. Animation was moved over to the MNG project. Now: when was the last time you encountered a MNG? I cannot say I have been overrun by them lately.

    Then an animated PNG called APNG was brought into the Netscape browser to create the Throbber, demonstrating the possibilities. The PNG community did not accept it, some voters stated "it also abuses the PNG spec". The desire for prefection left end users without a working alternative to what they wanted.

    ReplyDelete

All comments must be moderated by a member of the IPKat team before they appear on the blog. Comments will not be allowed if the contravene the IPKat policy that readers' comments should not be obscene or defamatory; they should not consist of ad hominem attacks on members of the blog team or other comment-posters and they should make a constructive contribution to the discussion of the post on which they purport to comment.

It is also the IPKat policy that comments should not be made completely anonymously, and users should use a consistent name or pseudonym (which should not itself be defamatory or obscene, or that of another real person), either in the "identity" field, or at the beginning of the comment. Current practice is to, however, allow a limited number of comments that contravene this policy, provided that the comment has a high degree of relevance and the comment chain does not become too difficult to follow.

Learn more here: http://ipkitten.blogspot.com/p/want-to-complain.html

Powered by Blogger.