Marcus, You suggest "You might be thinking of ways to defeat these grocery store queues", but I'm actually looking for ways to help people recognize when their systems are running into terminal congestion. Terminal congestion strongly appears to be what we're doing to the resources of the earth by continuing to increase investment in increasingly scattered, smaller and diminishing pools of opportunity that result in greater side effects.
There are a lot of people working on the world resource & global warming conflicts and sustaining our increasingly threatened ecological systems. They're mostly still quite comfortable believing in our marvelous talent for inventing increasingly complicated solutions for increasingly complicated problems. They're not discussing at all where that's headed though, as if micro-managing nature was something we knew how to do without question. If you look at it straight, though, our increasingly complicated solutions are consistently producing bigger crises than they solve, with no 'hump' in sight for the mounting complexity to get over with an extra push of effort. That's because the symptom is a one directional progression from freedom to diminishing returns to erupting complexity to conflict, in just about everything people do, all at once. We're not reading it as a change in our environment though. You suggest that when a computer buss is congested it has a self-protection mechanism that has the authority to put off users requests indefinitely. That's sort of a central control mechanism for dealing with independent users that were not smart enough to share the limited resource on their own. If the independent users were to learn enough about each other's needs they might learn ways to cooperate and make better use of the limited shared resource. For example, they might save up low priority tasks for off peak times, and so both avoid arbitrary central control and improve the overall efficiency of the bus as resource. I guess the question is, does anyone have a term for the limit of that, the limit of creative collaboration between independent users sharing a limited resource? I'd call that the "edge of chaos" if I didn't know someone else had already used that for something rather different... It's the natural line you cross where independent users exhaust their ability to use a limited resource cooperatively, that triggers either central control or conflict. Anything come to mind? Phil > > Phil Henshaw wrote: > > So a bus, in functional terms, is a 'resource' that never runs into > limits > > of the kind where users are forced to learn about each other's > complex needs > > in order to figure our how to get the last little drop of capacity > out? > > That is, leaving aside the transformational 'synergy' of having > everyone in > > line fall in love and forget about their shopping... among the other > kinds > > of choices I had in mind. :-) > > > A bus is a potential bottleneck. Typically a bus runs a slower rate > than a processor. Similarly the things connected to the bus and the > memory are also slower. So there's a fast resource that can be > divided > up in a more sensible way. Imagine a super-fast Mighty Mouse clerk, > that runs from station to station, operating a hundred times the speed > of a typical customer,. Such a clerk could soak up all of the latency > introduced by the users of the customer and various sorts of > exceptional > conditions. That's basically analogous to massive hyperthreading on a > computer. > > You might be thinking of ways to defeat these grocery store queues. > For example, what happens when 10 customers come along each with 50 > Costco flatbed carts and block all of the lines (supposing there are 10 > lines)? Then everyone else has to wait. That can be fixed if the > clerks can quickly push off all of a customer's purchases to the side > and start a new checkout on their register. That 's what > virtualization software/hardware does, or at a higher level, or > system-level checkpointing. In these everyday cases, I can't see how > it makes any sense to model other users. The system architecture > should be able to cope. > > Anyway, the latter is an example where there can be the perception > there > is a limited resource, but really there is not. Users may not be able > to make good use of peak speed anyway, e.g. having Mighty Mouse as > their > individual clerk. > > Marcus > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
