During normal operation, the LCD on an F7xx displays each second a number, which I believe to be the number of NFS operations in the last second, followed by a row of 0 to 10 splodges --- at any rate, I have never seen more than 10.
The hardware installation guide refers to this as "a bar graph" but doesn't go into details. What is actually being measured here? The number of splodges is correlated with the number, but not very strongly, and the number has a far larger dynamic range.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
At 08:45 PM 10/13/00 +0100, Chris Thompson wrote:
During normal operation, the LCD on an F7xx displays each second a number, which I believe to be the number of NFS operations in the last second, followed by a row of 0 to 10 splodges --- at any rate, I have never seen more than 10.
The hardware installation guide refers to this as "a bar graph" but doesn't go into details. What is actually being measured here? The number of splodges is correlated with the number, but not very strongly, and the number has a far larger dynamic range.
After staring at that thing and wondering myself, it looks to me as if it is sort of a sliding rate-of-change meter.
When there is a big surge in #/Ops over a short period of time, bar jumps up a lot. Ditto for a big decrease in ops, shaving the bar.
However, I've seen the bar nearly pegged with a relatively small number of ops (say, 400 or so) and hanging around 50% when the machine in question was pushing as many as I ever have seen it push.
In general, I think the main purpose is to have Cool Blinky Lights.
-j
During normal operation, the LCD on an F7xx displays each second a number, which I believe to be the number of NFS operations in the last second, followed by a row of 0 to 10 splodges --- at any rate, I have never seen more than 10.
The LCD is 16 characters wide, and 5 digits of number, a space, and 10 blobs is 16 characters. (I guess we'll have to fix the code if we build a machine that can get the number above 99999.)
The hardware installation guide refers to this as "a bar graph" but doesn't go into details. What is actually being measured here? The number of splodges is correlated with the number, but not very strongly, and the number has a far larger dynamic range.
The bar graph scale varies over time to adapt to the load on the machine; see below.
After staring at that thing and wondering myself, it looks to me as if it is sort of a sliding rate-of-change meter.
When there is a big surge in #/Ops over a short period of time, bar jumps up a lot. Ditto for a big decrease in ops, shaving the bar.
The bar graph represents the ops/second on filers and, depending on the release, URLs/second or MBytes/second on NetCache boxes.
I.e., it's a bar graph of the number displayed on the line above it...
However, I've seen the bar nearly pegged with a relatively small number of ops (say, 400 or so) and hanging around 50% when the machine in question was pushing as many as I ever have seen it push.
However, the *scale* of the bar graph varies over time, so that if the machine is under low load, you don't have the bar graph pegged at "no blobs", and if it's under high load, you don't have it pegged at "all blobs", if the load is varying significantly.
The bar graph is scaled based on a maximum value, where:
the maximum value starts out at 100;
if the number to be displayed is greater than the max ops value, or if 5 seconds have passed since we last recomputed the max ops value, we compute the max ops value as the number to be displayed rounded up to a multiple of 100.
The "if the number to be displayed is greater than the max ops value" is to keep it from pegging at the right-hand edge under high load if the load is varying enough.
The "if 5 seconds have passed" is to keep it from pegging at the left-hand edge under low load, *and* to keep it from constantly bouncing back and forth if the load varies quickly between high and low.
In general, I think the main purpose is to have Cool Blinky Lights.
I see you have discovered the true secret of the bar graph.
- Guy "I just wish that, when I put the LCD support into ONTAP for 3.0, I'd put in the feature I'd wanted to put in, where it randomly puts, on occasion, 'Buy More Filers' into the LCD for a fraction of a second" Harris
On Fri, 13 Oct 2000, Guy Harris wrote:
The LCD is 16 characters wide, and 5 digits of number, a space, and 10 blobs is 16 characters. (I guess we'll have to fix the code if we build a machine that can get the number above 99999.)
Naw, just switch to kilounits above, say, 75000 (and switch back if it falls below 50000, to avoid rapid flipping between units and kilounits around the transition). Better yet, upgrade to a higher- resolution LCD display capable of displaying 40x6 or 20x3 in a larger font, and bitmapped graphics. Throw in a programmable display command set callable via the JVM... ooooooh, the possibilities! :)
taob@risc.org wrote:
Throw in a programmable display command set callable via the JVM... ooooooh, the possibilities! :)
This brings up the question: What can you do with the Java interpreter accessible from the rc_toggle_basic mode without risking breaking anything? For instance, for those too cheap to buy SnapMirror, would it be possible to set up some el-cheapo DIY filer-to-filer replication using the JVMs in two filers, instead of relying on NFS clients to do the copying?
--tml
Excellent idea. You could assign two spare drives for left and right -- pull the drive to start turning, push it back in to stop, the system monitors scsi bus events -- and then push the reset button to fire.
On Mon, Oct 16, 2000 at 12:19:32PM -0700, Guy Harris wrote:
Better yet, upgrade to a higher- resolution LCD display capable of displaying 40x6 or 20x3 in a larger font, and bitmapped graphics. Throw in a programmable display command set callable via the JVM... ooooooh, the possibilities! :)
Quake.
I also think the netapps need a soundcard - just because the cool blinkey light show you get with test_lcd lasts exactly as long as one playthrough of the hamsterdance.com song.
A match made in heaven ...
Hal Siegel _---_ / Senior Systems Engineer(ing) YY()))))\ /| Texas Microprocessor Division (@@) )))))/ Advanced Micro Devices /_/__/__/ hal@beast.amd.com mm mm
Hal Siegel wrote:
I also think the netapps need a soundcard - just because the cool blinkey light show you get with test_lcd lasts exactly as long as one playthrough of the hamsterdance.com song.
ISTR reading somewhere, I think it was the cockroft book [1] about setting up your web server to effectively "echo 1 > /dev/audio" every time it had a hit. Why not have a speaker that blips for every operation per second that it does. I can imagine some quite interesting tunes being played.[2]
[1] If you run solaris boxes and you care about performance you really should read it. ISBN: 0130952494 [2] There are some wonderful tunes out there played by people on old computers with AM radios with each note being formed by executing a number of instructions.
soundcard, video on the LCD, better add a few more protocols (IRC?), and, by the way, an onboard DVD reader to boot with.
I still haven't decided if they REALLY need a rdfile command.
--
Louis
On Mon, 16 Oct 2000, Louis Brune wrote:
I still haven't decided if they REALLY need a rdfile command.
Though rdfile and wrfile are sufficient to change files on disk, such as etc/rc, "edfile" would be really, really nice.
Now would the "ed" part be: ed, vi, emacs, etc. Oh, look at the worms spilling out of this can...
Until next time...
The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
My understanding is that the ops isn't just NFS ops - it's NFS + CIFS ops, and maybe even NFS + CIFS + HTTP + FTP (?) ops.
And the 10 splodges isn't related to ops at all; it's the CPU usage, 0 to 100%.
At least, that's what I thought. I'm not sure either.
Bruce
My understanding is that the ops isn't just NFS ops - it's NFS + CIFS ops, and maybe even NFS + CIFS + HTTP + FTP (?) ops.
It's NFS ops plus SMB ops plus HTTP ops on filers, and megabits/second (not megabytes/second, as per my previous mail) on NetCache boxes. (It was URLs/second until the streaming code went in, at which point URLs/second ceased to be adequate to describe the load).
And the 10 splodges isn't related to ops at all; it's the CPU usage, 0 to 100%.
Nope, it's just a bar graph of the number displayed to the left of the bar graph.
The Activity light does represent CPU usage - it's off if in the last fraction of a second (I'd have to dig through the code some more to see what the fraction is, as it's been ages since I first put that code into the system) the CPU was idle (running only the idle process), and on if during the last fraction of a second it wasn't idle.
--On Friday, October 13, 2000 7:04 PM -0700 Guy Harris guy@netapp.com wrote:
And the 10 splodges isn't related to ops at all; it's the CPU usage, 0 to 100%.
Nope, it's just a bar graph of the number displayed to the left of the bar graph.
And what is the scale? Ten splodges equals how many ops? It looks to me more like some sort of autoscaling based on a rolling average, as I have seen the bar graph shoot off to the right during slack times when the number is relatively low compared to its rated max ops/sec.
Frank
-- Frank Smith fsmith@hoovers.com Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501