Package: raggle Version: 0.4.2-1 Severity: normal I run raggle inside screen inside aterm. When I use 'n' to go to the next entry, the "Description" window doesn't get replaced completely: when a line in the new description is shorter than the corresponding line in the previous description, the new display contains a leftover string from the previous description, which makes it hard to read the new display. Forcing a redraw through ctrl-L doesn't help.
Raggle should update the complete display on 'n', e.g. by filling out lines with spaces. Here's an illustration, produced using the attached feed. l Description qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk xLinux: LKML Upgrade x xLink: http://kerneltrap.org/node/5541 x xDate: Wed, 10 Aug 2005 05:05:19 -0700 x x x xThe server that handles the Linux Kernel Mailing x xList[1] [archive[2]] recently got an upgrade. Matti x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj In the next item, the last line is one character shorter than this one's last line, and the "i" from "Matti" is still there on 'n': l Description qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk xLinux: Git Homepage x xLink: http://kerneltrap.org/node/5533 x xDate: Mon, 08 Aug 2005 06:51:31 -0700 x x x xPetr Baudis announced the creation of a homepage x xfor git[1], the directory content manager used to i x <- mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj ^ | In the following entry, both lines are shorter than above, so there are two leftovers: "page" (from "homepage") and "d to i" ("d to " from "used to " and "i" from Matti"). 1111 vvvv l Description qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk xLinux: Weekly Status Summaries x xLink: http://kerneltrap.org/node/5528 x xDate: Fri, 05 Aug 2005 10:33:21 -0700 x x x x2.6 Linux kernel maintainer Andrew Morton [epage x <- 1 xinterview[1]] posted his first kernel status d to i x <- 2 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj ^^^^^^ |||||| 222222 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (750, 'experimental'), (500, 'testing-proposed-updates'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.12.4 Locale: LANG=C, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1) Versions of packages raggle depends on: ii elinks [www-browser] 0.10.4-7 advanced text-mode WWW browser ii epiphany-browser [www-bro 1.6.4-1 Intuitive GNOME web browser ii irb 1.8.2-1 Interactive Ruby (irb) ii libncurses-ruby1.8 0.9.2-3 ruby Extension for the ncurses C l pn librexml-ruby1.8 <none> (no description available) ii libruby1.8 [libyaml-ruby1 1.8.2-9 Libraries necessary to run Ruby 1. ii links2 [www-browser] 2.1pre16-2 Web browser running in both graphi ii lynx-ssl [www-browser] 1:2.8.4.1b-3.1 Text-mode WWW Browser supporting S ii mozilla-browser [www-brow 2:1.7.10-1 The Mozilla Internet application s ii mozilla-firefox [www-brow 1.0.6-2 lightweight web browser based on M ii ruby 1.8.2-1 An interpreter of object-oriented ii w3m [www-browser] 0.5.1-4 WWW browsable pager with excellent raggle recommends no packages. -- no debconf information -- Obsig: developing a new sig
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE rss [<!ENTITY % HTMLlat1 PUBLIC "-//W3C//ENTITIES Latin 1 for XHTML//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent";>]> <rss version="0.92" xml:base="http://kerneltrap.org";> <channel> <title>KernelTrap - Your source for current kernel news</title> <link>http://kerneltrap.org</link> <description>KernelTrap is a web community devoted to sharing the latest in kernel development news.</description> <language>en-local</language> <item> <title>Linux: SATA Status</title> <link>http://kerneltrap.org/node/5549</link> <description><p>Jeff Garzik noted that he has updated the Serial ATA Linux software <a href="http://linux.yyz.us/sata/software-status.html">status report</a>, "<i>things in SATA-land have been moving along recently</i>". The status report notes that, "<i>the 'ATA host state machine', the core of the entire driver, is considered production-stable.</i>" The libATA driver uses the kernel's SCSI layer, and causes each SATA port to appear as a new SCSI bus. A programmer's guide to libata [<a href="http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/libata.pdf"; target="new">pdf</a>] further explains, "<i>libATA is a library used inside the Linux kernel to support ATA host controllers and devices. libATA provides an ATA driver API, class transports for ATA and ATAPI devices, and SCSIATA translations for ATA devices according to the T10 SAT specification [<a href="http://www.t10.org/ftp/t10/document.04/04-174r3.pdf"; target="new">pdf</a>].</i>" The latest patches for the 2.4 and 2.6 kernels can be found <a href="http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/">here</a>.</p> <p>Regarding PATA, or Parallel ATA (IDE), Jeff also posted a ten item todo list. The software status webpage notes, "<i>libata will be gaining full support for PATA, including older chipsets and devices with buggy/problematic designs. PATA will be fully supported, as will SATA. Currently, libata PATA drivers only exist for Intel PIIX and a few Promise chipsets.</i>"</p> </description> <pubDate>Fri, 12 Aug 2005 06:26:42 -0700</pubDate> </item> <item> <title>Linux: LKML Upgrade</title> <link>http://kerneltrap.org/node/5541</link> <description><p>The server that handles the <a href="http://www.tux.org/lkml/"; target="new">Linux Kernel Mailing List</a> [<a href="http://kerneltrap.org/mailarchive/1/overview/thread">archive</a>] recently got an upgrade. Matti Aarnio explains, "<i>folks at Dell have donated a new machine to be VGER, and folks at RedHat have installed it into [a] co-location facility with [a] 1000Mbps network connection into the machine.</i>" The upgrade offers much more performance for handling the extremely high-traffic mailing list.</p> <p>The Linux Kernel Mailing List is usually referred to as the lkml. It evolved many years ago from the "Linux Activist" and other <a href="ftp://tsx-11.mit.edu/pub/linux/mail-archive/"; target="new">early Linux mailing lists</a> run in Finland. Eventually the early mailing lists were replaced by the <a href="http://www.greatcircle.com/majordomo/"; target="new">Majordomo</a> powered lkml, managed by David Miller at Rutgers University on a server called "vger". When David went to work at RedHat, the server and mailing list went with him. To this day, it continues to be housed at RedHat. Even though it has a kernel.org domain name, it is not actually part of the Linux Kernel Archives [<a href="http://kerneltrap.org/node/5070">story</a>] or their infrastructure. Instead, it's included in the kernel.org domain due to its function as the primary Linux development mailing list.</p> </description> <pubDate>Wed, 10 Aug 2005 05:05:19 -0700</pubDate> </item> <item> <title>Linux: Git Homepage</title> <link>http://kerneltrap.org/node/5533</link> <description><p>Petr Baudis announced the creation of a <a href="http://git.or.cz/"; target="new">homepage for git</a>, the directory content manager used to manage the Linux kernel. Git was originally written by Linus Torvalds in early April of 2005 [<a href="http://kerneltrap.org/node/4982">story</a>], and is now maintained by Junio Hamano [<a href="http://kerneltrap.org/node/5496">story</a>]. Other online resources available for the tool include a <a href="http://www.kernel.org/git/?p=git/git.git;a=blob;f=Documentation/tutorial.txt">tutorial</a> that walks through the process of setting up and using git, a <a href="http://www.kernel.org/pub/software/scm/git/docs/">man page</a>, and the <a href="http://www.kernel.org/git/">gitweb interface</a> providing easy browsing of the many kernel trees managed by git. The new webpage explains:</p> <blockquote><p>"GIT falls into the category of distributed source code management tools, similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every GIT working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access to a central server."</p></blockquote> </description> <pubDate>Mon, 08 Aug 2005 06:51:31 -0700</pubDate> </item> <item> <title>Linux: Weekly Status Summaries</title> <link>http://kerneltrap.org/node/5528</link> <description><p>2.6 Linux kernel maintainer Andrew Morton [<a href="http://kerneltrap.org/node/10">interview</a>] posted his first kernel status report, dated August 4'th, 2005. He explained, "<i>at [the] kernel summit I pledged to put out weekly where-we're-at summaries, mainly so that subsystem maintainers could get an estimate of when the next major kernel release will be, so they can plan their merge windows.</i>" The merge windows he referred to were explained earlier by Linux creator Linus Torvalds as part of the improved development process [<a href="http://kerneltrap.org/node/5500">story</a>] in which major changes will only be merged into the mainline kernel during the first two weeks after a major release.</p> <p>Andrew added that he doesn't know precisely when the next major release will occur, "<i>the timing is driven by perception-of-stability</i>". He did estimate, however, that the 2.6.13 kernel will be released sometime between August 12'th and August 19'th. He then went on to list 60 bugs being tracked in <a href="http://bugzilla.kernel.org/"; target="new">bugzilla</a> that he currently considers "<i>real</i>" and "<i>worth attending to</i>", causing him to state, "<i>they're almost all post-2.6.12 regressions. Longer-term we simply have to do better than this, else we'll stabilise at a pretty buggy level.</i>" Finally he summarized, "<i>no matter what process changes we make, the bottom line is that developers/maintainers will need to spend more of their time working with reporters on fixing bugs.</i>"</p> </description> <pubDate>Fri, 05 Aug 2005 10:33:21 -0700</pubDate> </item> <item> <title>Linux: Removing Older GCC Support</title> <link>http://kerneltrap.org/node/5527</link> <description><p>Adrian Bunk posted a patch to the <a href="http://tux.org/lkml/">lkml</a> to remove support for older versions of the <a href="http://gcc.gnu.org/"; target="new">Gnu Compiler Collection</a>. With his patch, versions of gcc prior to 3.2 [<a href="http://kerneltrap.org/node/380">story</a>] would no longer be able to compile the kernel. He offers two advantages, "<i>reducing the number of supported gcc versions from 8 to 4 allows the removal of several #ifdef's and workarounds</i>", and "<i>my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time</i>". He further explains, "<i>my personal opinion about the time and space a compilation requires is that this is no longer that much of a problem for modern hardware, and in the worst case you can compile the kernels for older machines on more recent machines.</i>"</p> <p>Public reactions to the proposition were entirely negative. David Miller explained that, "<i>many people still use [gcc] 2.95 because it's still the fastest way to get a kernel build done and that's important for many people.</i>" Dave Airlie noted that some Linux kernel ports such as <a href="http://linux-vax.sourceforge.net/">Linux on VAX</a> don't even compile with the newer versions of the compiler. Others added that even if the kernel does compile with the latest gcc releases, they hit strange runtime errors not hit when compiling with an older version of gcc. It is apparent from this thread that support for at least gcc 2.95 is very unlikely to go away any time soon.</p> </description> <pubDate>Thu, 04 Aug 2005 06:26:29 -0700</pubDate> </item> <item> <title>Linux: Tracking the -mm Kernel</title> <link>http://kerneltrap.org/node/5514</link> <description><p>Active 2.6 development happens in Andrew Morton [<a href="http://kerneltrap.org/node/view/10">interview</a>]'s -mm tree [<a href="http://kerneltrap.org/node/875">story</a>], where cutting edge patches are first merged for testing and stabilization before hopefully eventually making it into Linus' mainline 2.6 tree. A recent thread discussed the difficulty in tracking the -mm kernel, understanding what patches are in what releases, and what patches have made it into the mainline kernel. Andrew agreed, "<i>it's hard. -mm is always in flux.</i>" He also noted that he recently stoped sending out 'patch was dropped' messages when patches were merged into Linus' tree, as this was causing too much confusion, "<i>I got lots of 'waah, why did you drop my patch' from people whose patches had been merged by Linus.</i>"</p> <p>One way to track the -mm kernel is by subscribing to the <a href="http://vger.kernel.org/vger-lists.html#mm-commits"; target="new">mm-commits mailing list</a>. Andrew points out that this can easily be done by typing, "<i><code>echo subscribe mm-commits | mail majordomo &lt;at&gt; vger.kernel.org</code></i>". Additionally, Andrew recently began offering regular <a href="ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/"; target="new">"broken-out" tarballs</a>, a collection of all *.patch files that comprise the current -mm kernel.</p> </description> <pubDate>Mon, 01 Aug 2005 08:59:58 -0700</pubDate> </item> <item> <title>Linux: 2.6.13-rc4, Improved Development Process</title> <link>http://kerneltrap.org/node/5500</link> <description><p>Back from the <a href="http://lwn.net/Articles/KernelSummit2005/"; target="new">2005 Linux Kernel Developers' Summit</a>, Linus Torvalds released the 2.6.13-rc4 kernel. Linus noted that the <a href="http://lwn.net/Articles/144281/"; target="new">improved development process</a> discussed at the recent summit will begin after the upcoming release of the 2.6.13 kernel, "<i>which is hopefully not too far away.</i>" The general idea of the new process, which improves upon last year's development model [<a href="http://kerneltrap.org/node/3513">story</a>], is to require that all major merges happen within two weeks of a stable kernel release. All the rest of the time between releases should then be spent on fixing bugs. Linus summarized:</p> <blockquote><p>"So if you have a favourite kernel developer, please wake him up with a friendly kick to the head and explain this concept to him in small easy-to-understand words, and tell him that we're in the freeze process for 2.6.13 now, and that he should be gathering up the patches, and make sure they get to me _after_ 2.6.13 is out, but at that point do it in a timely manner."</p></blockquote> </description> <pubDate>Fri, 29 Jul 2005 06:15:35 -0700</pubDate> </item> <item> <title>Linux: Junio Hamano New Git Maintainer</title> <link>http://kerneltrap.org/node/5496</link> <description><p>The git directory content manager was born in early April of 2005 [<a href="http://kerneltrap.org/node/4982">story</a>], less than a week after the announcement that BitKeeper would no longer be available free of charge to kernel developers [<a href="http://kerneltrap.org/node/4966">story</a>]. The tool was originally written by Linux creator Linus Torvalds, and rapidly evolved with the help of an active developer community which Linus repeatedly noted he hoped would eventually take over [<a href="http://kerneltrap.org/node/5091">story</a>]. A scant two months after development on the tool began, the 2.6.12 kernel was released, managed by git [<a href="http://kerneltrap.org/node/5308">story</a>].</p> <p>Now, Linus has announced that Junio Hamano is the new git maintainer. "<i>I always said I didn't really want to maintain it in the long run,</i>" Linus explained, "<i>and maybe some of you thought I was just saying that, especially as the weeks dragged out to over three months, but hey, that's just because this thing ended up being a bit bigger and more professional than I originally even envisioned.</i>" He went on to note that Junio was the obvious choice, and that this change means he will be able to return his full focus to the <a href="http://www.tux.org/lkml/">Linux Kernel mailing list</a>.</p> <p>Junio thanked those involved, described his development methods, and discussed the upcoming 1.0 release. Regarding 1.0, he suggested that all features are in, and that he is primarily looking for bugfixes and documentation updates. Following the announcement, Ryan Anderson posted an updated "Git 1.0 Synopis", a brief overview of the tool and its features. His document begins, "<i>Git, sometimes called 'global information tracker', is a 'directory content manager'. Git has been designed to handle absolutely massive projects with speed and efficiency, and the release of the 2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it does this task well.</i>"</p> </description> <pubDate>Thu, 28 Jul 2005 07:25:54 -0700</pubDate> </item> <item> <title>Linux: Entire 2.6 Source Tree Imported Into Git</title> <link>http://kerneltrap.org/node/5486</link> <description><p>Linux creator Linus Torvalds announced that he has succesfully imported the <a href="http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=summary"; target="new">entire 2.6 Linux kernel development tree</a> into git [<a href="http://kerneltrap.org/node/4982">story</a>], his once interim now likely permanent replacement for BitKeeper [<a href="http://kerneltrap.org/node/4966">story</a>]. He points out that the source history was imported from the bkcvs tree, "<i>of course, this _is_ the cvs import, which means that it's basically just a straight-line linearization of the real BK history, but it's a pretty good linearization and so it's certainly useful.</i>" He goes on to note that the tree is his current "best effort", using the <a href="http://kerneltrap.org/mailarchive/15/message/76700/thread">cvsimport functionality</a> that was added to git in early June, "<i>and obviously I'll re-create it if there _are_ cvsps or cvsimport bugs that cause the import to have problems</i>".</p> <p>Linus also pointed out that the archive is "<i>pretty aggressively</i>" compressed, weighing in at only 166 MB compared to an uncompressed size of around 2.4 GB. He notes that a single 2.6.12-rc2 kernel tree without any history compressed with "gzip -9" is by itself 45 MB in size, so the complete 2.6 kernel history compressed and stored in git is only 3.6 times larger than a single compressed release. The import took around 16 hours, "<i>most of it appears to have been due to CVS being slow, the git parts were quick</i>". Going forward, Linus notes that he eventually plans to import the entire 2.4 kernel tree into git as well, "<i>but I was more interested in the 2.6.x tree (for obvious reasons), and before I do the 2.4.x one I'd like to give that tree some time for people to check if the conversion was ok.</i>"</p> </description> <pubDate>Tue, 26 Jul 2005 18:15:56 -0700</pubDate> </item> <item> <title>Linux: tty Cleanup</title> <link>http://kerneltrap.org/node/5473</link> <description><p>Alan Cox [<a href="http://kerneltrap.org/node/view/9">interview</a>] discussed his current efforts on improving the tty layer, "<i>at the moment tty buffers are attached directly to the tty. This is causing a lot of the problems related to tty layer locking, also problems at high speed and also with bursty data (such as occurs in virtualised environments)</i>". The current implementation includes what are called "flip buffers", a per device buffer for data received from tty devices.</p> <p>Alan describes his current effort, "<i>I'm working on ripping out the flip buffers and replacing them with a pool of dynamically allocated buffers. This allows both for old style 'byte I/O' devices and also helps virtualisation and smart devices where large blocks of data suddenely materialise and need storing.</i>" He goes on to detail his new API for working with the dynamically allocated buffers, then notes, "<i>I've converted a fair number of drivers to this API ready and I'll post some patches for review soon.</i>"</p> </description> <pubDate>Fri, 22 Jul 2005 06:45:46 -0700</pubDate> </item> <item> <title>Linux: Realtime Benchmarking</title> <link>http://kerneltrap.org/node/5466</link> <description><p>Con Kolivas [<a href="http://kerneltrap.org/node/465">interview</a>] used the latest version of <a href="http://interbench.kolivas.org/"; target="new">Interbench</a>, his interactivity benchmarking tool [<a href="http://kerneltrap.org/node/5415">story</a>], to compare latencies between the plain 2.6.12 kernel, the 2.6.12 kernel with kernel preemption enabled, the plan 2.6.10 kernel, and the 2.6.10 kernel with the PREEMPT_RT realtime preemption option enabled.</p> <p>Regarding plain kernel preemption, Con offered the following summary, "<i>with these workloads, on this hardware, running these real time simulations there is not a convincing argument for CONFIG-PREEMPT. Note that running interbench with the non-real time benchmarks also does not show a convincing reason for preempt.</i>" Conversely, the PREEMPT_RT test revealed a noticeable change, about which Con concluded, "<i>interestingly the average latencies are slightly higher (in the miniscule &lt;2us range), but the maximum latencies are excellently bound to 25us.</i>" Read on to see the actual test results.</p> </description> <pubDate>Thu, 21 Jul 2005 06:43:32 -0700</pubDate> </item> <item> <title>Linux: Performance Testing The Kernel</title> <link>http://kerneltrap.org/node/5438</link> <description><p>Kenneth Chen <a href="http://kerneltrap.org/mailarchive/1/message/94078/thread">announced</a> the <a href="http://kernel-perf.sourceforge.net/"; target="new">Linux Kernel Performance Project</a>, "<i>we decided to run a large set of benchmarks covering core components of the Linux kernel (virtual memory management, I/O subsystem, process scheduler, file system, network, device driver, etc) on a regular basis.</i>" Results from 13 benchmark utilities are displayed in both table and graph format, run on several different servers. The 2.6.9 kernel [<a href="http://kerneltrap.org/node/4026">story</a>] is used as the baseline, compared against various more recent kernels up to 2.6.13-rc1. Ken explains:</p> <blockquote><p>"Our goal is to work with the Linux community to further enhance the performance of the Linux kernel. The data available on the site allows community members to closely track performance gains and losses with every version of the kernel. Ultimately, we hope that this data will result in performance increases in Linux kernel development."</p></blockquote> </description> <pubDate>Fri, 15 Jul 2005 05:35:40 -0700</pubDate> </item> <item> <title>Linux: Debating Hertz</title> <link>http://kerneltrap.org/node/5430</link> <description><p>The decision to change the default hertz in the 2.6 Linux kernel from 1000 to 250 [<a href="http://kerneltrap.org/node/5411">story</a>] continued to be discussed, until Linux creator Linus Torvalds finally had enough, "<i>get on with your lives. Realize that there is no 'perfect' value for HZ. 250 right now is somewhere reasonable, and for the extreme ends you can always choose your own.</i>" He also dismissed concern over picking an ideal number that minimizes long-term time drift, "<i>long-term time drift is something that we inevitably have to use things like NTP to handle, if you want an exact clock.</i>" Instead, he highlighted tasks that affect the short term, such as converting timevals into jiffies, "<i>in short-term things, the timeval/jiffie conversion is likely to be _bigger_ issue than the crystal frequency conversion. So we should aim for a HZ value that makes it easy to convert to and from the standard user-space interface formats. 100Hz, 250Hz and 1000Hz are all good values for that reason. 864 is not.</i>"</p> <p>Looking forward, he proposed a better solution, "<i>btw, if somebody really gets excited about all this, let me say (once again) what I think might be an acceptable situation.</i>" He noted, "<i>I don't think we want a _highfrequency_ timer, I want a _lower_ frequency mode.</i>" He described raising the default hertz all the way up to 2000, "<i>or something that we decide is the upper limit of sanity. We then have some timer logic entity that notices that nothing is going to care for the next 100 ticks, so we go into 'slow mode', and reprogram the timer to tick at a frequency of 100Hz, but when it does tick, we just count it as 20.</i>" He went on to explain that this hides the 'variable frequency' from everything else, "<i>the timer tick is 2kHz as far as everybody is concerned. It's just that the ticks sometimes come in 'bunches of 20'.</i>"</p> </description> <pubDate>Thu, 14 Jul 2005 06:27:02 -0700</pubDate> </item> <item> <title>GNU/Hurd: System V Shared Memory Implemented</title> <link>http://kerneltrap.org/node/5428</link> <description><p>Some weeks after Neal Walfield [<a href="http://kerneltrap.org/node/5">interview</a>] implemented POSIX semaphores for libpthread [<a href="http://kerneltrap.org/node/5165">story</a>], <a href="http://portal.wikinerds.org/brinkmann-interview-mar2005"; target="new">Marcus Brinkmann</a> has now <a href="http://lists.gnu.org/archive/html/bug-hurd/2005-07/msg00060.html">implemented</a> SysV shared memory for the <a href="http://www.gnu.org/software/hurd/hurd.html"; target="new">GNU Hurd</a> in glibc, based on some earlier work done by Neal. This was probably the last commonly used POSIX feature missing in the Hurd, and having shared memory available will make several programs work much better. Success has already been reported with mplayer; it was very cludgy before and works smoothly with shared memory enabled.</p> </description> <pubDate>Wed, 13 Jul 2005 06:36:38 -0700</pubDate> </item> <item> <title>Linux: Interbench, An Interactivity Benchmark</title> <link>http://kerneltrap.org/node/5415</link> <description><p>Con Kolivas [<a href="http://kerneltrap.org/node/view/465">interview</a>], a doctor specializing in anaesthesia, has released a new benchmark application called <a href="http://interbench.kolivas.org/"; target="new">Interbench</a>, designed to benchmark "interactivity". Con's earlier benchmark, <a href="http://contest.kolivas.org/"; target="new">Contest</a>, was designed to measure responsiveness. In his release announcement, he begins, "<i>there has been a lot of talk about what makes up a nice feeling desktop under linux. It comes down to two different but intimately related parameters which are not well defined.</i>" He goes on to explain that the two parameters are "responsiveness" and "interactivity". The former he defines as, "<i>the rate at which your workloads can proceed under different load conditions.</i>" The latter he defines as, "<i>the scheduling latency and jitter present in tasks where the user would notice a palpable deterioration under different load conditions.</i>" He continues, "<i>responsiveness would allow you to continue using your machine without too much interruption to your work, whereas interactivity would allow you to play audio or video without any dropouts, or drag a gui window across the screen and have it render smoothly across the screen without jerks.</i>"</p> <p>The new benchmarking tool emulates various cpu scheduling behaviors of interactive tasks, measuring latency and jitter. Con goes on to describe how the new tool can be used, noting, "<i>in response to critisicm of difficulty in setting up my previous benchmark, contest, I've made this as simple as possible.</i>" He also provides some sample benchmark results, comparing the plain 2.6.13-rc1 kernel to one patched with his own <a href="http://kernel.kolivas.org/"; target="new">-ck patchset</a>. In his conclusion, he notes, "<i>this was quite some time in the making... I realise there's so much more that could be done trying to simulate the interactive tasks and the loads, but this is a start, it's quite standardised and the results are reproducible.</i>"</p> </description> <pubDate>Tue, 12 Jul 2005 05:09:26 -0700</pubDate> </item> </channel> </rss>
