Of course you'd need a larger address space than that for swapping...
No you don't. You can have considerably more than 4GB of total virtual memory space on IA32 and other 32 bit architectures. You are just limited to (assuming no bank switching)
2^32 bytes of physical memory 2^32 bytes of (physical + virtual) memory mapped into any one vm context-- e.g. process.
Sure, sure, exponential growth and all. But you're not talking about 3000x the amount of RAM that's in a typical system today-- you're talking about 256 BILLION TIMES THE RAM that's in a typical system today.. that is available in a 64 bit system vs. a 32 bit system.
If one bit of memory fits on one silicon atom, it would take 127038750317144 kg of silicon (that's a lot, by the way!) to build a computer with 2^128 bytes of memory. So no, the exponential growth is not going to continue forever, dream on.
It's hard to picture why there will ever be a need for 128-bit computing.
2^64 is 18446744073709551616. This is BIG. 17179869184 gigabytes. 16777216 terabytes of addressable memory. 16384 petabytes. This is basically the maximum amount of physical memory and the maximum size of one individual process's virtual memory mapping on a 64 bit architecture (yes, I know many current 64 bit implementations, including AMD64 are limited to 2^48 in practice; but the architectures can fundamentally handle both 2^64 physical and virtual addressing).
This is enough addressing that you can have 2.5GB of memory in a process for each man, woman, and child on the face of the planet.
And as to doing integer math larger than 2^64-- why? 2^32 is already overkill for most things.
Nope, I don't see "128-bit computing" becoming mainstream anytime soon. And it's far from clear 64 bit on the desktop is all that close, given the fact that A) the added code size contributes cache misses and saps performance, and B) there is not much done on the desktop now that requires more than 2^32 bytes of memory in a process, and C) not much stuff does math on quantities greater than 2^32 (4294967296). Keep in mind bank switching allows you to have more RAM than 4GB on all recent ia32 processors (2^36/2^40).
If we change architectures, it will be less about addressing limitations and more about the piss-poor quantity of registers available on ia32. More registers means more obtainable instruction-level parallelism.. this equals more work done on modern architectures.
To simplify it, simple harmonic motion-- the movement of the ISS around the earth.
If you're on the ISS, and you "push" a bolt 1 foot below the station, without changing its orbital velocity, you have just moved the ellipse of the orbit of that object around the earth, but not changed its size.
So when you have travelled 180 degrees around the earth, the object will want to be one foot higher than the station; another 180 degrees and back to 1 foot below, etc, oscillating back and forth. This is one of the fundamental ways that "microgravity" differs from true zero-gravity.
The bulk of data coming back from the Mars Exploration Rovers comes back through relay sessions through the Mars Odyssey and the Mars Global Surveyor satellites. The orbiters are simply much closer to the rovers than Earth is, the path loss is less, and so the data rates are much higher... and the satellites have direct visibility of earth for much longer and much higher EIRPs to talk to earth with.
A couple of weeks ago they tried the first "interplanetary network" where the sessions were up "live", rather than store and forward.
The really big advantage of this is they'll be able to command the rovers in near-realtime and get answers back right away for much more of the day than direct to earth communications is possible. And with 3 communications satellites above Mars, they are likely to have quite a few communications windows. Expect them to be fairly risk adverse, though, and for it to be several weeks before this is included in their operations.
Light through fiber doesn't allow other signals to couple in through inductively, capacitively, or through RF (assuming the fiber has good insulation around it that blocks light coming in). So you can run buses a lot longer. Usually capacitance and crosstalk become limiting on bus length.
The speed of light is relevent too, but usually only for the number of wait states you need at the start of a bus transaction.
No conspiracy theory here, just I think it's bad PAO PR to embargo. Me putting together some images on my site is not going to lessen the impact when they hold their press conference. But my inability to get the imagery annoys me and the rest of the hobbyist community.
Sure, PDS is the authentic source for mission scientific data, but would it really be hard to throw us a bone with a few technical numbers? It's getting pushed occasionally for some of the imagery with Maestro updates-- why can't they just have a few lines on the website with the engineering data.
They should make up their minds. The degree of transparency they had talked about being in place before the mission is simply not there.
As to positioning data: nope, it's not, but it is important for accurately producing anaglyphs/range maps/good stitches unfortunately. And the radiometric data -is- important for nearcolor-- I could release a lot more nearcolor imagery if I had confidence the radiometric data was right. As it is now, I have to inspect each image by hand and compare to the spectroscopy data I have on hand to make sure things are close to right. As to why those pieces of engineering data associated with the image aren't being distributed-- i don't know. Perhaps NASA assumes no one is interested.
My site was one of the past ones featured on Slashdot.
Unfortunately, all data isn't released. There is not radiometric data or pointing data for pictures, spectrometer data, etc.
And NASA puts a hold on images they plan to use later for press conferences-- e.g. the individual PanCam pictures of the parachute and backshell weren't released. This goes directly against the promises they made pre-mission.
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;
They all come from the JPL raw pictures area. My scripts/code turn the raw pictures into color imagery and anaglyphs, and assist me in stitching images together into larger ones.
When it comes to scale, the pancam images (which all the color images are derived from) have a 16.8x16.8 degree field of view. This is about the same as 140mm telephoto lens when used with a 35mm camera. As to the size across the frame, this varies with the camera distance. The closest the camera will be to the center of the frame is about 7 ft, making the picture maybe about 2-3 feet across? The pancam is largely designed to mimic what human vision would see, in resolution and in focal length.
The microscopic imager takes pictures that are about 1.25" across when in focus. I may be able to produce crude color pictures with it because it has a dust cover that is colored orange, and sometimes they take pictures with it on... providing crude color information.
Any that incorporate infrared will render it purple-y. The blue chip is very reflective in the infrared spectrum.. and with 2 for most of the red value, infrared is incorporated into it.
That's why it's called pseudocolor, because the redpoint is off by 30-60nm depending on exposure. It doesn't mess things up much except for things that have a ton of infrared reflectivity. I also have "nearcolor" pics that take L2/3/4/5/6 filtered pictures together and combine them to be really close perceptually what people would see. But there have not been any qualifying sets of images downlinked from Opportunity yet, nor will there be many. (L3/L4 aren't so useful for science, so it's only things that they're really interested in that they take pictures with all filters---and that thus I can do it for).
Featuring COLOR IMAGES from Opportunity, before JPL has made them available. (By aggregating 2/5/6 filters together to simulate what the human eye would see).
Also, there are stereo anaglyphs up of the lander.
Well, it received a command to beep, and beeped. That command goes to the flight computer. The particular beep it sent back indicated the operating mode the computer was in.
Update: Now they've done 2 engineering traffic data sessions. The first was a quick telemetry run, 10 bits per second for 10 minutes. Apparently they liked what they saw, because less than an hour later they did a 120 bit per second run for 20 minutes.
This will let them see why it decided things were unusual and entered a safe mode, and bring it out.
I meant a synchronization problem between the physical transmitter unit and the main avionics system.
When it comes to clocks, it is somewhat complicated. The rover keeps a clock, and usually finds earth by locating the sun in the sky. It has a set of keplerian/rotational elements for both Earth around the Sun and the MGS/Odyssey around Mars, and thus knows when they rise and set in the sky. This tells it when to transmit and where to point the antenna.
Full duplex communications are possible on xband, so transmitting and receiving do not need to be synchronized. Blocks of data are sent with error correction codes-- as they arrive intact, messages are sent telling the rover to delete them. Retransmits can also be requested if the data is particularly interesting and missing (but often aren't, as witnessed by the number of empty portions of images.
UHF is usually just used to offload additional data from the rover during the night to the satellites. The delays are short and the protocols are thus more conventional.
They have only had one day to troubleshoot. Much of that day was spent assuming atmospheric water vapor and dish tracking problems caused errors in sending command traffic. It's important to get some idea of the problem before you go shoving things into safe modes-- else you might make things worse.
That tone is still unconfirmed-- they are not positive they have received it (it came in only 2.5 hours ago and processing the data sets takes time.. NASA has not confirmed that they are sure they got a 7.2 tone).
But I agree it is likely the rover is reporting it is faulted, even if it is not a sure thing yet.
By now they have probably rebooted it (forced it through safe mode to clear any software fault; space vehicles never really go all the way "down"), so if it's still happenning I would say it's either a hardware fault or corruption of essential software or data in (putatively) nonvolatile memory (not unreasonable in high-rad environments).
Not impossible, but relatively unlikely with deep-space grade hardware. It'd require a double fault to create a detectable error, and more than that to create an undetectable one.
If they haven't forced it through safe mode, then they're not too worried and are more interested in characterizing the problem than getting on with the scientific mission. Which is a good or a bad thing depending on which sort of information is more valuable. I'm sure the guys in the software group have their bias.
They've had one day, and much of that was spent thinking the problem was because of thunderstorms/atmospheric vapor near Canberra and dish tracking problems were causing communications errors. It's important to get some idea of the problem before you go shoving things into safe modes because you may make things worse (if it's a power bus fault, for instance).
I watched the press conference and have read extensively about the communications system. I am also the person featured in yesterday's slashdot article about imagery and my postprocessing/color correction/stereo anaglyph creation from it.
In the coming days, if communications are not restored, the spacecraft will enter safe modes that cause it to try harder to transmit and will reset subsystems. I am optimistic at this point.
A considerable number of things have to work properly for the rover to be in its present state. Mars Global Surveyor received a carrier on UHF but no data, confirming that the UHF antenna, amplifier, and tranmitter are functional. The fact that it transmitted at the correct time (at night) indicates batteries and power systems are at least mostly functional, and that the spacecraft computer/avionics system was able to calculate the time of the MGS pass.
Also, NASA's DSN (Deep Space Network) has been able to send commands asking Spirit to send tones on X-Band, and has received the response tones back. This confirms that at least the low gain antenna, antenna switch, x-band receiver, and x-band tone transmitter are functional.
Perhaps a software fault or a synchronization problem with the radios is preventing valid daa frames from being transmitted. The fact that so much is known to functional argues against a failure that will incapacitate the spacecraft indefinitely. In the coming days, if communications are not restored, the spacecraft will enter safe modes that cause it to try harder to transmit and will reset subsystems. I am optimistic at this point.
What you want on a space probe is maximal CCD chip area-- not to take things up with filters. So they have a color wheel instead. Also, the filters of ranges that the eye is sensitive to in red, green, and blue is not very useful scientifically.
They have a choice of 8 filters on each of the pancams, and the left filters are in the visible range of light. However, there are caveats, as human visual perception is a complex thing. As a result, colors are going to be off even if a picture is shot with all 7 visual range filters.
The image processing software I've written makes a best guess with 2/4/7 and 2/5/6 filter sets. It is pretty close, but extreme colors are wrong (the red point is shifted by about 30nm) I hope to use the cases where they've shot additional pictures (e.g. magic carpet) to improve things further for selected images in the next couple of days.
The Habeas Infringers List seems to be effective and well updated. I've received a total of 13 spams with the Habeas headers, and 11 of them scored +4 for spam like so:
HABEAS_HIL (4.0 points) RBL: Sender is on www.habeas.com Habeas Infringer List
The problem is that not enough legitimate mail contains the warranty. More commercial licensors would give Habeas greater resources to track infringers and would also make the Habeas mark a much better indicator of spam.
Of course you'd need a larger address space than that for swapping...
No you don't. You can have considerably more than 4GB of total virtual memory space on IA32 and other 32 bit architectures. You are just limited to (assuming no bank switching)
2^32 bytes of physical memory
2^32 bytes of (physical + virtual) memory mapped into any one vm context-- e.g. process.
Sure, sure, exponential growth and all. But you're not talking about 3000x the amount of RAM that's in a typical system today-- you're talking about 256 BILLION TIMES THE RAM that's in a typical system today.. that is available in a 64 bit system vs. a 32 bit system.
If one bit of memory fits on one silicon atom, it would take 127038750317144 kg of silicon (that's a lot, by the way!) to build a computer with 2^128 bytes of memory. So no, the exponential growth is not going to continue forever, dream on.
It's hard to picture why there will ever be a need for 128-bit computing.
2^64 is 18446744073709551616. This is BIG. 17179869184 gigabytes. 16777216 terabytes of addressable memory. 16384 petabytes. This is basically the maximum amount of physical memory and the maximum size of one individual process's virtual memory mapping on a 64 bit architecture (yes, I know many current 64 bit implementations, including AMD64 are limited to 2^48 in practice; but the architectures can fundamentally handle both 2^64 physical and virtual addressing).
This is enough addressing that you can have 2.5GB of memory in a process for each man, woman, and child on the face of the planet.
And as to doing integer math larger than 2^64-- why? 2^32 is already overkill for most things.
Nope, I don't see "128-bit computing" becoming mainstream anytime soon. And it's far from clear 64 bit on the desktop is all that close, given the fact that A) the added code size contributes cache misses and saps performance, and B) there is not much done on the desktop now that requires more than 2^32 bytes of memory in a process, and C) not much stuff does math on quantities greater than 2^32 (4294967296). Keep in mind bank switching allows you to have more RAM than 4GB on all recent ia32 processors (2^36/2^40).
If we change architectures, it will be less about addressing limitations and more about the piss-poor quantity of registers available on ia32. More registers means more obtainable instruction-level parallelism.. this equals more work done on modern architectures.
To simplify it, simple harmonic motion-- the movement of the ISS around the earth.
If you're on the ISS, and you "push" a bolt 1 foot below the station, without changing its orbital velocity, you have just moved the ellipse of the orbit of that object around the earth, but not changed its size.
So when you have travelled 180 degrees around the earth, the object will want to be one foot higher than the station; another 180 degrees and back to 1 foot below, etc, oscillating back and forth. This is one of the fundamental ways that "microgravity" differs from true zero-gravity.
The bulk of data coming back from the Mars Exploration Rovers comes back through relay sessions through the Mars Odyssey and the Mars Global Surveyor satellites. The orbiters are simply much closer to the rovers than Earth is, the path loss is less, and so the data rates are much higher... and the satellites have direct visibility of earth for much longer and much higher EIRPs to talk to earth with.
A couple of weeks ago they tried the first "interplanetary network" where the sessions were up "live", rather than store and forward.
The really big advantage of this is they'll be able to command the rovers in near-realtime and get answers back right away for much more of the day than direct to earth communications is possible. And with 3 communications satellites above Mars, they are likely to have quite a few communications windows. Expect them to be fairly risk adverse, though, and for it to be several weeks before this is included in their operations.
"BAUD" is the measurement of symbols per second.
16 BAUD of 8 level FSK would be 48 bits/second. (16 symbols per second, 3 bits per symbol).
Actually, iSync requires the palm desktop and the base palm conduits to talk to PalmOS devices. It will be interesting to see how this plays out.
Light through fiber doesn't allow other signals to couple in through inductively, capacitively, or through RF (assuming the fiber has good insulation around it that blocks light coming in). So you can run buses a lot longer. Usually capacitance and crosstalk become limiting on bus length.
The speed of light is relevent too, but usually only for the number of wait states you need at the start of a bus transaction.
No conspiracy theory here, just I think it's bad PAO PR to embargo. Me putting together some images on my site is not going to lessen the impact when they hold their press conference. But my inability to get the imagery annoys me and the rest of the hobbyist community.
Sure, PDS is the authentic source for mission scientific data, but would it really be hard to throw us a bone with a few technical numbers? It's getting pushed occasionally for some of the imagery with Maestro updates-- why can't they just have a few lines on the website with the engineering data.
They should make up their minds. The degree of transparency they had talked about being in place before the mission is simply not there.
Hehe. Thank you.
As to positioning data: nope, it's not, but it is important for accurately producing anaglyphs/range maps/good stitches unfortunately. And the radiometric data -is- important for nearcolor-- I could release a lot more nearcolor imagery if I had confidence the radiometric data was right. As it is now, I have to inspect each image by hand and compare to the spectroscopy data I have on hand to make sure things are close to right. As to why those pieces of engineering data associated with the image aren't being distributed-- i don't know. Perhaps NASA assumes no one is interested.
My site was one of the past ones featured on Slashdot.
Unfortunately, all data isn't released. There is not radiometric data or pointing data for pictures, spectrometer data, etc.
And NASA puts a hold on images they plan to use later for press conferences-- e.g. the individual PanCam pictures of the parachute and backshell weren't released. This goes directly against the promises they made pre-mission.
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;
:)
US Constitution, Article I, Section 8.
Get a clue.
HEhe, thank you.
They all come from the JPL raw pictures area. My scripts/code turn the raw pictures into color imagery and anaglyphs, and assist me in stitching images together into larger ones.
When it comes to scale, the pancam images (which all the color images are derived from) have a 16.8x16.8 degree field of view. This is about the same as 140mm telephoto lens when used with a 35mm camera. As to the size across the frame, this varies with the camera distance. The closest the camera will be to the center of the frame is about 7 ft, making the picture maybe about 2-3 feet across? The pancam is largely designed to mimic what human vision would see, in resolution and in focal length.
The microscopic imager takes pictures that are about 1.25" across when in focus. I may be able to produce crude color pictures with it because it has a dust cover that is colored orange, and sometimes they take pictures with it on... providing crude color information.
Any that incorporate infrared will render it purple-y. The blue chip is very reflective in the infrared spectrum.. and with 2 for most of the red value, infrared is incorporated into it.
That's why it's called pseudocolor, because the redpoint is off by 30-60nm depending on exposure. It doesn't mess things up much except for things that have a ton of infrared reflectivity. I also have "nearcolor" pics that take L2/3/4/5/6 filtered pictures together and combine them to be really close perceptually what people would see. But there have not been any qualifying sets of images downlinked from Opportunity yet, nor will there be many. (L3/L4 aren't so useful for science, so it's only things that they're really interested in that they take pictures with all filters---and that thus I can do it for).
See nearcolor pics near the top of my site.
For more good stuff, go to my site...
Featuring COLOR IMAGES from Opportunity, before JPL has made them available. (By aggregating 2/5/6 filters together to simulate what the human eye would see).
Also, there are stereo anaglyphs up of the lander.
Well, it received a command to beep, and beeped. That command goes to the flight computer. The particular beep it sent back indicated the operating mode the computer was in.
Update: Now they've done 2 engineering traffic data sessions. The first was a quick telemetry run, 10 bits per second for 10 minutes. Apparently they liked what they saw, because less than an hour later they did a 120 bit per second run for 20 minutes.
This will let them see why it decided things were unusual and entered a safe mode, and bring it out.
I meant a synchronization problem between the physical transmitter unit and the main avionics system.
When it comes to clocks, it is somewhat complicated. The rover keeps a clock, and usually finds earth by locating the sun in the sky. It has a set of keplerian/rotational elements for both Earth around the Sun and the MGS/Odyssey around Mars, and thus knows when they rise and set in the sky. This tells it when to transmit and where to point the antenna.
Full duplex communications are possible on xband, so transmitting and receiving do not need to be synchronized. Blocks of data are sent with error correction codes-- as they arrive intact, messages are sent telling the rover to delete them. Retransmits can also be requested if the data is particularly interesting and missing (but often aren't, as witnessed by the number of empty portions of images.
UHF is usually just used to offload additional data from the rover during the night to the satellites. The delays are short and the protocols are thus more conventional.
That last paragraph should be shot.
They have only had one day to troubleshoot. Much of that day was spent assuming atmospheric water vapor and dish tracking problems caused errors in sending command traffic. It's important to get some idea of the problem before you go shoving things into safe modes-- else you might make things worse.
That tone is still unconfirmed-- they are not positive they have received it (it came in only 2.5 hours ago and processing the data sets takes time.. NASA has not confirmed that they are sure they got a 7.2 tone).
But I agree it is likely the rover is reporting it is faulted, even if it is not a sure thing yet.
By now they have probably rebooted it (forced it through safe mode to clear any software fault; space vehicles never really go all the way "down"), so if it's still happenning I would say it's either a hardware fault or corruption of essential software or data in (putatively) nonvolatile memory (not unreasonable in high-rad environments).
Not impossible, but relatively unlikely with deep-space grade hardware. It'd require a double fault to create a detectable error, and more than that to create an undetectable one.
If they haven't forced it through safe mode, then they're not too worried and are more interested in characterizing the problem than getting on with the scientific mission. Which is a good or a bad thing depending on which sort of information is more valuable. I'm sure the guys in the software group have their bias.
They've had one day, and much of that was spent thinking the problem was because of thunderstorms/atmospheric vapor near Canberra and dish tracking problems were causing communications errors. It's important to get some idea of the problem before you go shoving things into safe modes because you may make things worse (if it's a power bus fault, for instance).
I watched the press conference and have read extensively about the communications system. I am also the person featured in yesterday's slashdot article about imagery and my postprocessing/color correction/stereo anaglyph creation from it.
From the parent post:
In the coming days, if communications are not restored, the spacecraft will enter safe modes that cause it to try harder to transmit and will reset subsystems. I am optimistic at this point.
A considerable number of things have to work properly for the rover to be in its present state. Mars Global Surveyor received a carrier on UHF but no data, confirming that the UHF antenna, amplifier, and tranmitter are functional. The fact that it transmitted at the correct time (at night) indicates batteries and power systems are at least mostly functional, and that the spacecraft computer/avionics system was able to calculate the time of the MGS pass.
Also, NASA's DSN (Deep Space Network) has been able to send commands asking Spirit to send tones on X-Band, and has received the response tones back. This confirms that at least the low gain antenna, antenna switch, x-band receiver, and x-band tone transmitter are functional.
Perhaps a software fault or a synchronization problem with the radios is preventing valid daa frames from being transmitted. The fact that so much is known to functional argues against a failure that will incapacitate the spacecraft indefinitely. In the coming days, if communications are not restored, the spacecraft will enter safe modes that cause it to try harder to transmit and will reset subsystems. I am optimistic at this point.
It's typical for space science applications.
What you want on a space probe is maximal CCD chip area-- not to take things up with filters. So they have a color wheel instead. Also, the filters of ranges that the eye is sensitive to in red, green, and blue is not very useful scientifically.
They have a choice of 8 filters on each of the pancams, and the left filters are in the visible range of light. However, there are caveats, as human visual perception is a complex thing. As a result, colors are going to be off even if a picture is shot with all 7 visual range filters.
The image processing software I've written makes a best guess with 2/4/7 and 2/5/6 filter sets. It is pretty close, but extreme colors are wrong (the red point is shifted by about 30nm) I hope to use the cases where they've shot additional pictures (e.g. magic carpet) to improve things further for selected images in the next couple of days.
The Habeas Infringers List seems to be effective and well updated. I've received a total of 13 spams with the Habeas headers, and 11 of them scored +4 for spam like so:
HABEAS_HIL (4.0 points) RBL: Sender is on www.habeas.com Habeas Infringer List
The problem is that not enough legitimate mail contains the warranty. More commercial licensors would give Habeas greater resources to track infringers and would also make the Habeas mark a much better indicator of spam.