A lot of fiber gets dark when the company upgrades. They run a more capable cable down the same pipe, and light it up.
So now you have this old cable running next to a new one, but it costs too much to run both at the same time. (Routing issues, maintenence, equipment cost, etc.) So you leave the old fiber dark.
When I was in elementary school, I had a third-hand 386 laptop. I loved it...I played with QBASIC on road trips, and really had a blast. But it was a 12" screen, and the contrast control was horrid.
I've got a Zire 21. Best damn thing I've ever owned. Battery lasts a long time...I've only had to recharge it three times since Christmas. (when I got it.)
That makes me wonder...could CPUs be dynamically clocked for short periods of time based on scheduling? Perhaps even overclocking for time slices of process with the root password entered three times, then underclocked for operations with low priority.
I've seen the scheduling options that come with stock 2.6.3, and there's not a whole lot of variety.
Also, a lot of the work that went into the original moon landings needn't be repeated. We have Velcro, mylar, technology for various reentry methods, gel pens...In other words, a lot of stuff we're not going to need to re-invent.
If it runs Linux, chances are someone's going to port KOrganizer and KMail to it. I don't use KDE personally, but I'd be surprised if you couldn't sync with the populer OSS office suites.
Well, x86 has vector operations in mmx, sse and sse2.
Rather than add on more extensions, you can crank up the performance of existing extensions by performing more operations per second.
Of course, with that gargauntuan pipeline, you're going to lose some of that performance. But not much, if you're doing data whose operations don't require the results of previous calculations.
One thing that always irks me is that people get so freaked out about framerates. Before my current card (ATI Radeon 9000, which I installed only a month ago), I was on a Riva TNT2, and before that, I was on an original Voodoo.
I'm used to 14 to 15 fps in Quake 1. And I can play (and whip just about anyone's butt in CTF) at that framerate, no problem.
As an aside, I can hear some digital watches, NTSC displays, VGA monitors monitors up to 1280x960@75Hz, really old hubs, and some wierd whistling sounds that I encounter in both Vorbis and MPEG compressed audio. Especially during applause.
You do run into one problem; is your 75 frames from your refresh rate synced with your rendering? I'd hope not.
Rendering software found in games generally doesn't keep track of the refresh rate of the monitor. In fact, I don't know that any rendering software outside your graphics provider (X under Linux, Windows has its own.) depends on the refresh rate of the monitor. Even then, I think the refresh rates and dot clock are used to control the resolution, not the actual drawing.
What that means is your game can keep drawing new frames to represent the absolute latest state in the physics envrinment (position of moving bodies, ect.), and have that latest frame ready when when the next scan proceeds on your display.
If your rendering was slowed to coincide with your refresh rate, only one frame would be rendered per screen redraw, which means that the frame could be as old as just barely after your previous redraw. Depending on how your OS's scheduling, you might even miss drawing a frame, which could cause you to offset. That could lead to a desyncing of audio and video, so the smart thing for an app to do if it finds itself behind schedule is to simply skip the frame. (I don't think that'd be as much of a problem if your physics and rendering were in two separate threads.)
If you dropped a frame, the viewer would probably notice it. Especially at lower refresh rates. At higher ones, they might not be able to explain what they saw, but it would probably cause some minor measure of confusion.
If you held onto that frame and wound up with an offset, the viewer would definately notice a desyncing of audio and video over the course of the game, and you might end up with other programmatical errors resulting from too many held frames.
Well, use something like HyperTransport over a short distance for a couple(or more) PCI cards.
What...is PCI a dirty word now?
Configure as many cards as you like to monitor the graphics commands on the PCI bus. Then have the cards dump rendered video back over the HT link to the master card. The master card would be decided automatically, since it would be the only card with a display plugged in.
Also, instead of mirroring data, you could have the cards pool their memory. That would be especially advantageous if you wanted to link four or five cards together, but wanted to run two displays, since each display could, with optimised drivers, primarily work with the data closest to it, yet be able to take memory from other cards as needed, you wind up with a synergistic (ack!) relationship.
While you technically won't multiply your performance by the number of cards you have, you'll still do better than the average card.
Finally, once PCI Express becomes standard (in, oh, I'd guess three years), AGP won't have an advantage over PCI, anyway.
Slashdot Mirror
I'd like to see an event-driven PDA, where the hardware is only running to process events, not for background tasks like redrawing the screen.
E ink could get us closer.
It's "eeenk" as in "We don't need no steeenking badges."
How about E Ink, Inc. ?
If you're only using one big AP, or you're only using one connection to the rest of the world, that's correct.
However, if you have several AP's and multiple, decentralized connections to the internet, then your overall bandwidth won't be as congested.
A lot of fiber gets dark when the company upgrades. They run a more capable cable down the same pipe, and light it up.
So now you have this old cable running next to a new one, but it costs too much to run both at the same time. (Routing issues, maintenence, equipment cost, etc.) So you leave the old fiber dark.
That second shouldn't cause carpel tunnel.
Hold your arm up, but leave your hand limp. See? Already properly shaped...A gripping thought, isn't it?
That was Ashley Judd? I'm going to have to go back and look at that article again.
You know, if I were Dr. Crusher, I wouldn't be happy to have my son laying on a bed with a girl...even with the mind-control device.
But as a viewer, I'll say what my step-dad said when I got caught viewing pr0n in 4th grade: "Way to go!"
When I was in elementary school, I had a third-hand 386 laptop. I loved it...I played with QBASIC on road trips, and really had a blast. But it was a 12" screen, and the contrast control was horrid.
I've got a Zire 21. Best damn thing I've ever owned. Battery lasts a long time...I've only had to recharge it three times since Christmas. (when I got it.)
That makes me wonder...could CPUs be dynamically clocked for short periods of time based on scheduling? Perhaps even overclocking for time slices of process with the root password entered three times, then underclocked for operations with low priority.
I've seen the scheduling options that come with stock 2.6.3, and there's not a whole lot of variety.
Yikes. They must be plotting to take over our network infrastructure. Imagine that.
Also, a lot of the work that went into the original moon landings needn't be repeated. We have Velcro, mylar, technology for various reentry methods, gel pens...In other words, a lot of stuff we're not going to need to re-invent.
If it runs Linux, chances are someone's going to port KOrganizer and KMail to it. I don't use KDE personally, but I'd be surprised if you couldn't sync with the populer OSS office suites.
Uh, that's a takeoff on a quote attributed to American congressman Everett Dirksen. "A billion here, a billion there, pretty soon you're talking about real money."
Just because there's a resisting force doesn't mean that force can't be overcome. That's the basis for any epic story.
Also, Vorbis(the audio codec normally associated with Ogg) doesn't even use Fraunhofer material.
Great for deep-see fishing, though. I wonder if my grandfather calls em "Warbly"
audio artifacts circling your head? Like an Ioune stone? I'm going to have to add that one to my D&D campaign.
Well, x86 has vector operations in mmx, sse and sse2.
Rather than add on more extensions, you can crank up the performance of existing extensions by performing more operations per second.
Of course, with that gargauntuan pipeline, you're going to lose some of that performance. But not much, if you're doing data whose operations don't require the results of previous calculations.
Well, shoot. If you had a registry editor, you could have set the drive to work in PIO mode. (Assuming you could find the registry setting.)
But the fact that DMA didn't work suggets that the drive was dying anyway, so, yeah, replacement was a good idea.
One thing that always irks me is that people get so freaked out about framerates. Before my current card (ATI Radeon 9000, which I installed only a month ago), I was on a Riva TNT2, and before that, I was on an original Voodoo.
I'm used to 14 to 15 fps in Quake 1. And I can play (and whip just about anyone's butt in CTF) at that framerate, no problem.
As an aside, I can hear some digital watches, NTSC displays, VGA monitors monitors up to 1280x960@75Hz, really old hubs, and some wierd whistling sounds that I encounter in both Vorbis and MPEG compressed audio. Especially during applause.
I think there's a significan advantage to having a framerate not linked to your refresh rate. See my other post.
You do run into one problem; is your 75 frames from your refresh rate synced with your rendering? I'd hope not.
Rendering software found in games generally doesn't keep track of the refresh rate of the monitor. In fact, I don't know that any rendering software outside your graphics provider (X under Linux, Windows has its own.) depends on the refresh rate of the monitor. Even then, I think the refresh rates and dot clock are used to control the resolution, not the actual drawing.
What that means is your game can keep drawing new frames to represent the absolute latest state in the physics envrinment (position of moving bodies, ect.), and have that latest frame ready when when the next scan proceeds on your display.
If your rendering was slowed to coincide with your refresh rate, only one frame would be rendered per screen redraw, which means that the frame could be as old as just barely after your previous redraw. Depending on how your OS's scheduling, you might even miss drawing a frame, which could cause you to offset. That could lead to a desyncing of audio and video, so the smart thing for an app to do if it finds itself behind schedule is to simply skip the frame. (I don't think that'd be as much of a problem if your physics and rendering were in two separate threads.)
If you dropped a frame, the viewer would probably notice it. Especially at lower refresh rates. At higher ones, they might not be able to explain what they saw, but it would probably cause some minor measure of confusion.
If you held onto that frame and wound up with an offset, the viewer would definately notice a desyncing of audio and video over the course of the game, and you might end up with other programmatical errors resulting from too many held frames.
Well, use something like HyperTransport over a short distance for a couple(or more) PCI cards.
What...is PCI a dirty word now?
Configure as many cards as you like to monitor the graphics commands on the PCI bus. Then have the cards dump rendered video back over the HT link to the master card. The master card would be decided automatically, since it would be the only card with a display plugged in.
Also, instead of mirroring data, you could have the cards pool their memory. That would be especially advantageous if you wanted to link four or five cards together, but wanted to run two displays, since each display could, with optimised drivers, primarily work with the data closest to it, yet be able to take memory from other cards as needed, you wind up with a synergistic (ack!) relationship.
While you technically won't multiply your performance by the number of cards you have, you'll still do better than the average card.
Finally, once PCI Express becomes standard (in, oh, I'd guess three years), AGP won't have an advantage over PCI, anyway.
You know, overclocking two cpus in an SMP situation might be neat.
I don't know a whole lot about SMP architectural hardware requirements, but it'd be great to read about it.