As an example, the daily fluctuations in CPU utilization of hundreds of thousands of individual machines could be tracked and charted 24/7 to determine a baseline from which abnormalities and patterns could be extracted. The possibilities are enormous.
And, just to make it more fun, the metrics they collect will be the ones the developers needed, not the ones you need to manage the system. Or, worse, the ones that are easiest to measure.
That isn't to say that you won't be able to do some interesting statistical analyses, just that the data you really want will be buried in cubic yards of noise, or not measured at all. And when you ask for them, you'll be told that you should use what you have.
Alas, prefetching is a research area in computer science: I've done a number of
experiments in that space, and (1) an ill-timed prefetch can eject a needed cache line, and (2) the benefit is quite small even if you set the prefetches by hand.
That leaves you with the previous state,
twiddling your thumbs for many many
instructions while the cache fills.
Thus the emphasis on either doing useful work in the meantime or speeding up the cache fill.
And write behind can delay while you evict a cache line to make room (;-))
It's probably fair to say that hardware
threads are really just a zero-instruction-count way to
do a context switch. This matters
when you only get 5-9 instructions on the average between a fetch, store or branch.
Even a single-instruction-time context switch would cost you 1/5 to 1/9 of your time (20% down to 11%). That's a brutal overhead, and something to avoid.
And they're shipping 2- and 4-socket boards in the T5240 and T5440 machines.
What you really want is the speed of
the Power, the parallelization of the T5000s and the "scout threads" of the Rock (;-))
Er, in a business context, "synergy" in the merger of two companies means "large numbers of people in administration, sales and marketing we can lay off".
Sun started out as a BSD-based company,
and had to pay through the nose for Bell 32V licenses to be able to sell their products. They've always liked the
BSD license and its derivitives, even though they've used the GPL on occasion.
Are there any specific products that Sun sells that IBM doesn't have equivalents of?
Sure, seriously multi-threaded chips,
something I'm surprised IBM hasn't
already adopted: after all, they have the same mismatch between sloth-like memory and fast CPUs.
We're just seeing what the graphics folks would call "one more time around the wheel of karma": a prototype of something new
is done in software, implemented in proprietary hardware for speed, and soon afterwards the next generation of main CPUs catches up to the point where it can be done in software once more, usually with some small amount of custom silicon on the interface board.
Boy, break into a low-margin area,
one with
45% to as low as 10% gross margins,
from a 60% area of the industry.
I think one should probably do the opposite, with low-wattage ARM Linux chips running routing software. After all, the
ARPAnet started with custom NIMs because only they were fast enough, but later went to cheap Unix boxes for cost reasons. Now one should be able to
do some pretty fast routing with modern processors, and make the same move for exactly the same reasons.
which is the normal V6-era algorithm
for atomic update, exactly as per Dwyer's CACM article.
The opportunity for an undefined result would then be a crash between the first write and either the update
or the rename.
That there is such a large time
during which the consistency of the filesystem is at risk seems even less
understandable with this algorithm.
Surely the metadata updates can be
ordered first and then the whole
sequence deferred, so that the risk
is between the data and metadatas writes of a consolidated set of I/Os.
It's ok to have some pretty huge delays, if and only if you delay the metadata update from the (atomic) rename as well as the write. Doing the metadata change and then delaying the write opens a huge window for a
crash to render the filesystem inconsistent.
The delay should be sufficient
to allow all the operations to be
topologically sorted into an order
which both preserves correctness and
allows the data to be written in
a single pass of the elevator.
Research over ten years ago
showed the necessary and sufficient time to vary with the
size of the commit cache, and
to be otherwise on the order of
seconds. If I understand
correctly, ZFS uses 5 seconds.
Non-journaled filesystems had that
behavior, and could become internally inconsisent. So we created journaled ones, so that one wouldn't have to
suffer that behavior except in cases which break the guarantees of that filesystem.
The debate is really about the proper
guarantees on metadata and data write, deep in the filesystem, specifically the updating of the metadata before the
data, as Mr. Tso pointed out.
An engineer would minimize the time
between the two writes, even if the two
were delayed for an arbitrary period: it's the time between the first data write and the metadata write which is the period in which a crash would destroy data, not the
time before the first write.
The sequence the guis appear to be
using is the traditional one
open existing file
read contents
seek to beginning
write new contents
close
Therefor a traditional filesystem would, in
step 4, write the data blocks,
change the length in the inode
and release any unused blocks if
the file was much smaller. The
opportunity for an undefined result
would be a crash between the first write and the length update. This
appears to be what ext3 is doing,
and what I (and v6) have done in the past.
A nontraditional filesystem could
improve on this by writing new blocks
and then a new inode, then
atomically linking the new inode in to
the directory block. And yes, such filesystems exist (;-))
Er, actually it removes the previous
data, then waits to replace it for long
enough that the probability of noticing
the disappearance approaches unity on flaky hardware (;-))
It seems exceedingly odd that issuing
a write for a non-zero-sized file and having it
delayed causes the file to become zero-size before the new data is written.
Generally when one is trying to maintain correctness one allocates space, places the data into it and only then links the space into place (paraphrased from from
Barry Dwyer's "One more time - how to
update a master file", Communications of the ACM, January 1981).
I'd be inclined to delay the metadata update until after the data was written, as Mr. Tso notes was done in ext3. That's certainly what I did back in the days of CP/M, writing DSA-formated floppies (;-))
Fire departments they don't bill you for responding to a fire at your home or business. Schools again socialized, yes you pay taxes, but the government provides the schools, the teachers, the school itself, athletic fields, etc. Not convinced, what about all the the rural electric companies owned by local and regional governments.
These three services were actually privately provided at first: Benjamin Franklin started a commercial fire company, schools were restrictively private in the old British "public school" system copied by the American colonies, and power companies were often private enterprises in my father's day,
even up here in Soviet Canuckistan (;-))
None of them stayed private: the competition between fire companies caused widespread public revulsion,
as did the restriction of schooling to
only the upper class in egalitarian America, and power companies didn't scale. One died because they were seen as immoral, the second as a conscious choice of the voting (and school-bond-buying) public and the third from technical reasons.
The Tragedy of the Commons is a perfect example of what happens when everyone or no one owns a resource.
Just to be anal, no real village commons
suffers from the cited problems, as
the community is self-protective and small enough that the violator of the norms gets enough flack that he backs off. The
paper is about what happens if you try to create what Hardin considers an unnatural commons, one of unrestricted size and without I usually call "societal norms", which he terms "mutual coercion, mutually agreed upon".
Publishers? Don't you mean one specific
bookstore chain, who's doing the classic
"let's leverage our way towards a monopoly" schtick?
The publishers left in the world
already know the value of making
books available free electronically
and retaining the right to print them.
I'm proud to say that O'Reilly started
this with the first edition of my "Using Samba". Other, smaller, imprints like Baen are following suit.
And isn't it this same bookstore that's
leaning on their supplier to use one particular print-on-demand service?
A desktop workstation or fast laptop
is optimal for a developer or fairly heavy user, but in a business context requires
buying the darn things
an imaging server, to create/update them
a backup and/or synchronization server (samba, unison and a tape changer).
Etc, etc.
However, many users don't actually need any more than a cheap diskless netbook or
a glorified X-terminal, and can do all
their computing on a back-end timesharing server.
As in "The Unix Timesharing System"
that we grew up with, which was
always orders of magnitude more cost-effective than
individual shared-nothing workstations.
A classic tactic in self-serving prosecutions is to charge a person with rape, pillage, robbery and illegal parking. Then, when the defendant is found guilty of illegal parking, the prosecutor can announce conviction, with most listeners thinking that the defendant was convicted of all the charges.
Slashdot Mirror
As an example, the daily fluctuations in CPU utilization of hundreds of thousands of individual machines could be tracked and charted 24/7 to determine a baseline from which abnormalities and patterns could be extracted. The possibilities are enormous.
And, just to make it more fun, the metrics they collect will be the ones the developers needed, not the ones you need to manage the system. Or, worse, the ones that are easiest to measure.
That isn't to say that you won't be able to do some interesting statistical analyses, just that the data you really want will be buried in cubic yards of noise, or not measured at all. And when you ask for them, you'll be told that you should use what you have.
--dave
Whoops, my apologies! We were talking about prefetch and branch prediction, and I referred to an experiment, which I didn't describe.
I've written a short description of it in my journal, at http://slashdot.org/~davecb/journal/226021
--dave
And write behind can delay while you evict a cache line to make room (;-))
--dave
It's probably fair to say that hardware threads are really just a zero-instruction-count way to do a context switch. This matters when you only get 5-9 instructions on the average between a fetch, store or branch. Even a single-instruction-time context switch would cost you 1/5 to 1/9 of your time (20% down to 11%). That's a brutal overhead, and something to avoid.
And they're shipping 2- and 4-socket boards in the T5240 and T5440 machines.
What you really want is the speed of the Power, the parallelization of the T5000s and the "scout threads" of the Rock (;-))
--dave
Er, in a business context, "synergy" in the merger of two companies means "large numbers of people in administration, sales and marketing we can lay off".
--dave
Sun started out as a BSD-based company, and had to pay through the nose for Bell 32V licenses to be able to sell their products. They've always liked the BSD license and its derivitives, even though they've used the GPL on occasion.
--dave
Are there any specific products that Sun sells that IBM doesn't have equivalents of?
Sure, seriously multi-threaded chips, something I'm surprised IBM hasn't already adopted: after all, they have the same mismatch between sloth-like memory and fast CPUs.
--dave
We're just seeing what the graphics folks would call "one more time around the wheel of karma": a prototype of something new is done in software, implemented in proprietary hardware for speed, and soon afterwards the next generation of main CPUs catches up to the point where it can be done in software once more, usually with some small amount of custom silicon on the interface board.
--dave
Boy, break into a low-margin area, one with 45% to as low as 10% gross margins, from a 60% area of the industry.
I think one should probably do the opposite, with low-wattage ARM Linux chips running routing software. After all, the ARPAnet started with custom NIMs because only they were fast enough, but later went to cheap Unix boxes for cost reasons. Now one should be able to do some pretty fast routing with modern processors, and make the same move for exactly the same reasons.
--dave
Actually I understood what was happening, but I found it exceedingly odd that it escaped from the lab (;-))
--dave
Yes, thanks!
The relevant sequence seems to be
which is the normal V6-era algorithm for atomic update, exactly as per Dwyer's CACM article.
The opportunity for an undefined result would then be a crash between the first write and either the update or the rename.
That there is such a large time during which the consistency of the filesystem is at risk seems even less understandable with this algorithm.
Surely the metadata updates can be ordered first and then the whole sequence deferred, so that the risk is between the data and metadatas writes of a consolidated set of I/Os.
--dave
It's ok to have some pretty huge delays, if and only if you delay the metadata update from the (atomic) rename as well as the write. Doing the metadata change and then delaying the write opens a huge window for a crash to render the filesystem inconsistent.
The delay should be sufficient to allow all the operations to be topologically sorted into an order which both preserves correctness and allows the data to be written in a single pass of the elevator.
Research over ten years ago showed the necessary and sufficient time to vary with the size of the commit cache, and to be otherwise on the order of seconds. If I understand correctly, ZFS uses 5 seconds.
--dave
Non-journaled filesystems had that behavior, and could become internally inconsisent. So we created journaled ones, so that one wouldn't have to suffer that behavior except in cases which break the guarantees of that filesystem. The debate is really about the proper guarantees on metadata and data write, deep in the filesystem, specifically the updating of the metadata before the data, as Mr. Tso pointed out.
--dave
POSIX is the minimum standard one must achieve to be called unix-like. In general, one wants to do better that that in Linux (;-))
--dave
An engineer would minimize the time between the two writes, even if the two were delayed for an arbitrary period: it's the time between the first data write and the metadata write which is the period in which a crash would destroy data, not the time before the first write.
--dave
The sequence the guis appear to be using is the traditional one
Therefor a traditional filesystem would, in step 4, write the data blocks, change the length in the inode and release any unused blocks if the file was much smaller. The opportunity for an undefined result would be a crash between the first write and the length update. This appears to be what ext3 is doing, and what I (and v6) have done in the past.
A nontraditional filesystem could improve on this by writing new blocks and then a new inode, then atomically linking the new inode in to the directory block. And yes, such filesystems exist (;-))
--dave
Er, actually it removes the previous data, then waits to replace it for long enough that the probability of noticing the disappearance approaches unity on flaky hardware (;-))
--dave
It seems exceedingly odd that issuing a write for a non-zero-sized file and having it delayed causes the file to become zero-size before the new data is written.
Generally when one is trying to maintain correctness one allocates space, places the data into it and only then links the space into place (paraphrased from from Barry Dwyer's "One more time - how to update a master file", Communications of the ACM, January 1981).
I'd be inclined to delay the metadata update until after the data was written, as Mr. Tso notes was done in ext3. That's certainly what I did back in the days of CP/M, writing DSA-formated floppies (;-))
--dave
Fire departments they don't bill you for responding to a fire at your home or business. Schools again socialized, yes you pay taxes, but the government provides the schools, the teachers, the school itself, athletic fields, etc. Not convinced, what about all the the rural electric companies owned by local and regional governments.
These three services were actually privately provided at first: Benjamin Franklin started a commercial fire company, schools were restrictively private in the old British "public school" system copied by the American colonies, and power companies were often private enterprises in my father's day, even up here in Soviet Canuckistan (;-))
None of them stayed private: the competition between fire companies caused widespread public revulsion, as did the restriction of schooling to only the upper class in egalitarian America, and power companies didn't scale. One died because they were seen as immoral, the second as a conscious choice of the voting (and school-bond-buying) public and the third from technical reasons.
--dave
Just to be anal, no real village commons suffers from the cited problems, as the community is self-protective and small enough that the violator of the norms gets enough flack that he backs off. The paper is about what happens if you try to create what Hardin considers an unnatural commons, one of unrestricted size and without I usually call "societal norms", which he terms "mutual coercion, mutually agreed upon".
See Hardin, Garrett The Tragedy of the Commons.
--dave
Publishers? Don't you mean one specific bookstore chain, who's doing the classic "let's leverage our way towards a monopoly" schtick?
The publishers left in the world already know the value of making books available free electronically and retaining the right to print them. I'm proud to say that O'Reilly started this with the first edition of my "Using Samba". Other, smaller, imprints like Baen are following suit.
And isn't it this same bookstore that's leaning on their supplier to use one particular print-on-demand service?
--dave
Resource management was pretty horrid in those days: users had to do it themselves with "nice". And they usually weren't (;-))
These days, Linux is a hotbed of resource management research and one of it's biggest supporters, IBM, has done some impressive work on zOS.
--dave
No utopia, just an improvement.
A desktop workstation or fast laptop is optimal for a developer or fairly heavy user, but in a business context requires
However, many users don't actually need any more than a cheap diskless netbook or a glorified X-terminal, and can do all their computing on a back-end timesharing server.
As in "The Unix Timesharing System" that we grew up with, which was always orders of magnitude more cost-effective than individual shared-nothing workstations.
--dave
Cool! I like that
--dave
A classic tactic in self-serving prosecutions is to charge a person with rape, pillage, robbery and illegal parking. Then, when the defendant is found guilty of illegal parking, the prosecutor can announce conviction, with most listeners thinking that the defendant was convicted of all the charges.
--dave