For our New Year's party I used a wireless laptop that nfs-mounted a big mp3 collection from a server and used xmms with a playlist generated with grave. Most of the tunes were encoded at 256K. Looking at network traffic, the wireless channel would be quiet for 4 seconds, then the player would move 50 packets in the 5th second, then quiet for 4 more seconds, and so on. Interesting pattern that illustrates nfs read-ahead.
The Sonos device is different in several respects. The main ones are the gui/controls, the mesh network, and audio quality. I met the Sonos people last year and they are audio geeks. My tunes would sound much better on their box than my laptop. They have time synch and streaming in their network whereas the nfs hack has nothing of the kind and depends on readahead bandwidth. The control system speaks for itself. My family could easily use it whereas I have to be present to get the nfs hack setup (and debugged if needed).
There are rarely new ideas in computer architecture. This may be an update of a transputer-like thing with better communications and core cpu. The real questions that need answering are about the memory model (distributed?) and comm model (warmed over message-passing?). Chances are it contains nothing new or radical and is likely just a cluster component on a chip. Prepare to be disappointed.
SGI has had 512 and 1024-cpu MIPS-based systems in operation for more than 5 years. Much work was done on the Irix systems to initialize large parallel computations and provide libraries and compiler support for these configurations. One technique is to provide message-passing libraries that use shared memory. A better technique is to morph (slightly) parallel mesh apps so that each computational mesh node exposes the array elements to be shared with neighbors. No message-passing needed - you push data after a big iteration and then use the (really fast) sync primitives to launch into the next iteration. With shared-nothing clusters (i.e. Beowulf) a computation (and its memory) must be partitioned among the compute nodes. The improvement over a "classical" cluster can be startling especially with computations that are more communications-bound than compute-bound. This means there is no value for replacing a render farm with a big system. But there are big compute problems, e.g. finite element, for which the shared-nothing cluster is often inadequate.
With a single memory image system the computation can easily repartition dynamically as the computation proceeds. Its very costly (never say impossible!) to do this on a cluster because you have to physically move memory segments from one machine to another. On the NUMA system you just change a pointer. The hardware is good enough that you don't really have to worry about memory latency.
And let's not forget io. Folks seem to forget that you can dump any interesting section of the computation to/from the file system with a single io command. On these systems the io bandwidth is limited only by the number of parallel disk channels - a system like the one mentioned in the article can probably sustain a large number of GBytes/sec to the file system.
Let's not forget page size. The only way you can traverse a few TB of memory without TLB-faulting to death is to have multi-MByte-size pages (because TLB size is limited). SGI allowed a process to map regions of main memory with different page sizes (upto 64 MB I think) at least 10 years ago in order to support large image data base and compute apps.
When I used to work at SGI (5 years ago) the memory bandwidth at one cpu node was about 800 MBytes/s. My understanding is that the Altix compute nodes now deliver 12 GBytes/s at each memory controller. Although I haven't had a chance to test drive one of these new systems, it sounds like they have gradually been porting well-seasoned Irix algorithms to Linux. It is unlikely that a commodity computer really needs all of this stuff, but I'm looking at a 4-cpu Opteron that could really use many of the memory management improvements.
I implemented this once as a special patch in Irix/XFS. It's not sufficient to do it just in the file system. The priority must be passed down to the devices. With Fibre Channel devices supporting a good-sized output queue, it is important to utilize the priority queuing supported by the disk channel vlsi chip. Unless there is device and driver support for priority queues, reordering the disk block queue at higher levels in the OS is usually not effective.
This kind of priority is best-suited for real-time processes that have real-time needs for disk access. The problem of keeping a big tarball unpacking operation from sucking up lots of space may be better solved by adding space constraints rather than having prioritized i/o.
The Mesh Networks Inc protocols are proprietary. They are a byproduct of military-funded tactical radio R&D. There is an emphasis onself-organizing topology and route discovery. If every soldier and vehicle is lugging a radio, then the network has a good chance of continuing to operate even if parts of it are destroyed.
This kind of mesh does have some pathology.Take some number, say 10, of nodes placed in a straight line. You are at one end of the line and the internet ISP is at the other end. And you have 10 wireless hops between you and the internet. And the people in the middle of the line may not be really happy with you either.
There are non-proprietary approches. Check out the ietf MANET working group at http://www.ietf.org.html.charters/manet-charte r.ht ml.
There are numerous university projects. Try Google(mesh network & university) or Google(mobile network & university).
There have been numerous failed startup company attempts at mesh networks. One approach that I found very appealing used a self-organizing mesh that organized itself into rooted tree structures. The internal tree branches served as backhaul connections to the internet. The leaves represent the clients/users. The internal nodes are not mobile. They are devices to be installed on utility poles or public access locations. They find one another and create an uplink/downlink infrastructure where uplink means a path to the ISP or other wired infrastructure and downlink means to the client. I liked this approach because it builds a predictible structure that can be analyzed and because the routing procedures within the internal nodes are a lot simpler than in the completely unconstrained mesh network.
The tree-like organization also seems to avoid another conceptual problem with the fully unconstrained network which is bandwidth sharing. If you are a client in a full mesh, your node must accept routing traffic from other nodes. Thus a goodish portion of your bandwidth and battery power may be consumed by traffic going through your client - but it's not your traffic.
I'd guess that most people would not want to act as a router and be draining power pretty much fulltime. Makes more sense to have a wireless self-organizing infrastructure that can provide bandwidth to clients that cruise within range.
There were a few misleading comments about power in earlier emails. Cell phones typical draw about 2 watts when transmitting. That exceeds the current capacity of the battery. They actually charge a capacitor from the battery between time slots and drain the capacitor during transmission. 802.11 devices have lower peak current drains, and they continue to get better. The most important technique in.11 power management is to put the radio in sleep mode (and run the sleep protocol with the AP). This has not been a competitive focal point, but vendors are starting to improve.
Next-generation.11 radios that are just starting to hit retail channels can operate on both the 11b and 11a bands and with both the 11b and a/g OFDM codecs. The prices for 11a nic cards is under $100 now (79?) and the a/b/g nic cards won't be far behind.
I think it is important to point out that 11b only has 3 channels to operate in. That doesn't give you much routing diversity when you need a lot of overlapping transmitters to create a useful (and thus redundant) mesh. But when you add 11a and can use the higher bandwidth ofdm codec in either the 11a bands or in the 11b bands (where they call it 11g), then you have more than a dozen channels that can be operating simultaneously. It seems obvious to me that this kind of channel diversity will be needed to successfully deploy a good mesh.
There were many comments about motives and costs, but I didn't see anyone make the obvious comment about bandwidth. That is, the bandwidth on a cable segment is shared on the channel. The cable companies are not in position to make more segments or open up more channels. I view bandwidth caps as a disguised way of dealing with system capacity issues without fixing the system. Someone I know once called this kind of situation a "success disaster". More customers for cable means the service gets worse, etc.
Similar article in today's NY Times citing the Intel publication. Their article highlights that no comparison is made to recent Pentium-Xeon performance improvements. The article also mentions AMD's Hammer and suggests directly that McKinley may not measure up to the hype when compared with other processors.
The article also mentions that Jack Dongarra - keeper of the Linpack-based 500 fastest computer systems - now shows an Itanium-based cluster at the top of the heap.
Unfortunately for programs that don't run out of the cache, there are three dimensions to computer system performance: processor, memory, and io. Intel marketing has successfully skewed the common perception to the detriment of a more balanced system viewpoint.
The Tiqit eightythree is similar in concept to the sony gizmo, but even smaller. It runs any X86 OS, has a cardbus slot, vga out, mike+audio plugs, 10G disk, etc. Screen might be smaller than the Sony, but is still very effective. Not in production yet, but may signify a trend. See www.tiqit.com.
I never have had the time to learn how to program a Palm. With one of these devices, I don't have to. For that reason alone, they're likely to be more useful... even though more costly at first Even so, the money I wasted on two Palms would probably bring one home.
11g is really 11a-style OFDM at 2.4 Ghz rather than the 5 Ghz band. There would be two (at least) 11g modes: a compatibility mode whereby OFDM packets and legacy 11b CCK packets coexist, and one which is "pure" OFDM at 2.4 Ghz.
The compatibility mode adds a huge overhead to each transmitted packet. An 11g transmitter in this mode must first complete a legacy 11b RTS/CTS operation on the air which, if successful, is followed by the actual packet. Even if the actual packet were transmitted at nearly infinite bandwidth, the effective bandwidth you'd see on a connection would be quite low - think 10 Mb/s on average. That's not exactly chopped liver and its way better than legacy 11b, but it's definitely not 54 Mb/s.
There are suprisingly large differences between 11a products, even those using the exact same vlsi chips. There are two primary reasons: differences in choice of output power amplifier (or lack thereof) and differences in choice of antenna. You can deduce some of what's going on by looking at power and sensitivity ratings in manufacturers product specs. By the way, this also a great way to distinguish between 11b products as well.
Second generation 11a products have much better receiver sensitivity and output power than the first generation versions. And they do transmit through walls... although not concrete or metal or mirrors or some ceramics.
The main reason why 11b can reach farther than 11a in some situations is that 11b can ratchet down to 1 Mb/s whereas 11a is defined for rates from 54 down to 6 Mb/s (11g is identical to 11a in this regard). The difference in SNR and sensitivity needed at a receiver to pick out the 11a or 11g signal accounts for nearly all of the differences in range... and these differences are quite small if you have a good 11a radio with a good antenna.
Thus, 11g will have the same power, SNR, and receiver sensitivity challenges as 11a in the 5 Ghz band, but will also have a small boost in signal propagation efficiency in the lower band. Don't get bamboozled by the hype about compatibility with 11b. Compatibility for sharing the channel does not imply that the radio properties of 11g are the same as 11b.
Most vendors are busy bringing out 11a+b base stations and NIC cards. 11g in compatibility mode looks like a nightmare, whereas 11g in "pure" mode looks like 3 more channels of high performance OFDM if you have an 11a radio that can tune to both the 5Ghz and 2.4 Ghz bands. Aside from the higher-power outdoor channels at 5.8, this provides 11 channels for OFDM (8 at 5 Ghz plus 3). And this means that a group of base stations in an AP-dense environment will certainly be able to find a clear channel.
I didn't say much about the PBCC-based 22 Mb/s products. PBCC is actually a clever design but is likely going to be overshadowed by OFDM at 5 Ghz (11a) and OFDM at 2.4 Ghz (11g variants).
These projects when described in the lay press nearly always skip over any analysis of the kinds of algorithms that can work well on a distributed system. The first metric to look at is the ratio of communication to computation. That is, how many bytes of data does a compute exchange with neighbor(s) before continuing with the next step of computation.
Render farms are embarrasingly parallel requiring no communication with neighbors while rendering a frame. They do require a large amount of data before starting on the next frame, but you can either pipeline that (which they don't do usually) or double up on the number of compute nodes (which is more common).
Suppose instead you want to solve a big mesh problem like a 3D cube with 10^10 points on a side. And its a fairly simple computation. You might need 10^5 or 10^6 nodes and the data traffic between nodes would look like a DOS attack if it took place on the internet.
And then there is the rich space of possibilities between these two extremes and the crossproduct with storage. It is a fascinating area to work in because there is much yet to learn and the possibilities for new networks and processors and storage evolves all the time. Things that were impossible to do last year are within reach this year or next year.
But.... just as 100 Volkswagon beetles may have the same horsepower as a huge earthmoving machine, the beetles cannot readily move mountains... and 100 or 1000 or 10000 PCs with a low-cost interconnect are not equal to a supercomputer or a supercluster that may support 10^6 greater communcations to computation ratio - and thus a much greater range of useful distribution algorithms.
The idea of grassroots bandwidth by-the-people and for-the-people is certainly democratic and appealing in a 60s kind of way. But, commenters are correct in that there are contractual issues with underprovisioned and over-lawyerd ISPs, and this vision of wireless utopia is a pipedream.
That said, I and other professionals who travel would pay for predictable and reliable service in airports and hotels. I sincerely hope that Sputnik or Instant802 or Joltage or someone else who have done the system integration plus the authentication and proper billing systems win a contract with one of the major ISPs, probably a cellular provider, to build out and operate this kind of service.
Paying for access to phantom bandwidth will not attract a self-sustaining customer base. Free access to phantom bandwidth is not a self-sustaining business model. Fix the biz and and things could get started. It's not the same as universal bandwidth everywhere, even though that is a very worthwhile goal. But that goal cannot be reached in one step. A self-sustaining business is the necessary first step.
the arguments without the polemic; and perhaps my family will understand better why I no longer go to the movies with them and why I'm making mp3s from my ancient jazz LPs.
Best quote: the RIAA/MPAA does not want you to have a computer.
they're made in Hollister, CA.
an outgrowth of a company known for motorcycle
after market products. It's a 3-wheeler with belt-drive
to the rear wheel. In California it is classified as a motorcycle
and is allowed in the carpool lanes.
I was a TA for an undergraduate course. It was almost 30 years ago - ~1974. We wanted to identify assignments that had been copied. Sometimes variable names were changed, sometimes not. The compiler was hacked to produce a signature derived from parse tress. Graders looking at assignments could compare the signatures. The prof simply announced that independent work was expected and showed the statistics. A few people needed more personal explanations. By and large the exercise was carried out with good humor and good taste.
I've tried StarOffice, AbiWord and a few other things. They all barf in one way or another
on some of the Word or PowerPoint docs that I must be able to display and edit. These are mostly IEEE standards documents. IETF is fortunately more enlightended.
Since I only have to work with such things about 10% of the time, Vmware has been the solution for me. Expensive? Absolutely since I purchase both vmware and M$. Expensive hardware too since running two operating systems requires more memory. Vmware sucks up a lot. But it works flawlessly for me.
I'll give Hancom a try.
I can't imagine a government agency standardizing on it if it didn't work well. Even so, I have a queasy feeling about whether the software can readily accept my ieee documents or not. Their webpage cites "Enhanced compatibility with MS office files" - kind of noncomittal. Even so, I'll try this before something that seems overly pretentious and overly hyped like Lindows.
It may be worth mentioning that I would really prefer that Adobe had not backed away from Framemaker on Linux. But that's no longer an option.
"fast packet rekeying" is not the same as changing the base keys or master keys (knowledge shared by the endpoints and key distribution system).
Rather, it refers to a technique of using regular
'ol WEP to encipher each packet, but using a different key FOR EACH PACKET. These per-packet keys are computed on the fly using a hash function-like method that scrambles the real key and thus increases the difficulty of attacking the underlying RC4. This technique has been called "key mixing" - a better term than "fast packet rekeying" IMHO - because it avoids confusion with "rekeying" whereby key material is exchanged between endpoints. Rekeying every 16K packets is required in addition to key mixing in order to avoid the passive key recovery methods (airsnort).
By the way, the "real" problem with RC4/WEP is that WEP uses the initial 256 bytes of the RC4 cipherstream. The best "fix" for WEP would be to simply discard all the key flogging trickery, but that approach was rejected because of overhead and difficulty of retrofitting NIC cards that have dedicated RC4 hardware.
It should also be pointed out that spiffing up the WEP does not eliminate attacks whereby 3rd parties inject messages. The rest of the fixup work for WEP involves specifying a separate message authentication function that prevents imposters from sending messages. A good example of what can happen in the absence of authentication is the recent well-publicized weaknesses in Universal Plug and Play. One problem was that an unsolicited UPNP NOTIFY message, if bogus and accepted, initiated a bad chain of events.
Similarly, a rekeying procedure using something like 802.1X is vulnerable to hijacking if the rekey messages are not protected with an authentication function. The bad guy can, in theory, instruct the endpoints to switch to a new key. Of course it's not quite as easy as that because the messages may not be easily forgeable. But if there are ways to forge such messages and there is no authentication function, then the system is wide open.
There is a fair chance that 11b vendors will subset WEP updates in a manner that will may separate message authentication as a configurable option. The result will be a better WEP, but in a system context that can still be compromized although not as easily as before.
The press releases are designed to soothe security-minded corporate customers and disguise the remaining technical issues with WEP, such as
1. the key-mixing technique was diluted in strength so that the overhead of firmware upgrades would be acceptable. The "improved" technique has been changed a few times as weaknesses were discovered. It is quite possible that the new WEP can be cracked as thoroughly as the original.
2. the key-mixing technique requires that a new temporal key be set up every 16K packets - a sign of weakness. The 802.1X procedures for setting up the temporal keys have not been finalized and contain weaknesses.
3. it is debateable whether the 802.1X temporal key procedures, once finalized, will be practical at higher PHY rates of 802.11g or 802.11a since the rate of temporal key updates must be greater than the lower rates needed for 11b.
It is more foolproof to rely on IPSEC as other posters observe. The argument against IPSEC and for wireless link crypto is based on the perceived overhead of forcing everything on an internal enterprise network to run IPSEC so that the wireless subnet can be secure. For SOHO setups this should not be an issue.
Adding stiffening material of one kind or another
to the case components which can act as acoustic
membranes (i.e. loudspeakers) can reduce or kill
a good portion of high-frequency vibration noise.
That's the most irritating noise for most folks.
I have more rotating disk spindles than box fans
or cpu coolers. The disks contribute hugely
to the background buzz. Mounting the disks
on rubber grommets and vibration-damping the
supporting structure does help. Now that we're
slowly converting to disk trays (each with a fan),
it seems easier to apply damping to the disks
as part of the tray assembly via foam/rubber
standoffs.
A technically better cooling solution that's less of a
challenge than water cooling involves pumping
cold air through the box. The cool air source and air pump are in a noisy equipment
room or outside the building. The pressurized
air is pushed into the computer box and pulled
out. Using cold air means less air total flow is
needed.
I saw this technique implemented years ago
- it was astonishingly effective: you couldn't
tell the equipment was powered up.
Blinding the pilot was a scenario in a Tom Clancy
novel. Couple of cia guys hide in the weeds
with equipment brought in through Japanese customs
as professional camera gear. They zap the pilots
on approach and the cause of the crash is not
apparent to investigators.
High-power microwaves, e.g. radar transmitters,
are known to cause inoperable cataracts.
This was well-understood 30 years ago.
x-rays caused by high power high-frequency
emissions can cause cancer. Old color-TV sets
and medical x-rays are good examples. Cancer
incidence among x-ray technicians remains higher
than the norm.
Low-frequency power line emissions at any power
level have yet to be associated with confirmed medical evidence although the medical community
and legal community have been looking for several
years.
Microwave power transmission has the potential
for disaster.
Users of Cplant wanted to checkpoint their
computation every 10 minutes or so to graphically
observe the progress of the program. This is a very common technique in large-scale computation. Unfortunately, it took more than an hour to do that on the incarnation of the hardware that had
six OC3s for external communication. And that was
before the machine grew bigger.
Commodity machines tend to have commodity io.
Get what you pay for (sometimes).
I thought Cplant did a nice job of applying
two-level structure to an otherwise flat sea
of cluster nodes. Think of it as worker bees
and team leader bees. A rack of workers would
have a team leader responsible for that rack.
There's a 1024p SGI machine at NASA Ames.
You can run your program through the compiler,
get an a.out, run it, get all of those puppies
honking at the same time while file io can be
instantly visible to any or all of them.
File io could easily be in the GBytes/sec range
to/from a single file descriptor and single file.
Wake me up when a cluster can approximate that
functionality (compile+go, unified io) albeit if not at similar performance levels.
smart routers are a bandaid
on
Smart Routers
·
· Score: 1
The religion of packet switching (dumb router core) does not acknowledge the value of circuit switching. There are many architectures where packet switching rides over (reliable) circuits,
as well as the other way around. The extreme measures needed to look at an IP packet stream and deduce (!!) the circuit information that would have been present, but is not, require a tour-de-force of beyond-the-header spying: i.e. it's like adding a switching fabric to Carnivore. Caspian is not the only proponent of "reverse-engineering" packets to synthesize QoS streams. The idea has been around, although doing it on a bunch of OC-192 flows is quite macho. Caspain has probably stated the problem correctly; it is not at all clear the world will be dragged in their direction.
I rely on debuggers for a traceback after crash.
However, that rarely tells what the program was
doing before it got into trouble. For that you
need not only the current state, but the previous
states looking back in time. Debugging a transport protocol under multi-client load is a
good example.
I'd suggest creating a tracebuffer fifo, simple means for annotating the threaded code with
calls that log state in the buffer, and means
for extracting the contents and displaying
in various interesting ways. It's easy to do this. It's portable. And it will yield information far beyond what is possible with
language/OS-centric tools that know nothing
about the theory of operation of your app.
Slashdot Mirror
For our New Year's party I used a wireless laptop that nfs-mounted a big mp3 collection from a server and used xmms with a playlist generated with grave.
Most of the tunes were encoded at 256K. Looking at network traffic, the wireless channel would be quiet for 4 seconds, then the player would move 50 packets in the 5th second, then quiet for 4 more seconds, and so on. Interesting pattern that illustrates nfs read-ahead.
The Sonos device is different in several respects. The main ones are the gui/controls, the mesh network, and audio quality. I met the Sonos people last year and they are audio geeks. My tunes would sound much better on their box than my laptop. They have time synch and streaming in their network whereas the nfs hack has nothing of the kind and depends on readahead bandwidth. The control system speaks for itself. My family could easily use it whereas I have to be present to get the nfs hack setup (and debugged if needed).
There are rarely new ideas in computer architecture. This may be an update of a transputer-like thing with better communications and core cpu. The real questions that need answering are about the memory model (distributed?) and comm model (warmed over message-passing?).
Chances are it contains nothing new or radical
and is likely just a cluster component on a chip.
Prepare to be disappointed.
SGI has had 512 and 1024-cpu MIPS-based systems in operation for more than 5 years. Much work was done on the Irix systems to initialize large parallel computations and provide libraries and compiler support for these configurations. One technique is to provide message-passing libraries that use shared memory. A better technique is to morph (slightly) parallel mesh apps so that each computational mesh node exposes the array elements to be shared with neighbors. No message-passing needed - you push data after a big iteration and then use the (really fast) sync primitives to launch into the next iteration. With shared-nothing clusters (i.e. Beowulf) a computation (and its memory) must be partitioned among the compute nodes. The improvement over a "classical" cluster can be startling especially with computations that are more communications-bound than compute-bound. This means there is no value for replacing a render farm with a big system. But there are big compute problems, e.g. finite element, for which the shared-nothing cluster is often inadequate.
With a single memory image system the computation can easily repartition dynamically as the computation proceeds. Its very costly (never say impossible!) to do this on a cluster because you have to physically move memory segments from one machine to another. On the NUMA system you just change a pointer. The hardware is good enough that you don't really have to worry about memory latency.
And let's not forget io. Folks seem to forget that you can dump any interesting section of the computation to/from the file system with a single io command. On these systems the io bandwidth is limited only by the number of parallel disk channels - a system like the one mentioned in the article can probably sustain a large number of GBytes/sec to the file system.
Let's not forget page size. The only way you can traverse a few TB of memory without TLB-faulting to death is to have multi-MByte-size pages (because TLB size is limited). SGI allowed a process to map regions of main memory with different page sizes (upto 64 MB I think) at least 10 years ago in order to support large image data base and compute apps.
When I used to work at SGI (5 years ago) the memory bandwidth at one cpu node was about 800 MBytes/s. My understanding is that the Altix compute nodes now deliver 12 GBytes/s at each memory controller. Although I haven't had a chance to test drive one of these new systems, it sounds like they have gradually been porting well-seasoned Irix algorithms to Linux. It is unlikely that a commodity computer really needs all of this stuff, but I'm looking at a 4-cpu Opteron that could really use many of the memory management improvements.
g
I implemented this once as a special patch in Irix/XFS. It's not sufficient to do it just in the file system. The priority must be passed down to the devices. With Fibre Channel devices supporting a good-sized output queue, it is important to utilize the priority queuing supported by the disk channel vlsi chip. Unless there is device and driver support for priority queues, reordering the disk block queue at higher levels in the OS is usually not effective.
This kind of priority is best-suited for real-time processes that have real-time needs for disk access. The problem of keeping a big tarball unpacking operation from sucking up lots of space may be better solved by adding space constraints rather than having prioritized i/o.
The Mesh Networks Inc protocols are proprietary.
e r.ht ml.
.11 power management is to put the radio in sleep mode (and run the sleep protocol with the AP). This has not been a competitive focal point, but vendors are starting to improve.
.11 radios that are just starting to hit retail channels can operate on both the 11b and 11a bands and with both the 11b and a/g OFDM codecs. The prices for 11a nic cards is under $100 now (79?) and the a/b/g nic cards won't be far behind.
They are a byproduct of military-funded tactical
radio R&D. There is an emphasis onself-organizing topology and route discovery. If every soldier and vehicle is lugging a radio, then the network
has a good chance of continuing to operate even if parts of it are destroyed.
This kind of mesh does have some pathology.Take some number, say 10, of nodes placed in a straight
line. You are at one end of the line and the internet ISP is at the other end. And you have
10 wireless hops between you and the internet. And the people in the middle of the line may not be really happy with you either.
There are non-proprietary approches. Check out the ietf MANET working group at
http://www.ietf.org.html.charters/manet-chart
There are numerous university projects. Try Google(mesh network & university)
or Google(mobile network & university).
There have been numerous failed startup company attempts at mesh networks. One approach that I found very appealing used a self-organizing mesh
that organized itself into rooted tree structures.
The internal tree branches served as backhaul connections to the internet. The leaves represent the clients/users. The internal nodes are not mobile. They are devices to be installed on utility poles or public access locations. They find one another and create an uplink/downlink
infrastructure where uplink means a path to the ISP or other wired infrastructure and downlink
means to the client. I liked this approach because it builds a predictible structure that
can be analyzed and because the routing procedures
within the internal nodes are a lot simpler
than in the completely unconstrained mesh network.
The tree-like organization also seems to avoid
another conceptual problem with the fully
unconstrained network which is bandwidth sharing.
If you are a client in a full mesh, your node
must accept routing traffic from other nodes.
Thus a goodish portion of your bandwidth and battery power may be consumed by traffic going
through your client - but it's not your traffic.
I'd guess that most people would not want to act
as a router and be draining power pretty much
fulltime. Makes more sense to have a wireless
self-organizing infrastructure that can provide
bandwidth to clients that cruise within range.
There were a few misleading comments about power
in earlier emails. Cell phones typical draw
about 2 watts when transmitting. That exceeds
the current capacity of the battery. They actually charge a capacitor from the battery between time slots and drain the capacitor during transmission. 802.11 devices have lower peak current drains, and they continue to get better. The most important technique in
Next-generation
I think it is important to point out that 11b only has 3 channels to operate in. That doesn't give you much routing diversity when you need a lot of overlapping transmitters to create a useful (and thus redundant) mesh. But when you add 11a and can use the higher bandwidth ofdm codec in either the 11a bands or in the 11b bands (where they call it 11g), then you have more than a dozen channels that can be operating simultaneously. It seems obvious to me that this kind of channel diversity will be needed to successfully deploy a good mesh.
There were many comments about motives and costs, but I
didn't see anyone make the obvious comment about bandwidth.
That is, the bandwidth on a cable segment is shared on the channel. The cable companies are not in position to make more segments or open up more channels. I view bandwidth caps as a disguised way of dealing with system capacity issues without fixing the system. Someone I know once called this
kind of situation a "success disaster". More customers for cable means the service gets worse, etc.
Similar article in today's NY Times citing the Intel publication. Their article highlights that no comparison is made to recent Pentium-Xeon performance improvements. The article also mentions AMD's Hammer and suggests directly that McKinley may not measure up to the hype when compared with other processors.
The article also mentions that Jack Dongarra - keeper of the Linpack-based 500 fastest computer systems - now shows an Itanium-based cluster at the top of the heap.
Unfortunately for programs that don't run out of the cache, there are three dimensions to computer system performance: processor, memory, and io.
Intel marketing has successfully skewed the common perception to the detriment of a more balanced system viewpoint.
The Tiqit eightythree is similar in concept to the
sony gizmo, but even smaller. It runs any X86 OS,
has a cardbus slot, vga out, mike+audio plugs, 10G disk, etc. Screen might be smaller than the Sony, but is still very effective. Not in production yet, but may signify a trend. See www.tiqit.com.
I never have had the time to learn how to program a Palm. With one of these devices, I don't have to. For that reason alone, they're likely to be more useful... even though more costly at first
Even so, the money I wasted on two Palms would probably bring one home.
bathrooms and Italian-style kitchens often
have ceramic tile walls.
11g is really 11a-style OFDM at 2.4 Ghz rather than the 5 Ghz band. There would be two (at least) 11g modes: a compatibility mode whereby OFDM packets and legacy 11b CCK packets coexist, and one which is "pure" OFDM at 2.4 Ghz.
... and these differences are quite small if you have a good 11a radio with a good antenna.
The compatibility mode adds a huge overhead to each transmitted packet. An 11g transmitter in this mode must first complete a legacy 11b RTS/CTS operation on the air which, if successful, is followed by the actual packet. Even if the actual packet were transmitted at nearly infinite bandwidth, the effective bandwidth you'd see on a connection would be quite low - think 10 Mb/s on average. That's not exactly chopped liver and its way better than legacy 11b, but it's definitely not 54 Mb/s.
There are suprisingly large differences between 11a products, even those using the exact same vlsi chips. There are two primary reasons: differences in choice of output power amplifier (or lack thereof) and differences in choice of antenna.
You can deduce some of what's going on by looking
at power and sensitivity ratings in manufacturers product specs. By the way, this also a great way to distinguish between 11b products as well.
Second generation 11a products have much better receiver sensitivity and output power than the first generation versions. And they do transmit through walls... although not concrete or metal or mirrors or some ceramics.
The main reason why 11b can reach farther than 11a in some situations is that 11b can ratchet down to 1 Mb/s whereas 11a is defined for rates from 54 down to 6 Mb/s (11g is identical to 11a in this regard). The difference in SNR and sensitivity needed at a receiver to pick out the 11a or 11g signal accounts for nearly all of the differences in range
Thus, 11g will have the same power, SNR, and receiver sensitivity challenges as 11a in the 5 Ghz band, but will also have a small boost in signal propagation efficiency in the lower band.
Don't get bamboozled by the hype about compatibility with 11b. Compatibility for sharing the channel does not imply that the radio properties of 11g are the same as 11b.
Most vendors are busy bringing out 11a+b base stations and NIC cards. 11g in compatibility mode looks like a nightmare, whereas 11g in "pure" mode looks like 3 more channels of high performance OFDM if you have an 11a radio that can tune to both the 5Ghz and 2.4 Ghz bands. Aside from the higher-power outdoor channels at 5.8, this provides 11 channels for OFDM (8 at 5 Ghz plus 3).
And this means that a group of base stations in an AP-dense environment will certainly be able to find a clear channel.
I didn't say much about the PBCC-based 22 Mb/s products. PBCC is actually a clever design but is likely going to be overshadowed by OFDM at 5 Ghz (11a) and OFDM at 2.4 Ghz (11g variants).
These projects when described in the lay press nearly always skip over any analysis of the kinds of algorithms that can work well on a distributed system. The first metric to look at is the ratio of communication to computation. That is, how many bytes of data does a compute exchange with neighbor(s) before continuing with the next step of computation.
Render farms are embarrasingly parallel requiring no communication with neighbors while rendering a frame. They do require a large amount of data before starting on the next frame, but you can either pipeline that (which they don't do usually) or double up on the number of compute nodes (which is more common).
Suppose instead you want to solve a big mesh problem like a 3D cube with 10^10 points on a side. And its a fairly simple computation. You might need 10^5 or 10^6 nodes and the data traffic between nodes would look like a DOS attack if it took place on the internet.
And then there is the rich space of possibilities between these two extremes and the crossproduct with storage. It is a fascinating area to work in because there is much yet to learn and the possibilities for new networks and processors and storage evolves all the time. Things that were impossible to do last year are within reach this year or next year.
But.... just as 100 Volkswagon beetles may have the same horsepower as a huge earthmoving machine, the beetles cannot readily move mountains... and 100 or 1000 or 10000 PCs with a low-cost interconnect are not equal to a supercomputer or a supercluster that may support 10^6 greater communcations to computation ratio - and thus a much greater range of useful distribution algorithms.
The idea of grassroots bandwidth by-the-people
and for-the-people is certainly democratic and
appealing in a 60s kind of way. But, commenters
are correct in that there are contractual issues
with underprovisioned and over-lawyerd ISPs,
and this vision of wireless utopia is a pipedream.
That said, I and other professionals who travel
would pay for predictable and reliable service
in airports and hotels. I sincerely hope that
Sputnik or Instant802 or Joltage or someone else
who have done the system integration plus the
authentication and proper billing systems win
a contract with one of the major ISPs, probably
a cellular provider, to build out and operate
this kind of service.
Paying for access to phantom bandwidth will not
attract a self-sustaining customer base. Free
access to phantom bandwidth is not a self-sustaining business model. Fix the biz
and and things could get started. It's not the
same as universal bandwidth everywhere, even
though that is a very worthwhile goal. But that
goal cannot be reached in one step. A self-sustaining business is the necessary first
step.
the arguments without the polemic; and perhaps my family
will understand better why I no longer go to the movies with them and why I'm making mp3s from my ancient jazz LPs.
Best quote: the RIAA/MPAA does not want you to have a computer.
see www.corbinmotors.com/sparrow.htm
they're made in Hollister, CA.
an outgrowth of a company known for motorcycle
after market products. It's a 3-wheeler with belt-drive
to the rear wheel. In California it is classified as a motorcycle
and is allowed in the carpool lanes.
I was a TA for an undergraduate course. It was almost 30 years ago - ~1974. We wanted to identify assignments that had been copied. Sometimes variable names were changed, sometimes not. The compiler was hacked to produce a signature derived from parse tress. Graders looking at assignments could compare the signatures. The prof simply announced that independent work was expected and showed the statistics. A few people needed more personal explanations. By and large the exercise was carried out with good humor and good taste.
I've tried StarOffice, AbiWord and a few other things. They all barf in one way or another
on some of the Word or PowerPoint docs that I must be able to display and edit. These are mostly IEEE standards documents. IETF is fortunately more enlightended.
Since I only have to work with such things about 10% of the time, Vmware has been the solution for me. Expensive? Absolutely since I purchase both vmware and M$. Expensive hardware too since running two operating systems requires more memory. Vmware sucks up a lot. But it works flawlessly for me.
I'll give Hancom a try.
I can't imagine a government agency standardizing on it if it didn't work well. Even so, I have a queasy feeling about whether the software can readily accept my ieee documents or not. Their webpage cites "Enhanced compatibility with MS office files" - kind of noncomittal. Even so, I'll try this before something that seems overly pretentious and overly hyped like Lindows.
It may be worth mentioning that I would really prefer that Adobe had not backed away from Framemaker on Linux. But that's no longer an option.
g
If software in China today is mostly pirated,
how can an indigenous software industry survive
and grow?
"fast packet rekeying" is not the same as changing the base keys or master keys (knowledge shared by the endpoints and key distribution system).
Rather, it refers to a technique of using regular
'ol WEP to encipher each packet, but using a different key FOR EACH PACKET. These per-packet keys are computed on the fly using a hash function-like method that scrambles the real key and thus increases the difficulty of attacking the underlying RC4. This technique has been called "key mixing" - a better term than "fast packet rekeying" IMHO - because it avoids confusion with "rekeying" whereby key material is exchanged between endpoints. Rekeying every 16K packets is required in addition to key mixing in order to avoid the passive key recovery methods (airsnort).
By the way, the "real" problem with RC4/WEP is that WEP uses the initial 256 bytes of the RC4 cipherstream. The best "fix" for WEP would be to simply discard all the key flogging trickery, but that approach was rejected because of overhead and difficulty of retrofitting NIC cards that have dedicated RC4 hardware.
It should also be pointed out that spiffing up the WEP does not eliminate attacks whereby 3rd parties inject messages. The rest of the fixup work for WEP involves specifying a separate message authentication function that prevents imposters from sending messages. A good example of what can happen in the absence of authentication is the recent well-publicized weaknesses in Universal Plug and Play. One problem was that an unsolicited UPNP NOTIFY message, if bogus and accepted, initiated a bad chain of events.
Similarly, a rekeying procedure using something like 802.1X is vulnerable to hijacking if the rekey messages are not protected with an authentication function. The bad guy can, in theory, instruct the endpoints to switch to a new key. Of course it's not quite as easy as that because the messages may not be easily forgeable. But if there are ways to forge such messages and there is no authentication function, then the system is wide open.
There is a fair chance that 11b vendors will subset WEP updates in a manner that will may separate message authentication as a configurable option. The result will be a better WEP, but in a system context that can still be compromized although not as easily as before.
The press releases are designed to soothe security-minded corporate customers and disguise the remaining technical issues with WEP, such as
1. the key-mixing technique was diluted in strength so that the overhead of firmware upgrades would be acceptable. The "improved" technique has been changed a few times as weaknesses were discovered. It is quite possible that the new WEP can be cracked as thoroughly as the original.
2. the key-mixing technique requires that a new temporal key be set up every 16K packets - a sign of weakness. The 802.1X procedures for setting up the temporal keys have not been finalized and contain weaknesses.
3. it is debateable whether the 802.1X temporal key procedures, once finalized, will be practical at higher PHY rates of 802.11g or 802.11a since the rate of temporal key updates must be greater than the lower rates needed for 11b.
It is more foolproof to rely on IPSEC as other posters observe. The argument against IPSEC and for wireless link crypto is based on the perceived overhead of forcing everything on an internal enterprise network to run IPSEC so that the wireless subnet can be secure. For SOHO setups this should not be an issue.
Adding stiffening material of one kind or another
to the case components which can act as acoustic
membranes (i.e. loudspeakers) can reduce or kill
a good portion of high-frequency vibration noise.
That's the most irritating noise for most folks.
I have more rotating disk spindles than box fans
or cpu coolers. The disks contribute hugely
to the background buzz. Mounting the disks
on rubber grommets and vibration-damping the
supporting structure does help. Now that we're
slowly converting to disk trays (each with a fan),
it seems easier to apply damping to the disks
as part of the tray assembly via foam/rubber
standoffs.
A technically better cooling solution that's less of a
challenge than water cooling involves pumping
cold air through the box. The cool air source and air pump are in a noisy equipment
room or outside the building. The pressurized
air is pushed into the computer box and pulled
out. Using cold air means less air total flow is
needed.
I saw this technique implemented years ago
- it was astonishingly effective: you couldn't
tell the equipment was powered up.
Blinding the pilot was a scenario in a Tom Clancy
novel. Couple of cia guys hide in the weeds
with equipment brought in through Japanese customs
as professional camera gear. They zap the pilots
on approach and the cause of the crash is not
apparent to investigators.
High-power microwaves, e.g. radar transmitters,
are known to cause inoperable cataracts.
This was well-understood 30 years ago.
x-rays caused by high power high-frequency
emissions can cause cancer. Old color-TV sets
and medical x-rays are good examples. Cancer
incidence among x-ray technicians remains higher
than the norm.
Low-frequency power line emissions at any power
level have yet to be associated with confirmed medical evidence although the medical community
and legal community have been looking for several
years.
Microwave power transmission has the potential
for disaster.
Users of Cplant wanted to checkpoint their computation every 10 minutes or so to graphically observe the progress of the program. This is a very common technique in large-scale computation. Unfortunately, it took more than an hour to do that on the incarnation of the hardware that had six OC3s for external communication. And that was before the machine grew bigger. Commodity machines tend to have commodity io. Get what you pay for (sometimes). I thought Cplant did a nice job of applying two-level structure to an otherwise flat sea of cluster nodes. Think of it as worker bees and team leader bees. A rack of workers would have a team leader responsible for that rack. There's a 1024p SGI machine at NASA Ames. You can run your program through the compiler, get an a.out, run it, get all of those puppies honking at the same time while file io can be instantly visible to any or all of them. File io could easily be in the GBytes/sec range to/from a single file descriptor and single file. Wake me up when a cluster can approximate that functionality (compile+go, unified io) albeit if not at similar performance levels.
The religion of packet switching (dumb router core) does not acknowledge the value of circuit switching. There are many architectures where packet switching rides over (reliable) circuits, as well as the other way around. The extreme measures needed to look at an IP packet stream and deduce (!!) the circuit information that would have been present, but is not, require a tour-de-force of beyond-the-header spying: i.e. it's like adding a switching fabric to Carnivore. Caspian is not the only proponent of "reverse-engineering" packets to synthesize QoS streams. The idea has been around, although doing it on a bunch of OC-192 flows is quite macho. Caspain has probably stated the problem correctly; it is not at all clear the world will be dragged in their direction.
I rely on debuggers for a traceback after crash. However, that rarely tells what the program was doing before it got into trouble. For that you need not only the current state, but the previous states looking back in time. Debugging a transport protocol under multi-client load is a good example. I'd suggest creating a tracebuffer fifo, simple means for annotating the threaded code with calls that log state in the buffer, and means for extracting the contents and displaying in various interesting ways. It's easy to do this. It's portable. And it will yield information far beyond what is possible with language/OS-centric tools that know nothing about the theory of operation of your app.