With the 2.2 series kernels, you have to manually enable DMA transfers, using 'hdparm'. In 2.4, you can compile the IDE driver with the option to enable DMA automatically.
Try doing: hdparm -d1 -m16/dev/hda (and do the same to your other drives).
Then try again. If you're not using DMA mode, the IDE IO subsystem really takes a knock when reading/writing, and will slow your whole box to a halt. I can happy encode a DVD (see drip.sourceforge.net) while compiling a kernel and whatever else, while listening to silky smooth audio. (And I'm not special or anything:)
Well, for the record I have regularly ripped CD's using 2.2.xx, 2.3.xx and 2.4.xx kernels, with xmms playing, and not had a skip.
Firstly, are those tests done with DMA enabled on the IDE devices?
Secondly, where on earth did they get the 5.8ms figure from? Some math:
0.0058s * 44100 * 2 * 2 = 1024 byte audio buffer.
Sir, that is rubbish. The global audio buffer is 65536 bytes (unless somebody does funny things with ALSA or something). I have had enough experience programming sound cards on the hardware driver level to understand the ins and outs, and unless I'm missing something seriously fundamental (I'm probably lacking in linux-kernel specific knowledge), those figures are quite skewed.
Does xmms normally skip a beat without the pre-emptive patch? I swear, I've only ever had xmms skip when spinning up a powered-down hard drive, or when my loadavg goes above 15, and that on a much more modest box.
I have heard only good things about the pre-emptive (or pre-emtible, whatever the correct name is), but let's not forget that xmms uses a sound buffer several seconds long, of which it would play 64k chunks at a time, which at worst means the kernel needs to service and swap DMA buffers 3 times per second (65536/(44100*2*2) = 372ms) with basically no decoding/mixing overhead for up to several seconds at a time.
If you're getting a latency longer than 350ms, you've got bigger problems. Just my £0.02
You can start counting at 0, but when you reach 14 you've counted 15 numbers, and I do believe "14-and-counting" alludes to the number of point-releases counted.
"from the point-release-14-and-counting-dept." would be more accurate, but I'll try not to lose any sleep over it. *yawn*
Buy a Suzuki GSX-1300R (~150bhp on the back wheel from the factory).
Fit a decent turbocharger with a dump-valve to smooth out the gearchanges.
Engineer the head to raise it slightly (decreasing the compression ratio for the turbo)
Tune the turbo to kick in at about 5000rpm
Get the engine dyno-tuned, for completeness.
Seriously - there is a nice company in the UK which does this as a standard modification to the Hyabusa (GSX-1300R) and a prominant bike magazine tested one themselves and found 348bhp on the back wheel. And I can almost guarantee you that the bike was more rideable, because you'd only get the insane power when you MEAN business by twisting the throttle at above 5000rpm. The test rider says the front wheel would lift under acceleration when already doing 240kph...
More power for a fraction of the cost.
*AND* this isn't butt-ugly like that horrible silver piece of shit for $150,000.
Actually, you get primary colours for paint/ink/dye, and you get primary colours for light.
Paint colours mix colour SUBTRACTIVELY, and light colours mix ADDITIVELY. The cones in your eyes really *are* sensitive to the red, green, and blue primary colours because you see light, not paint.
I don't remember if it was on Slashdot or not, but yes - I saw this last year too. It's getting a little old now.
A small bit of theory will make you realise that the only reason RGB works is because it stimulates the 3 different types of cones in our eyes (which are sensitive to 3 different sets of ranges of wavelengths of light) in a similar manner as light of a single frequency. What you see coming out of your monitor is usually nothing like the single wavelength of light which truly makes up the colour you perceive.
"The HDCP system can't be broken". Who knows, with a handful of xor logic gates and some transistors, a 16 year old european kid may just succeed:)
And no, D-VHS will not replace DVD - not at over $12000 just to watch the bloody thing. And now that everyone's used to being able to view interactively on one's PC, who wants to go back to TV?!
I would reckon that as soon as someone figures out how to grab the video content, we'll be back to trading mpeg4's over the internet again. Goodbye "non-piracy" theory. Information will always win in the end.
...that the future as prophesied by Parallax Software in their hallowed work "Descent", would be dominated by the Post Terran Mining Corporation (PTMC) and mankind's endless quest for minerals, and blowing up robots.
...at how bad the online security of some banks can be. The largest bank in my country (and on my continent) has at least one firewall box I know of which lets you *telnet* into it, log in as root. The clincher? IT HAS NO ROOT PASSWORD. And once you're in would be easy to get to whatever info you want because the sysadmins don't believe in secure connections. Heck, port 23 is just *fine* with them.
And another bank here which runs it's online services on IIS had left it with all the default settings *AND* passwords! Luckily a third party IT company discovered it while doing some unrelated work and that at least has now been fixed.
The moral of the story? I don't trust the buggers. They're bad enough with hard cash (read: thieving bastards) what makes you think you can trust them with something as temporal as a few bits and bytes on an electronic communication meduim. That's what your money ends up as...
In my opinion, a lot of things still have to mature before I am comfortable with the idea of doing business online with a bank.
OK so this is a day late and it will never be read or moderated but here goes anyway...
Any realtime user-input orientated application would be a very amateurish production if it's control mechanism were dependant upon the output mechanism. Think back to the original BASIC nibbles games we used to play on our XT's.
Sorry, but for many years now games have been running "interrupt" driven control mechanisms and CPU-speed-limited output mechanisms. This would mean, for example, that exactly as the user presses, say, FIRE, that keypress event is inserted into an event queue with an exact timestamp (frame independant). Upon the next frame/physics engine update, the time difference between the event timestamp and the exact time at the beginning of the frame/physics processing, would be used to accurately "predict" where the rocket (for instance) should be, taking into account player movement and direction changes, etc. So FPS *should* be irrelevant to the physics and control of a game.
However, a human interacts with something like a game using realtime input/feedback, meaning that you constantly recalibrate your movements and keypresses in the game based on the current display output. This is where higher FPS will give you an edge - you get to see your movement/change faster, and therefore you calibrate sooner, becoming more accurate, and this, linked with a fast enough refresh to give your visual cortex the illusion of fluid motion, is what makes a game feel "smooth". The simplest example I can think of regarding this, would be moving your mouse cursor in your GUI.
A hint for Q3A players: Get your monitor running at the highest frequency it can in the resolution you choose - say, 85Hz for example - and then add a few to that number and set the maximum displayed FPS to that figure, by using the "\com_maxfps" command, eg, "\com_maxfps 88".
And to do a bit more knit-picking, the linked article refers to "purple" as being a combination of "red" and "blue". This is untrue - every colour possible is only a combination of a unique light-wave frequency and intensity, meaning that all intensities of the colour "purple" have the same unique light frequency. However, the three types of cones in the human eye (each responding to stimuli from different wavelength-/frequency-ranges) interpret things slightly differently. A colour like purple will stimulate the "red-range" and "blue-range" cones about equally, and therefore an RGB display consisting of equal red and blue signals, with no green, will stimulate the same cones in the same way, thus giving the illusion of the colour purple.
16.8 million pixels...let's see...3 bytes minimum for truecolor:
16777216 * 3 = 50331648 = 48MB
Now that's a lot of data to be transferring around. I assume that any devices using this new technology will at least be transferring the photo data using USB or something...
BTW 16.8 megapixels is most-likely a 4096x4096 image. WOW! You could zoom in over 5x before getting a pixel ratio of 1:1 with the image on an 800x600 display.
Don't you remember where they found Fwiffo the Spathi in Star Control II? The prophets Fred Ford and Paul Reiche III were correct! Oh, here come those friendly men with the white jackets again...
Before you jump so quickly to flame mode, it would be a good idea for *you* to know what you are talking about.
The only 36bit thing about the PPro's is that it has 36bits of virtual address space, ie. 64Gb. Apart from that the CPU still has 8-, 16-, 32-, 64-, and some steppings have 128-bit instructions on them.
Then there's the issue of bus size - I'm not clued up at the moment as to the bus sizes of the different CPU's, but there you have another factor.
How how do you rate a CPU in "bits", I ask you? Cut the flames then, until you know what you are saying.
For my $0.02 on the topic, let me go through a bit of history:
8086: 20 bits of virtual RAM address space (thank you Bill Gates), giving 1Mb maximum RAM. 8bit and 16bit instructions, with an 8bit memory bus. Debut at 4.77Mhz
80286: Here is the first example in the x86 range of trying to maintain backwards ISA compatibility. The '286 had a 24bits of address space (16Mb) but in order to maintain compatibilty with a handful of 8086 programs, the designers did two very annoying things: 1) The A20 address line: without setting this stupid control line, the first 64kb of each 1Mb of RAM (excluding the first 1Mb) is inaccessible. Crazy! Just because some software on the XT relies on the fact that there will never be over 1Mb of RAM, and sometimes write to addresses higher than 1Mb knowing that the effective address would wrap around back to 0.... 2) 80286 Real Mode: The CPU still started up in "Real Mode" which prevents you from using any of the extended RAM you may have...you had to clumsily switch to 16 protected mode (a programmer's nightmare) to access the RAM. I wont go into the topic of Intel+M$+undocumented instructions right here.
80386: This was a huge jump up from the '286, with 32bits of virtual address space (4Gb), a whole new set of 32bit instructions, some extra registers and a whole different architecture. This CPU would have been *great* to start with, but for the good old "ISA backwards compatibility" issues Hannibal speaks of. It introduced 32bit Protected Mode, allowing multi-tasking and hardware task switching, etc, but it *still* booted into Real Mode. What a pain in the ass. And it would take programmers *years* before they begain to come to grips with the complications of switching between these CPU modes.
Ok, "So what's the point of all this useless information?" you ask...Well, it serves to illustrate the cumbersome and incredibly annoying way that the x86 CPU's of today operate: so much red tape to go through to get to the CPU's real power, because by default it limits you to good old 8086 days.....IMHO Intel should have phased out their old way of doing things and started afresh with the 386 - trust me, applications would have been a whole lot more stable and advanced if it wasn't for the *really* silly backward compatibility issues. And besides it would not have been terribly hard to create a "virtual machine" for the old 8086 software anyway...
So, x86, it's been real. Rest In Peace. And bring on the new stuff.
What they are describing is the phenomenon of the cesium emitting a light wave identical to the one entering it. The cesium is already in an excited state, and the leading-edge of the light wave sets off a very fast "reaction" which begins emitting a pulse of light out of the other side before the main pulse has entered the crystal.
The energy used to do this is then absorbed back into the cesium from the incoming light. Using the information in the article you could calculate that the leading edge of the light wave is a little under 60 feet long.
I dont suppose you've ever wondered what the tensile forces acting on the tube would amount to? The strongest substance known to man would disintegrate at a fraction of the speed of light due to the angular momentum.
Our friendly Telco monopoly here in South Africa has deemed DSL an illegal technology. We have imported two DSL modems and use them to link our two offices but we have to hide them whenever the telco engineers are about. A third party DSL provider would be great.
Re:Why don't you read the article?
on
Inside Transmeta
·
· Score: 1
Who's the idiot? The one who reads a statement as a Question would be considered an idiot. Good luck to you.
Slashdot Mirror
With the 2.2 series kernels, you have to manually enable DMA transfers, using 'hdparm'. In 2.4, you can compile the IDE driver with the option to enable DMA automatically.
/dev/hda (and do the same to your other drives).
:)
Try doing: hdparm -d1 -m16
Then try again. If you're not using DMA mode, the IDE IO subsystem really takes a knock when reading/writing, and will slow your whole box to a halt. I can happy encode a DVD (see drip.sourceforge.net) while compiling a kernel and whatever else, while listening to silky smooth audio. (And I'm not special or anything
Well, for the record I have regularly ripped CD's using 2.2.xx, 2.3.xx and 2.4.xx kernels, with xmms playing, and not had a skip.
Firstly, are those tests done with DMA enabled on the IDE devices?
Secondly, where on earth did they get the 5.8ms figure from? Some math:
0.0058s * 44100 * 2 * 2 = 1024 byte audio buffer.
Sir, that is rubbish. The global audio buffer is 65536 bytes (unless somebody does funny things with ALSA or something). I have had enough experience programming sound cards on the hardware driver level to understand the ins and outs, and unless I'm missing something seriously fundamental (I'm probably lacking in linux-kernel specific knowledge), those figures are quite skewed.
Does xmms normally skip a beat without the pre-emptive patch? I swear, I've only ever had xmms skip when spinning up a powered-down hard drive, or when my loadavg goes above 15, and that on a much more modest box.
I have heard only good things about the pre-emptive (or pre-emtible, whatever the correct name is), but let's not forget that xmms uses a sound buffer several seconds long, of which it would play 64k chunks at a time, which at worst means the kernel needs to service and swap DMA buffers 3 times per second (65536/(44100*2*2) = 372ms) with basically no decoding/mixing overhead for up to several seconds at a time.
If you're getting a latency longer than 350ms, you've got bigger problems. Just my £0.02
You can start counting at 0, but when you reach 14 you've counted 15 numbers, and I do believe "14-and-counting" alludes to the number of point-releases counted.
"from the point-release-14-and-counting-dept." would be more accurate, but I'll try not to lose any sleep over it. *yawn*
"from the 14-and-counting dept."
:)
We're actually at 15 (not 14) and counting - kernel version numbers are 0-based, and sequential.
Sorry moderators - I just had to
Buy a Suzuki GSX-1300R (~150bhp on the back wheel from the factory). Fit a decent turbocharger with a dump-valve to smooth out the gearchanges. Engineer the head to raise it slightly (decreasing the compression ratio for the turbo) Tune the turbo to kick in at about 5000rpm Get the engine dyno-tuned, for completeness.
Seriously - there is a nice company in the UK which does this as a standard modification to the Hyabusa (GSX-1300R) and a prominant bike magazine tested one themselves and found 348bhp on the back wheel. And I can almost guarantee you that the bike was more rideable, because you'd only get the insane power when you MEAN business by twisting the throttle at above 5000rpm. The test rider says the front wheel would lift under acceleration when already doing 240kph...
More power for a fraction of the cost.
*AND* this isn't butt-ugly like that horrible silver piece of shit for $150,000.
Paint colours mix colour SUBTRACTIVELY, and light colours mix ADDITIVELY. The cones in your eyes really *are* sensitive to the red, green, and blue primary colours because you see light, not paint.
A small bit of theory will make you realise that the only reason RGB works is because it stimulates the 3 different types of cones in our eyes (which are sensitive to 3 different sets of ranges of wavelengths of light) in a similar manner as light of a single frequency. What you see coming out of your monitor is usually nothing like the single wavelength of light which truly makes up the colour you perceive.
And no, D-VHS will not replace DVD - not at over $12000 just to watch the bloody thing. And now that everyone's used to being able to view interactively on one's PC, who wants to go back to TV?!
I would reckon that as soon as someone figures out how to grab the video content, we'll be back to trading mpeg4's over the internet again. Goodbye "non-piracy" theory. Information will always win in the end.
...that the future as prophesied by Parallax Software in their hallowed work "Descent", would be dominated by the Post Terran Mining Corporation (PTMC) and mankind's endless quest for minerals, and blowing up robots.
And another bank here which runs it's online services on IIS had left it with all the default settings *AND* passwords! Luckily a third party IT company discovered it while doing some unrelated work and that at least has now been fixed.
The moral of the story? I don't trust the buggers. They're bad enough with hard cash (read: thieving bastards) what makes you think you can trust them with something as temporal as a few bits and bytes on an electronic communication meduim. That's what your money ends up as...
In my opinion, a lot of things still have to mature before I am comfortable with the idea of doing business online with a bank.
I'm so ashamed of you I am even *trolling*
OK so this is a day late and it will never be read or moderated but here goes anyway... Any realtime user-input orientated application would be a very amateurish production if it's control mechanism were dependant upon the output mechanism. Think back to the original BASIC nibbles games we used to play on our XT's. Sorry, but for many years now games have been running "interrupt" driven control mechanisms and CPU-speed-limited output mechanisms. This would mean, for example, that exactly as the user presses, say, FIRE, that keypress event is inserted into an event queue with an exact timestamp (frame independant). Upon the next frame/physics engine update, the time difference between the event timestamp and the exact time at the beginning of the frame/physics processing, would be used to accurately "predict" where the rocket (for instance) should be, taking into account player movement and direction changes, etc. So FPS *should* be irrelevant to the physics and control of a game. However, a human interacts with something like a game using realtime input/feedback, meaning that you constantly recalibrate your movements and keypresses in the game based on the current display output. This is where higher FPS will give you an edge - you get to see your movement/change faster, and therefore you calibrate sooner, becoming more accurate, and this, linked with a fast enough refresh to give your visual cortex the illusion of fluid motion, is what makes a game feel "smooth". The simplest example I can think of regarding this, would be moving your mouse cursor in your GUI. A hint for Q3A players: Get your monitor running at the highest frequency it can in the resolution you choose - say, 85Hz for example - and then add a few to that number and set the maximum displayed FPS to that figure, by using the "\com_maxfps" command, eg, "\com_maxfps 88". And to do a bit more knit-picking, the linked article refers to "purple" as being a combination of "red" and "blue". This is untrue - every colour possible is only a combination of a unique light-wave frequency and intensity, meaning that all intensities of the colour "purple" have the same unique light frequency. However, the three types of cones in the human eye (each responding to stimuli from different wavelength-/frequency-ranges) interpret things slightly differently. A colour like purple will stimulate the "red-range" and "blue-range" cones about equally, and therefore an RGB display consisting of equal red and blue signals, with no green, will stimulate the same cones in the same way, thus giving the illusion of the colour purple.
Seeing as RAM these days is getting, like, 2Gb throughput (in my benchmark program anyway), that's 100x faster than a really speedy hard drive...
16777216 * 3 = 50331648 = 48MB
Now that's a lot of data to be transferring around. I assume that any devices using this new technology will at least be transferring the photo data using USB or something...
BTW 16.8 megapixels is most-likely a 4096x4096 image. WOW! You could zoom in over 5x before getting a pixel ratio of 1:1 with the image on an 800x600 display.
Hmmm imagine a beowu$%^#5...NO CARRIER
Don't you remember where they found Fwiffo the Spathi in Star Control II? The prophets Fred Ford and Paul Reiche III were correct! Oh, here come those friendly men with the white jackets again...
The only 36bit thing about the PPro's is that it has 36bits of virtual address space, ie. 64Gb. Apart from that the CPU still has 8-, 16-, 32-, 64-, and some steppings have 128-bit instructions on them.
Then there's the issue of bus size - I'm not clued up at the moment as to the bus sizes of the different CPU's, but there you have another factor.
How how do you rate a CPU in "bits", I ask you? Cut the flames then, until you know what you are saying.
For my $0.02 on the topic, let me go through a bit of history:
8086: 20 bits of virtual RAM address space (thank you Bill Gates), giving 1Mb maximum RAM. 8bit and 16bit instructions, with an 8bit memory bus. Debut at 4.77Mhz
80286: Here is the first example in the x86 range of trying to maintain backwards ISA compatibility. The '286 had a 24bits of address space (16Mb) but in order to maintain compatibilty with a handful of 8086 programs, the designers did two very annoying things:
1) The A20 address line: without setting this stupid control line, the first 64kb of each 1Mb of RAM (excluding the first 1Mb) is inaccessible. Crazy! Just because some software on the XT relies on the fact that there will never be over 1Mb of RAM, and sometimes write to addresses higher than 1Mb knowing that the effective address would wrap around back to 0....
2) 80286 Real Mode: The CPU still started up in "Real Mode" which prevents you from using any of the extended RAM you may have...you had to clumsily switch to 16 protected mode (a programmer's nightmare) to access the RAM. I wont go into the topic of Intel+M$+undocumented instructions right here.
80386: This was a huge jump up from the '286, with 32bits of virtual address space (4Gb), a whole new set of 32bit instructions, some extra registers and a whole different architecture. This CPU would have been *great* to start with, but for the good old "ISA backwards compatibility" issues Hannibal speaks of. It introduced 32bit Protected Mode, allowing multi-tasking and hardware task switching, etc, but it *still* booted into Real Mode. What a pain in the ass. And it would take programmers *years* before they begain to come to grips with the complications of switching between these CPU modes.
Ok, "So what's the point of all this useless information?" you ask...Well, it serves to illustrate the cumbersome and incredibly annoying way that the x86 CPU's of today operate: so much red tape to go through to get to the CPU's real power, because by default it limits you to good old 8086 days.....IMHO Intel should have phased out their old way of doing things and started afresh with the 386 - trust me, applications would have been a whole lot more stable and advanced if it wasn't for the *really* silly backward compatibility issues. And besides it would not have been terribly hard to create a "virtual machine" for the old 8086 software anyway...
So, x86, it's been real. Rest In Peace. And bring on the new stuff.
What they are describing is the phenomenon of the cesium emitting a light wave identical to the one entering it. The cesium is already in an excited state, and the leading-edge of the light wave sets off a very fast "reaction" which begins emitting a pulse of light out of the other side before the main pulse has entered the crystal.
The energy used to do this is then absorbed back into the cesium from the incoming light. Using the information in the article you could calculate that the leading edge of the light wave is a little under 60 feet long.
Logical, isn't it? :)
Better luck next time.
Our friendly Telco monopoly here in South Africa has deemed DSL an illegal technology. We have imported two DSL modems and use them to link our two offices but we have to hide them whenever the telco engineers are about. A third party DSL provider would be great.
Who's the idiot? The one who reads a statement as a Question would be considered an idiot. Good luck to you.
I hope for once Linus' purpose will be detailed - too many people have lame-ass conspiracy theory schemes.
Anyway, please stop posting crap, Dr Fool.
Gates.says.money.is.god
Besides the flamebait you provide, it is quite obvious you use Microsoft products for spell-checking. The correct spelling is "zealot". You fool.