linux-kernel - Re: [KORG] Re: kernel.org lies about latest -mm kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070109080115.d7314b7a.khali@linux-fr.org>
Date:	Tue, 9 Jan 2007 08:01:15 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	"J.H." <warthog9@...nel.org>
Cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Andrew Morton <akpm@...l.org>, Pavel Machek <pavel@....cz>,
	kernel list <linux-kernel@...r.kernel.org>, hpa@...or.com,
	webmaster@...nel.org
Subject: Re: [KORG] Re: kernel.org lies about latest -mm kernel

Hi JH,

On Mon, 08 Jan 2007 13:33:04 -0800, J.H. wrote:
> On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
> > * Drop the bandwidth graphs. Most visitors certainly do not care, and
> > their presence generates traffic on all web servers regardless of the
> > one the visitor is using, as each graph is generated by the respective
> > server. If you really like these graphs, just move them to a separate
> > page for people who want to watch them. As far as I am concerned, I
> > find them rather confusing and uninformative - from a quick look you
> > just can't tell if the servers are loaded or not, you have to look at
> > the numbers, so what's the point of drawing a graph...
> 
> While I agree that most users don't care, they are useful.  If someone

So moving them to a separate page would make sense.

> notices that 1 has an incredibly high load and moving lots of traffic in
> comparison to 2, than they can manually redirect to 2 for better &
> faster service on their own.  Since these images aren't particularly big

Unfortunately the images actually fail to present this information to
the visitor clearly. One problem is the time range displayed. 17
minutes is either too much (hardly better than an instant value, but
harder to read) or not enough (you can't really see the trend.) With
stats on the last 24 hours, people could see the daily usage curve and
schedule their rsyncs at times of lesser load, for example, if they see
a daily pattern in the load.

Another problem is the fact that the vertical scales are dynamically
chosen, and thus different between both servers, making it impossible to
quickly compare the bandwidth usage. If the bandwidth usage on both
servers is stable, both images will look the same, even though one
server might be overloaded and the other one underused. The user also
can't compare from one visit to the next, the graphs look essentially
the same each time, regardless of the actual bandwidth use. So, if you
really want people to use these graphs to take decsions and help
balancing the load better, you have to use fixed scales.

I also notice that the graphs show primarily the bandwidth, while what
seems to matter is the server load.

> they cache just fine and it's not that big of a deal, and there are much
> longer poles in the tent right now.

The images are being regenerated every other minute or so, so I doubt
they can actually be cached.

-- 
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/