After doing further research, I've come across a second operating principle used to make coilguns, which is closer to what the original poster described.
As a conductor resists changes to the local magnetic field (Lenz's Law, cited above), if you set up a moving magnetic field, the projectile will tend to follow it.
Note that the projectile is not "attracted into the coil", as the original article stated. Rather, if you're turning coils on and off in sequence along the gun, the projectile will be repelled by the moving field as it approaches, and dragged along with it (attracted) as it passes. The projectile *won't* just follow along with the first pulse in the moving field, either - it's just tugged briefly in the same direction. You'd have to send a train of moving field pulses over it to bring it up to the speed of the train, and it'll never quite get there (as the speed of the projectile approaches that of the moving pulse train, the pulses pass with lower frequency, so the projectile's efficiency as an inductor drops).
You don't gain much drift-resistance, either. While the projectile is no longer actively perturbed off-axis (as with the previous style of coilgun I described), nothing keeps it on the axis either. You still need active correction (or rails).
You're also wasting more power, because you have to keep many coils (those around the projectile) oscillating instead of just the coil behind the projectile.
This coilgun still does not require a ferromagnetic projectile, though ferromagnetism doesn't actively harm this type of gun.
Several points look suspicious.
on
Homemade Gauss Gun
·
· Score: 5, Informative
Background information about 'Gauss Guns' can be found here [http://www.powerlabs.org/coilguns.htm]
I've spotted multiple errors in this person's page. It looks like he was cribbing notes from a more informed paper.
Problems I've found:
A DC solenoid attracts only ferromagnetic materials. An AC solenoid repels any conductor.
The authour claims that coilgun coils attract the projectiles. This is not correct. They work by repulson (by Lenz's Law, the induced field in the conducting slug repels the coil's field).
Whinging about no exact solutions to coilgun parameter values is bogus.
The authour does handwaving towards the 3-body problem to support his claim that you can't figure out what the best configuration of a coilgun is. These are completely unrelated problems. The 3-body problem is hard because the system a) has no general closed-form solution and b) is chaotic, so you can't even approximate a closed-form solution for many configurations.
A coilgun, on the other hand, just has more variables than you need. You don't have one optimal coilgun - you have an infinite number of optimal coilguns. Pick some of your parameters to be convenient, and solve for the others.
It's not hard to calculate how strong the induced field will be in a coilgun, or the force transferred to the projectile. It's also not hard to calculate how a capacitor-driven system will behave (hint: consider the coil's inductance with and without the slug inside it, and you can figure out how the energy transfer works).
Energy limitations apply only to military-grade coilguns.
If you're building a tabletop coilgun, you don't have to worry about energy storage. Just get a good DC supply, set up the coils in parallel with capacitors to get a nice LC tank circuit, and set up a transistor on each coil driven off an extra turn of the coil (or a secondary coil) just as you'd set up an RF signal generator. You're going to put at most a few hundred joules into your projectile (and that's if you're heaving aluminum pipe segments across the street). Exotic solutions are only needed if you're trying to shell a neighbouring city.
[He gets most of the switching circuit concerns right, though an ordinary bipolar transistor works fine at tabletop energies, and switching _time_ isn't a problem - even a military weapon can get away with tenth of a millisecond timing for the coils.]
Ferromagnetic projectile is just dumb.
As driving frequency goes up (or pulse length shortens), inductive effects become important. This is how a real coilgun works - it's driven by inductive repulsion of a conducting slug. If you have an iron slug, a) attractive and repulsive forces will fight each other (or you can think of it as induced currents shielding the slug from your applied magnetic field).
Magnetic slugs only work for tabletop devices with slow firing speeds.
A metal sheath is asking for arcing.
He's using a metal pipe as a guide for the projectile. A closed pipe would shield the inside of the tube just as a conducting projectile shields itself. He cuts a slot through the length of the pipe to avoid this, but you still have very high induced voltages around the pipe. A coilgun that switches at any decent speed with a strong magnetic field will induce currents that arc across this gap.
If you want a projectile guide, use rails.
If you want an elegant solution, let the slug move through open air and use secondary coils to adjust the geometry of the magnetic field as the projectile passes through to nudge it back into line if you notice it drifting. But this is not trivial to implement.
If you want to centralize administration, and don't really care what happens underneath that, why not just maintain a reference Windows machine, take drive images, and re-image the drives of the lab machines (over the network) on a weekly basis?
There's software available to automatically do this for NT-based systems (a few parts of the university I'm at do that). Or, you could set up a few shell scripts on a small *nix partition on each machine to do the same thing.
You'd have to make sure that you had only one or a small number of hardware and software configurations throughout the labs, but that tends to happen anyways (machines are bought en masse, and there are only a few departments you're responsible for).
I'm not sure what a thin client solution would buy you over this, and it would introduce additional headaches (having to maintain a very powerful server to serve all of the clients, for one thing).
I don't think it's fair to allow the computer to "judge" modem players' moves, and try to determine "if" the player would have got the hit. Not only is this unfair to the player (when they get to a real LAN tournament they'll be roasted), it's also unfair to the vet with a decent connection, because the newbie in essense gets a free hit. I would propose figuring out better ways to communicate over the network instead of trying to second guess the players' moves with algorhythms.
If my connection to a game is rotten, there's nothing the game client or the game server can do about it.
If you're only getting 4 updates a second from the server, your client *has* to guess what the other players are doing until the server tells it what really happens, because the alternative is to have a 4 FPS update.
Likewise, if the server only gets 4 updates per second from your client, it *has* to guess what you want to do, because it can't read your mind. Most servers guess that you'll keep holding down the keys that you were holding when it last heard from you, which is a tolerable solution. What would you prefer them to do?
The networking code in most games is already as good as it can be. The interpolation code tends to vary from game to game, but the effects are usually the same.
4X AGP is a 32-bit 266 MHz bus. That's more throughput than possible with PCI.
Unless you buy into Intel's PCI-X, which is 64/133.
And most graphics cards are not limited by bus bandwidth with *any* flavour of AGP (see the various Tom's Hardware benchmarks). The usual limit is fill rate for new cards, and lack of geometry processing for old cards (assuming you're playing a new game). Textures are stored on-card by any sane game, so the only thing going across the bus is lists of triangles.
AGP doesn't have contention with other devices on the bus so it doesn't have to do any logic for mastering or controlling and can allocate all its clocks to doing a data transfer.
While this would be an issue for very short data transfers, graphics cards will likely be transferring large batches of data. This is done in burst mode, which gives one transfer per clock.
Why would you want PCI? The only advantage PCI gives is that you can hang multiple devices off of it. But while that lets you get multiple monitor support easier, it will really kill your limited bandwidth.
You have bandwidth to spare; all you'd be doing in a multi-monitor setup is sending the same triangle lists over the bus, not cutting and pasting image data or doing texturing. Have one one dominant card and leave the others snooping traffic, and you have zero extra overhead for this.
The real benefit of having multiple video cards is that it lets you easily do render farming for things like games. Have each card render half the screen, and copy all cards' partial renderings to one card's frame buffer. 32/33 PCI is too slow to be practical for this, but 64/66 has more than enough bandwidth. I studied the feasibility of this at one of my past jobs.
A fast CPU is nice, but how about upgrading the rest of the standard PC architecture and peripherals to the same level?
Weren't we all suppose to be using high-speed serial connections by now instead of a cocktail of SCSI (1/2/3, wide, fast, hold the mayo), IDE (ATA-33/66/100), parallel, 8 bit serial, USB, Firewire, PS/2, PCI, ISA (which is finally disappearing), etc. Heck, I'd be happy if the motherboard ran at even half to a third the speed of the cpu.:P
The good news is that USB is well on its way to completely replacing serial and parallel ports, and that PCI has been the One True Bus for the past couple of years now. Everything south of the southbridge is slowly fading away.
IMO, if we'd switched to 66 MHz 64-bit PCI years ago, we'd have no further problems on this front. In practice, PCI-X may finally be pushed through by Intel, and that will serve most internal communications needs. Motherboard chipsets are modular enough that it doesn't really matter what flavour of IDE/SCSI/firewire your drive is hanging off of; the drive controller is just another PCI device to the processor. You have enough bandwidth and DMA functionality on PCI bus to handle it.
The only peripherals that are currently bottlenecks are RAM and the video card. RAM is handled by upgrading the memory bus every couple of years. This is easy to do, because peripherals don't care what happens on the other side of the northbridge. The video card was handled adequately by the hack that is AGP (64-bit 66 MHz PCI would have been a much better idea, but that wouldn't have given Intel its nice AGP port to license).
The only peripheral that *might* be a problem in the future will be the network card (when gigabit cards finally come into vogue), and that will probably be what forces motherboard makers to put wider/faster PCI on to midrange boards and not just high-end boards.
In summary, this is less of a problem than it first appears to be.
The only serious bottleneck for performance is RAM latency, and that's not because of legacy peripherals.
Also, wasn't this inevitable. There are a few Beowulf jokes being posted, but that's really what's going on. Increasingly high performance tasks (Google, render farms etc. etc. etc.) are using massive arrays of low-power CPUs. It costs a lot of money to develop big iron chips, and if people aren't buying them then there's no point in investing that much money.
The problem is that a massively parallel computer is only useful for certain classes of problem. There are many types of problem where communications load goes up very rapidly with the number of processors, which makes a cluster (with its relatively poor communications bandwidth) impractical. This is what Big Iron is designed to be useful for.
Re:And why not turn lead into gold while we're at
on
Inside Intel
·
· Score: 2
My point was that they need to focus more on researching those fields rather than on clock speed. [...]
Now, im not talking about making lead into gold, im just saying its almost obvious if you want technologically superior chips, you need to invest in the obvious bottleneck, not what the marketing department says is most effective.
And my point is that Intel will market what they expect to be able to put on the shelves next year. *That's* why you hear about their other processor tweaks.
Of *course* Intel is spending money on improving their memory subsystems! But you don't hear about it, because they haven't made any breakthroughs yet (RamBus was the last proposed improvement they invested in, and that failed spectacularly).
It is also in Intel's interest to invest in improvements that are likely to bear fruit quickly. Improving the memory subsystem isn't the only way to improve processor performance, so they're investigating other methods as well.
Re:And why not turn lead into gold while we're at
on
Inside Intel
·
· Score: 2
Oh, I don't know about that. The PA-8700 has 2.25 MB of L2 cache, which is okay I suppose. The MIPS R14000 processors in the SGI Origin 3000 series have 8 MB of L2 cache per CPU, and they do pretty well, to put it mildly.
Large amounts of cache benefit niche applications. You see huge caches on server chips because a) they happen to run this kind of niche load, and b) servers are optimized for performance above all else, which means a performance gain of a few percent is worth the cost of adding more cache (while a consumer would balk at paying twice as much).
Cache benefits servers that are running many, many tasks at once - a context switch won't necessarily end up purging the cache if it's big enough. Consumer machines don't usually have this kind of load (or we'd all be running dual-processor machines).
Some scientific applications will benefit, but only some of them. The rest either have access patterns that don't lend themselves to cacheing, or use blocking techniques to increase locality enough that even a smaller cache will be adequate (incremental return becomes low beyond a certain point).
For the vast majority of applications, we're already well into the realm of diminishing returns. Simple proof of this: We've had 256k and 512k caches on consumer chips for quite a while. Linewidth is fine enough that we have the ability to put much more cache on without taking a yield penalty. If doubling the cache size was a sure-fire performance boost for consumer chips, both Intel and AMD would have done it already.
And why not turn lead into gold while we're at it.
on
Inside Intel
·
· Score: 4, Interesting
Maybe instead of constantly worrying about clock speeds they spend more research into being able to add larger amounts of cache or try to achieve one clock cycle access to main memory
I'm afraid that both of these (especially the last one) sound like the infamous "let's just find a way to factor huge numbers" quote. That is - yes, it would be wonderful to be able to do this, but there are good reasons for believing that it's very difficult (not that people haven't tried).
For caches, the problem is that larger caches are slower and more power-hungry. To compensate, you use a multilevel cache architecture, but you still have some penalties. A modern foundry could put as much cache as it wanted on to a chip (look at HP's most recent chip for an example) - but because of architectural tradeoffs, this isn't always a good idea.
For memory, if you can find a way to get single-clock access latencies reliably without a 10x slower clock, sell it to $favourite_company and retire on the proceeds. This isn't likely to happen for _two_ reasons. Firstly, modern memory is optimized for density at the expense of speed (this is why we use DRAM and not SRAM for system memory). Secondly, because of the trace lengths, capacitance (and inductance!), and crosstalk and noise issues, it's one _hell_ of a lot harder to send data at low latency _or_ low bandwidth across a motherboard than just within a chip.
There are ways of pushing the boundaries on all of these things, but while we're doing that, processor speeds are still getting faster, putting tougher requirements on the memory and negating most of the relative gain.
In summary, there's a good reason that Intel (along with everyone else) is pursuing more conventional enhancements while background research into memory and caches is going on.
Most nearsightedness [allaboutvision.com] and farsightedness [allaboutvision.com] is caused by the eye, and consequently the retina, not being in the correct shape.The image is formed either too far ahead or behind the retina.
I read the article but I didn't see any mention of how the beam would project on malformed retinas.
As long as the rays from the scanner converge on one point near the surface of your eye, this problem should be greatly reduced.
Take an old-fashioned camera, and set the aperture to something wide (low F number). Then play with the focus. Focus has to be very finely adjusted.
Now set the aperture to something narrow (high F number). Much more of the scene looks sharp - imaging is less sensitive to focus.
I'm told that retina-scanning projectors produce much the same effect (haven't tried one myself, unfortunately).
Nuclear systems would be big, heavy, and only get about twice the fuel efficiency of the standard rockets they use now; ion propulsion, running on solar cells, gets ten times the efficiency of a standard rocket.
You could use a radiothermal electric generator to power an ion drive. This will approach solar-powered ion drive efficiencies if the weight of the RTG is comparable to or less than the weight of the solar panels you'd normally put on an ion-drive craft.
This would only be better than solar power for craft that would be far from the sun (power to weight ratio for RTGs is pretty lousy, if I recall correctly), but craft like this could certainly be built.
Among other things, this is the best way that I can think of to survey multiple bodies in the Kupier Belt.
Next, 3 MB cache sounds nice, but L3? It may be on die, but by that point the clock reduction probably makes it perform equivalently to a 256 k L1 cache, or a 512 or larger L2.
A fundamental rule of building caches is that a larger cache is slower and dissipates more energy per lookup than a smaller cache. This is why multilevel cacheing exists in the first place (otherwise we'd just have a huge L1 cache - and before you mention it, due to architectural sneakiness, HP's giant L1 cache isn't really an L1 cache).
So, you can't just spend the L3 area on making a bigger L2. You'd end up with a slower, hotter L2, which could easily _degrade_ performance.
As long as the L3 cache is faster to access than main memory, it'll be useful for some things. Whether it'll be useful for *most* things is another issue. This depends on the "working set" of the applications you're running (how much memory they repeatedly access). I guess Intel's banking on working sets being larger than most caches.
Another possibility is that they're testing the cache architecture for use in future SMT or CMP designs (both of which would have multiple independent executioin contexts running). If you're running multiple *independent* contexts, the working set grows with the number of contexts.
This option is even worse really when you consider how many people actually wish to sit in front of CS department machines to code all day. I know I don't.
All of the terminals in the department I'm in run Unix (solaris on the older Sun machines, Linux on the newer PCs). Virtually all of the students are doing their coding at school; they don't have coding environments installed at home.
Students occasionally code at home, but the code _has_ to be transferred to our network eventually - we require that code be submitted via our environment (submitXYZ123 [assignment number] [filenames]), and the code must _work_ on our environment - it's what we'll be marking on!
Given that the code must build on our environment (to be marked) and be submitted from our environment, most students just use the university computers.
I don't think this is a terribly draconian requirement. Anything else would be a *tremendous* hassle for the teaching assistants, and it's at worst a very minor inconvenience for the students (the coding environment is decent).
You might think so... however, having administered a course doing something similar (saving versions of students' source) it grows faster than you think. Take 300 students x 30 files each x saving every hour for a semester. It pushed the limits of the network-replicated storage the class was allocated (even taking unmodified files into account).
Point taken, but I was thinking more along the lines of every 6 hours for the half-dozen (maximum) files for a specific assignment, for the couple of weeks that the assignment is running (we'd do any plagarism checking promptly, and then delete the archives and just keep what was officially submitted). This gets you between one and two orders of magnitude savings.
I too have helped manage assignments (grad school means being a teaching assistant):).
The best solution I've heard of is simply to require the students to maintain their code on a public CVS repository. Then their changelog will tell the story of whether they really wrote the code themselves, or copied it wholesale from someone else the night before it was due.
Another option would be to force them to use a specific working directory, and get the admin to set up a shell script to mass-archive all studuents' work every 6 hours or so. If the script just picks code files (as opposed to object and binary files), the space required will be miniscule.
This would require less knowledge on the part of the student to implement, and would accomplish the same goal.
Question - could you make aluminum transparent on some wavelengths by packing it with an array of voids of size comparable to a wavelength of light?
If I understand correctly, this will allow light of a matching wavelength to pass through.
OTOH, if it's more than a few wavelengths thick, it will be very frequency-selecive, so you'd still block virtually all light. And building this extrememely ordered structure is left as an exercise for the reader. I'm just wondering if this or similar patterning would work.
AMD claims it's not a bug with the Athlon processor, but with the motherboard
According to young bald children everywhere, "There is no bug".
In related news, the motherboard manufacturers are quoted as saying, "It's not a bug with the motherboard, but with the Athlon processor."
Funny, I didn't think I was bald...
It's an Athlon bug if you think doing speculative writes is a bug.
It's a motherboard chipset bug if you think that the AGP controller should play nicely with cache-coherence protocols (right now it doesn't, presumably to gain a speed boost).
It's an OS bug if you think that the OS should be bright enough not to make AGP-touched memory cacheable (it wasn't intended to be).
Not that I buy into this stuff, but it occurs to me that an experiment like that is fairly simplistic. Try putting subjects into a room to see if they can detect the presence or absence of vitamin C -- do your results call scurvy into question?
The difference is that these people claim to be able to detect the (immediate) presence or absence of electromagnetic fields.
I make no claims of being able to detect whether my orange juice really contains vitamin C by tasting it.
why haven't AMD gone with the MHz doesn't equal performance as they have done with the new XP/MP chips, as it would be assumed the market for these will be consumers who don't generally look at benchmark figures?
My guess: Because they don't want to compete with *themselves*.
If a consumer sees a Duron rated to "1.3 GHz" (1300 MHz), and an Athlon XYZ rated to "1600 FooUnits", which will they want?
Right.
The fact that Celeron clock numbers are no better than Duron numbers is icing on the cake.
For example, if every footsoldier has the survivability of a light APC and the punch of one as well due to the increased load bearing capacity, this obviously lends a serious edge to that army.
Would it?
You could, for example, outfit each soldier to be able to move at superhuman speed, and carry a couple of tons of equipment... but wouldn't it make more sense just to give that soldier a jeep? Same capabilities, and lower complexity and cost.
Want to be able to move over any kind of terrain? Send a helicopter instead of a jeep.
An exoskeleton is basically a vehicle optimized to mimic human mobility ranges. Which is silly - optimize a vehicle to work as a vehicle, and it'll be simpler and more efficient.
Exoskeletons are really, really cool, and I want one too, but I don't think they'd be terribly useful in war, for the same reason that jet packs aren't (conventional vehicles do the job better).
There are two big unsolved problems with "extreme ultraviolet" lithography, which is really X-ray lithography. First, you need a coherent X-ray source. The proposed options are a synchrotron, which is big (house-sized) and expensive, or an X-ray laser, which nobody has yet made work. Sandia has claimed a laser-pumped "plasma" source, but it doesn't yet have enough power to do the job.
Or, you can use a frequency-doubled UV laser (frequency-doubled Ar:F lasers are the current favourite, if memory serves).
Shining a laser beam through certain types of material produces an output beam that contains frequencies that are harmonics of the input beam's frequency, due to nonlinear interactions between the incident beam and the electrons in the material.
This has been used as a tool in the lab for years, and has been under intense investigation for lithography for quite a while now. My understanding is that frequency-doubled EUV sources are already shipping.
Extreme Ultraviolet LLC has built the first ultraviolet lithography stand for manufacturing processors.
Um, we've been using UV for a while now. This company has built the first _Extreme_ UV rig. This is especially obvious as a press release when you realize that they can define EUV as beginning more or less wherever they feel like. The term "EUV" was coined when "X-Rays" got a bad name in lithography circles (it used to be "deep UV", "Soft X-Rays", "Hard X-Rays").
Will this make silicone obsolete?
a) "Silicon".
b) No.
The article says:
"EUV technology is very extendable...and we have demonstrated that it would work down to the 30-nanometer level," Gwyn said.
Barring a new invention, which is always possible, "It should take us to the end of silicon...as we know it today," he said.
In english: The limits of silicon technology will run out before the limits of EUV technology.
They're not ending silicon - they're saying that as long as silicon will be around, photolithography will be around.
Start with any light whose energy is broad on the spectrum, add a low energy but very narrowly focused spike of green, and these guys would call the color "green" because of a single spike on a spectrogram. Color perception is computed by an integral of intensity over wavelength, not by looking at the highest intensity peek.
To nit-pick, because it's 1:30am and I'm bored:
The sun's emission spectrum is a blackbody curve. Most of its light emission is near the high-frequency end of this curve. Thus, if the peak is in the green range, most of the rest of its light emission will be *near* that range.
While I agree that the sun doesn't look green ("yellow-white" was the term used by the FAQ referred to previously), to say that the argument is completely misleading is silly. This isn't a little, narrow spike - it's a great big wide peak at the crest of a quickly rising curve.
Slashdot Mirror
After doing further research, I've come across a second operating principle used to make coilguns, which is closer to what the original poster described.
As a conductor resists changes to the local magnetic field (Lenz's Law, cited above), if you set up a moving magnetic field, the projectile will tend to follow it.
Note that the projectile is not "attracted into the coil", as the original article stated. Rather, if you're turning coils on and off in sequence along the gun, the projectile will be repelled by the moving field as it approaches, and dragged along with it (attracted) as it passes. The projectile *won't* just follow along with the first pulse in the moving field, either - it's just tugged briefly in the same direction. You'd have to send a train of moving field pulses over it to bring it up to the speed of the train, and it'll never quite get there (as the speed of the projectile approaches that of the moving pulse train, the pulses pass with lower frequency, so the projectile's efficiency as an inductor drops).
You don't gain much drift-resistance, either. While the projectile is no longer actively perturbed off-axis (as with the previous style of coilgun I described), nothing keeps it on the axis either. You still need active correction (or rails).
You're also wasting more power, because you have to keep many coils (those around the projectile) oscillating instead of just the coil behind the projectile.
This coilgun still does not require a ferromagnetic projectile, though ferromagnetism doesn't actively harm this type of gun.
I've spotted multiple errors in this person's page. It looks like he was cribbing notes from a more informed paper.
Problems I've found:
The authour claims that coilgun coils attract the projectiles. This is not correct. They work by repulson (by Lenz's Law, the induced field in the conducting slug repels the coil's field).
The authour does handwaving towards the 3-body problem to support his claim that you can't figure out what the best configuration of a coilgun is. These are completely unrelated problems. The 3-body problem is hard because the system a) has no general closed-form solution and b) is chaotic, so you can't even approximate a closed-form solution for many configurations.
A coilgun, on the other hand, just has more variables than you need. You don't have one optimal coilgun - you have an infinite number of optimal coilguns. Pick some of your parameters to be convenient, and solve for the others.
It's not hard to calculate how strong the induced field will be in a coilgun, or the force transferred to the projectile. It's also not hard to calculate how a capacitor-driven system will behave (hint: consider the coil's inductance with and without the slug inside it, and you can figure out how the energy transfer works).
If you're building a tabletop coilgun, you don't have to worry about energy storage. Just get a good DC supply, set up the coils in parallel with capacitors to get a nice LC tank circuit, and set up a transistor on each coil driven off an extra turn of the coil (or a secondary coil) just as you'd set up an RF signal generator. You're going to put at most a few hundred joules into your projectile (and that's if you're heaving aluminum pipe segments across the street). Exotic solutions are only needed if you're trying to shell a neighbouring city.
As driving frequency goes up (or pulse length shortens), inductive effects become important. This is how a real coilgun works - it's driven by inductive repulsion of a conducting slug. If you have an iron slug, a) attractive and repulsive forces will fight each other (or you can think of it as induced currents shielding the slug from your applied magnetic field).
Magnetic slugs only work for tabletop devices with slow firing speeds.
He's using a metal pipe as a guide for the projectile. A closed pipe would shield the inside of the tube just as a conducting projectile shields itself. He cuts a slot through the length of the pipe to avoid this, but you still have very high induced voltages around the pipe. A coilgun that switches at any decent speed with a strong magnetic field will induce currents that arc across this gap.
If you want a projectile guide, use rails.
If you want an elegant solution, let the slug move through open air and use secondary coils to adjust the geometry of the magnetic field as the projectile passes through to nudge it back into line if you notice it drifting. But this is not trivial to implement.
If you want to centralize administration, and don't really care what happens underneath that, why not just maintain a reference Windows machine, take drive images, and re-image the drives of the lab machines (over the network) on a weekly basis?
There's software available to automatically do this for NT-based systems (a few parts of the university I'm at do that). Or, you could set up a few shell scripts on a small *nix partition on each machine to do the same thing.
You'd have to make sure that you had only one or a small number of hardware and software configurations throughout the labs, but that tends to happen anyways (machines are bought en masse, and there are only a few departments you're responsible for).
I'm not sure what a thin client solution would buy you over this, and it would introduce additional headaches (having to maintain a very powerful server to serve all of the clients, for one thing).
I don't think it's fair to allow the computer to "judge" modem players' moves, and try to determine "if" the player would have got the hit. Not only is this unfair to the player (when they get to a real LAN tournament they'll be roasted), it's also unfair to the vet with a decent connection, because the newbie in essense gets a free hit. I would propose figuring out better ways to communicate over the network instead of trying to second guess the players' moves with algorhythms.
If my connection to a game is rotten, there's nothing the game client or the game server can do about it.
If you're only getting 4 updates a second from the server, your client *has* to guess what the other players are doing until the server tells it what really happens, because the alternative is to have a 4 FPS update.
Likewise, if the server only gets 4 updates per second from your client, it *has* to guess what you want to do, because it can't read your mind. Most servers guess that you'll keep holding down the keys that you were holding when it last heard from you, which is a tolerable solution. What would you prefer them to do?
The networking code in most games is already as good as it can be. The interpolation code tends to vary from game to game, but the effects are usually the same.
4X AGP is a 32-bit 266 MHz bus. That's more throughput than possible with PCI.
Unless you buy into Intel's PCI-X, which is 64/133.
And most graphics cards are not limited by bus bandwidth with *any* flavour of AGP (see the various Tom's Hardware benchmarks). The usual limit is fill rate for new cards, and lack of geometry processing for old cards (assuming you're playing a new game). Textures are stored on-card by any sane game, so the only thing going across the bus is lists of triangles.
AGP doesn't have contention with other devices on the bus so it doesn't have to do any logic for mastering or controlling and can allocate all its clocks to doing a data transfer.
While this would be an issue for very short data transfers, graphics cards will likely be transferring large batches of data. This is done in burst mode, which gives one transfer per clock.
Why would you want PCI? The only advantage PCI gives is that you can hang multiple devices off of it. But while that lets you get multiple monitor support easier, it will really kill your limited bandwidth.
You have bandwidth to spare; all you'd be doing in a multi-monitor setup is sending the same triangle lists over the bus, not cutting and pasting image data or doing texturing. Have one one dominant card and leave the others snooping traffic, and you have zero extra overhead for this.
The real benefit of having multiple video cards is that it lets you easily do render farming for things like games. Have each card render half the screen, and copy all cards' partial renderings to one card's frame buffer. 32/33 PCI is too slow to be practical for this, but 64/66 has more than enough bandwidth. I studied the feasibility of this at one of my past jobs.
A fast CPU is nice, but how about upgrading the rest of the standard PC architecture and peripherals to the same level?
:P
Weren't we all suppose to be using high-speed serial connections by now instead of a cocktail of SCSI (1/2/3, wide, fast, hold the mayo), IDE (ATA-33/66/100), parallel, 8 bit serial, USB, Firewire, PS/2, PCI, ISA (which is finally disappearing), etc. Heck, I'd be happy if the motherboard ran at even half to a third the speed of the cpu.
The good news is that USB is well on its way to completely replacing serial and parallel ports, and that PCI has been the One True Bus for the past couple of years now. Everything south of the southbridge is slowly fading away.
IMO, if we'd switched to 66 MHz 64-bit PCI years ago, we'd have no further problems on this front. In practice, PCI-X may finally be pushed through by Intel, and that will serve most internal communications needs. Motherboard chipsets are modular enough that it doesn't really matter what flavour of IDE/SCSI/firewire your drive is hanging off of; the drive controller is just another PCI device to the processor. You have enough bandwidth and DMA functionality on PCI bus to handle it.
The only peripherals that are currently bottlenecks are RAM and the video card. RAM is handled by upgrading the memory bus every couple of years. This is easy to do, because peripherals don't care what happens on the other side of the northbridge. The video card was handled adequately by the hack that is AGP (64-bit 66 MHz PCI would have been a much better idea, but that wouldn't have given Intel its nice AGP port to license).
The only peripheral that *might* be a problem in the future will be the network card (when gigabit cards finally come into vogue), and that will probably be what forces motherboard makers to put wider/faster PCI on to midrange boards and not just high-end boards.
In summary, this is less of a problem than it first appears to be.
The only serious bottleneck for performance is RAM latency, and that's not because of legacy peripherals.
Also, wasn't this inevitable. There are a few Beowulf jokes being posted, but that's really what's going on. Increasingly high performance tasks (Google, render farms etc. etc. etc.) are using massive arrays of low-power CPUs. It costs a lot of money to develop big iron chips, and if people aren't buying them then there's no point in investing that much money.
The problem is that a massively parallel computer is only useful for certain classes of problem. There are many types of problem where communications load goes up very rapidly with the number of processors, which makes a cluster (with its relatively poor communications bandwidth) impractical. This is what Big Iron is designed to be useful for.
My point was that they need to focus more on researching those fields rather than on clock speed.
[...]
Now, im not talking about making lead into gold, im just saying its almost obvious if you want technologically superior chips, you need to invest in the obvious bottleneck, not what the marketing department says is most effective.
And my point is that Intel will market what they expect to be able to put on the shelves next year. *That's* why you hear about their other processor tweaks.
Of *course* Intel is spending money on improving their memory subsystems! But you don't hear about it, because they haven't made any breakthroughs yet (RamBus was the last proposed improvement they invested in, and that failed spectacularly).
It is also in Intel's interest to invest in improvements that are likely to bear fruit quickly. Improving the memory subsystem isn't the only way to improve processor performance, so they're investigating other methods as well.
Oh, I don't know about that. The PA-8700 has 2.25 MB of L2 cache, which is okay I suppose. The MIPS R14000 processors in the SGI Origin 3000 series have 8 MB of L2 cache per CPU, and they do pretty well, to put it mildly.
Large amounts of cache benefit niche applications. You see huge caches on server chips because a) they happen to run this kind of niche load, and b) servers are optimized for performance above all else, which means a performance gain of a few percent is worth the cost of adding more cache (while a consumer would balk at paying twice as much).
Cache benefits servers that are running many, many tasks at once - a context switch won't necessarily end up purging the cache if it's big enough. Consumer machines don't usually have this kind of load (or we'd all be running dual-processor machines).
Some scientific applications will benefit, but only some of them. The rest either have access patterns that don't lend themselves to cacheing, or use blocking techniques to increase locality enough that even a smaller cache will be adequate (incremental return becomes low beyond a certain point).
For the vast majority of applications, we're already well into the realm of diminishing returns. Simple proof of this: We've had 256k and 512k caches on consumer chips for quite a while. Linewidth is fine enough that we have the ability to put much more cache on without taking a yield penalty. If doubling the cache size was a sure-fire performance boost for consumer chips, both Intel and AMD would have done it already.
Maybe instead of constantly worrying about clock speeds they spend more research into being able to add larger amounts of cache or try to achieve one clock cycle access to main memory
I'm afraid that both of these (especially the last one) sound like the infamous "let's just find a way to factor huge numbers" quote. That is - yes, it would be wonderful to be able to do this, but there are good reasons for believing that it's very difficult (not that people haven't tried).
For caches, the problem is that larger caches are slower and more power-hungry. To compensate, you use a multilevel cache architecture, but you still have some penalties. A modern foundry could put as much cache as it wanted on to a chip (look at HP's most recent chip for an example) - but because of architectural tradeoffs, this isn't always a good idea.
For memory, if you can find a way to get single-clock access latencies reliably without a 10x slower clock, sell it to $favourite_company and retire on the proceeds. This isn't likely to happen for _two_ reasons. Firstly, modern memory is optimized for density at the expense of speed (this is why we use DRAM and not SRAM for system memory). Secondly, because of the trace lengths, capacitance (and inductance!), and crosstalk and noise issues, it's one _hell_ of a lot harder to send data at low latency _or_ low bandwidth across a motherboard than just within a chip.
There are ways of pushing the boundaries on all of these things, but while we're doing that, processor speeds are still getting faster, putting tougher requirements on the memory and negating most of the relative gain.
In summary, there's a good reason that Intel (along with everyone else) is pursuing more conventional enhancements while background research into memory and caches is going on.
Most nearsightedness [allaboutvision.com] and farsightedness [allaboutvision.com] is caused by the eye, and consequently the retina, not being in the correct shape.The image is formed either too far ahead or behind the retina.
I read the article but I didn't see any mention of how the beam would project on malformed retinas.
As long as the rays from the scanner converge on one point near the surface of your eye, this problem should be greatly reduced.
Take an old-fashioned camera, and set the aperture to something wide (low F number). Then play with the focus. Focus has to be very finely adjusted.
Now set the aperture to something narrow (high F number). Much more of the scene looks sharp - imaging is less sensitive to focus.
I'm told that retina-scanning projectors produce much the same effect (haven't tried one myself, unfortunately).
Nuclear systems would be big, heavy, and only get about twice the fuel efficiency of the standard rockets they use now; ion propulsion, running on solar cells, gets ten times the efficiency of a standard rocket.
You could use a radiothermal electric generator to power an ion drive. This will approach solar-powered ion drive efficiencies if the weight of the RTG is comparable to or less than the weight of the solar panels you'd normally put on an ion-drive craft.
This would only be better than solar power for craft that would be far from the sun (power to weight ratio for RTGs is pretty lousy, if I recall correctly), but craft like this could certainly be built.
Among other things, this is the best way that I can think of to survey multiple bodies in the Kupier Belt.
Next, 3 MB cache sounds nice, but L3? It may be on die, but by that point the clock reduction probably makes it perform equivalently to a 256 k L1 cache, or a 512 or larger L2.
A fundamental rule of building caches is that a larger cache is slower and dissipates more energy per lookup than a smaller cache. This is why multilevel cacheing exists in the first place (otherwise we'd just have a huge L1 cache - and before you mention it, due to architectural sneakiness, HP's giant L1 cache isn't really an L1 cache).
So, you can't just spend the L3 area on making a bigger L2. You'd end up with a slower, hotter L2, which could easily _degrade_ performance.
As long as the L3 cache is faster to access than main memory, it'll be useful for some things. Whether it'll be useful for *most* things is another issue. This depends on the "working set" of the applications you're running (how much memory they repeatedly access). I guess Intel's banking on working sets being larger than most caches.
Another possibility is that they're testing the cache architecture for use in future SMT or CMP designs (both of which would have multiple independent executioin contexts running). If you're running multiple *independent* contexts, the working set grows with the number of contexts.
This option is even worse really when you consider how many people actually wish to sit in front of CS department machines to code all day. I know I don't.
All of the terminals in the department I'm in run Unix (solaris on the older Sun machines, Linux on the newer PCs). Virtually all of the students are doing their coding at school; they don't have coding environments installed at home.
Students occasionally code at home, but the code _has_ to be transferred to our network eventually - we require that code be submitted via our environment (submitXYZ123 [assignment number] [filenames]), and the code must _work_ on our environment - it's what we'll be marking on!
Given that the code must build on our environment (to be marked) and be submitted from our environment, most students just use the university computers.
I don't think this is a terribly draconian requirement. Anything else would be a *tremendous* hassle for the teaching assistants, and it's at worst a very minor inconvenience for the students (the coding environment is decent).
You might think so... however, having administered a course doing something similar (saving versions of students' source) it grows faster than you think. Take 300 students x 30 files each x saving every hour for a semester. It pushed the limits of the network-replicated storage the class was allocated (even taking unmodified files into account).
:).
Point taken, but I was thinking more along the lines of every 6 hours for the half-dozen (maximum) files for a specific assignment, for the couple of weeks that the assignment is running (we'd do any plagarism checking promptly, and then delete the archives and just keep what was officially submitted). This gets you between one and two orders of magnitude savings.
I too have helped manage assignments (grad school means being a teaching assistant)
The best solution I've heard of is simply to require the students to maintain their code on a public CVS repository. Then their changelog will tell the story of whether they really wrote the code themselves, or copied it wholesale from someone else the night before it was due.
Another option would be to force them to use a specific working directory, and get the admin to set up a shell script to mass-archive all studuents' work every 6 hours or so. If the script just picks code files (as opposed to object and binary files), the space required will be miniscule.
This would require less knowledge on the part of the student to implement, and would accomplish the same goal.
Question - could you make aluminum transparent on some wavelengths by packing it with an array of voids of size comparable to a wavelength of light?
If I understand correctly, this will allow light of a matching wavelength to pass through.
OTOH, if it's more than a few wavelengths thick, it will be very frequency-selecive, so you'd still block virtually all light. And building this extrememely ordered structure is left as an exercise for the reader. I'm just wondering if this or similar patterning would work.
AMD claims it's not a bug with the Athlon processor, but with the motherboard
According to young bald children everywhere, "There is no bug".
In related news, the motherboard manufacturers are quoted as saying, "It's not a bug with the motherboard, but with the Athlon processor."
Funny, I didn't think I was bald...
It's an Athlon bug if you think doing speculative writes is a bug.
It's a motherboard chipset bug if you think that the AGP controller should play nicely with cache-coherence protocols (right now it doesn't, presumably to gain a speed boost).
It's an OS bug if you think that the OS should be bright enough not to make AGP-touched memory cacheable (it wasn't intended to be).
I'm voting for option 3), myself.
Not that I buy into this stuff, but it occurs to me that an experiment like that is fairly simplistic. Try putting subjects into a room to see if they can detect the presence or absence of vitamin C -- do your results call scurvy into question?
The difference is that these people claim to be able to detect the (immediate) presence or absence of electromagnetic fields.
I make no claims of being able to detect whether my orange juice really contains vitamin C by tasting it.
why haven't AMD gone with the MHz doesn't equal performance as they have done with the new XP/MP chips, as it would be assumed the market for these will be consumers who don't generally look at benchmark figures?
My guess: Because they don't want to compete with *themselves*.
If a consumer sees a Duron rated to "1.3 GHz" (1300 MHz), and an Athlon XYZ rated to "1600 FooUnits", which will they want?
Right.
The fact that Celeron clock numbers are no better than Duron numbers is icing on the cake.
For example, if every footsoldier has the survivability of a light APC and the punch of one as well due to the increased load bearing capacity, this obviously lends a serious edge to that army.
Would it?
You could, for example, outfit each soldier to be able to move at superhuman speed, and carry a couple of tons of equipment... but wouldn't it make more sense just to give that soldier a jeep? Same capabilities, and lower complexity and cost.
Want to be able to move over any kind of terrain? Send a helicopter instead of a jeep.
An exoskeleton is basically a vehicle optimized to mimic human mobility ranges. Which is silly - optimize a vehicle to work as a vehicle, and it'll be simpler and more efficient.
Exoskeletons are really, really cool, and I want one too, but I don't think they'd be terribly useful in war, for the same reason that jet packs aren't (conventional vehicles do the job better).
There are two big unsolved problems with "extreme ultraviolet" lithography, which is really X-ray lithography. First, you need a coherent X-ray source. The proposed options are a synchrotron, which is big (house-sized) and expensive, or an X-ray laser, which nobody has yet made work. Sandia has claimed a laser-pumped "plasma" source, but it doesn't yet have enough power to do the job.
Or, you can use a frequency-doubled UV laser (frequency-doubled Ar:F lasers are the current favourite, if memory serves).
Shining a laser beam through certain types of material produces an output beam that contains frequencies that are harmonics of the input beam's frequency, due to nonlinear interactions between the incident beam and the electrons in the material.
This has been used as a tool in the lab for years, and has been under intense investigation for lithography for quite a while now. My understanding is that frequency-doubled EUV sources are already shipping.
Only on slashdot can one read a flamewar between intelligent people on what color the sun is.
What color is the sun in YOUR world?
Green.
No! Yellow!
Aaaaaaaaaagh!
;)
Extreme Ultraviolet LLC has built the first ultraviolet lithography stand for manufacturing processors.
Um, we've been using UV for a while now. This company has built the first _Extreme_ UV rig. This is especially obvious as a press release when you realize that they can define EUV as beginning more or less wherever they feel like. The term "EUV" was coined when "X-Rays" got a bad name in lithography circles (it used to be "deep UV", "Soft X-Rays", "Hard X-Rays").
Will this make silicone obsolete?
a) "Silicon".
b) No.
The article says:
"EUV technology is very extendable...and we have demonstrated that it would work down to the 30-nanometer level," Gwyn said.
Barring a new invention, which is always possible, "It should take us to the end of silicon...as we know it today," he said.
In english: The limits of silicon technology will run out before the limits of EUV technology.
They're not ending silicon - they're saying that as long as silicon will be around, photolithography will be around.
Bullshit.
Start with any light whose energy is broad on the spectrum, add a low energy but very narrowly focused spike of green, and these guys would call the color "green" because of a single spike on a spectrogram. Color perception is computed by an integral of intensity over wavelength, not by looking at the highest intensity peek.
To nit-pick, because it's 1:30am and I'm bored:
The sun's emission spectrum is a blackbody curve. Most of its light emission is near the high-frequency end of this curve. Thus, if the peak is in the green range, most of the rest of its light emission will be *near* that range.
While I agree that the sun doesn't look green ("yellow-white" was the term used by the FAQ referred to previously), to say that the argument is completely misleading is silly. This isn't a little, narrow spike - it's a great big wide peak at the crest of a quickly rising curve.
And on that note, I'm going to bed.