So here he's saying exactly the opposite, that congestion is a serious problem for open spectrum! Which is it?
It's a bit of both. The existing protocols lack some features you really need to make best use of the bandwidth, for example, node routing and power control are both absolutely critical, and WiFi does neither out of the box.
The author does say as much somewhere, but mostly he talks as if the spectrum will bear an unlimited number of users, which is bollocks. Having lots of spread-spectrum devices in the same area and frequency band will affect the performance of these devices.
No. I think he's right. Certainly, if you reduce the power you transmit to the absolute minimum to reach just the nearest nodes then the bandwidth goes up. Then if you route through the other nodes, the bandwidth goes up. Direction aerials, bandwidth goes up. Optimal filtering to make good effect of the reflections in the room, bandwidth goes up. I truly think that the available bandwidth is very, very, very large. Sure it's lots of extra hardware, and there's lots of processing, but they're getting cheaper and cheaper. Also, as the users, and if properly designed, the room, tends to absorb microwaves, then the amount of bandwidth scales with the number of users- the noise floor just simply doesn't keep going up, since the users get in the way.
Perhaps months later, you've been able to decrypt the encrypted packet, but so what? If you've decrypted the password, you aren't in need of changing the clocks to use it, and the password has likely been changed already anyhow.
No it's an attack on certificates. Most certificates have an expiry date, because you think they could have been cracked. Once they have expired, if you have cracked a (presumably relatively short) public key and retrieved the private key you can misrepresent yourself but only if the time reference can be subverted, since the certificate will probably have expired by the time you've managed to do this.
As you noted, Kerberos also has had issues in the past.
Secure systems really need cryptographically signed time references.
There is the slight problem of, according to some estimates, there being more board positions than there are atoms in the universe... But even if you get past that, enumerating all the positions could take 'a little while'.
Actually the story I heard was that the stealth fighters were very visible on the ancient WWII radar that they had on the ships there. The stealth bomber is designed to block out the high frequencies that modern radars use and reflect the rest anywhere but back to where it came from. But the lower frequencies used in WWII aren't nearly as well attenuated; for basic physical reasons. That, plus the fact that they had 'passive' radar on some of the ships making use of single transmitters on other ships meant that they got to see this small cross-section blip fly past at somewhat below the speed of sound.
The cheapest lasers cost about $1/watt currently (semiconductor lasers); but normally you're talking $10s or $100s of dollars per watt.
Semiconductor lasers could be made to work, but they're awkward, you'd need a large array of them and you'd need focusing lenses, and a lot of mucking about and aligning.
Actually it can cause big issues. Many crypto systems rely on knowing what the tme is, so that certificates can be ignored if they are out of date. So if you spend 5 years cracking a certificate, the certs are probably then out of date, but then you hack the ntpd server and suddenly they work again, and ssh succumbing is moments away.
I've always hated the all or nothing priviledges that Unix uses.
This sounds similar to a scheme that Java supports on some platforms (netscape?); I believe there is a setPrivilege() call.
I'd like to see more of this kind of thing- restrictions to the file space that 'parts' of programs can access should be made, as well as I/O and networking restrictions. Is an email worm going to happen if the OS stops the macros from sending mail? Why should it if somebody else wrote the macro? There's a clear need for better granularity of security.
We've seen how useful personal filewalls are for network interfaces- this needs to be extended to the other services that the OS supports.
Given the speed of processors, how likely is a line in the cache to survive a context switch, even if it weren't flushed explicitly? I would imagine fairly small.
It had better be astronomically small otherwise user programs will gradually screw up; and I don't think it is that small in fact.
No, look swapping is not the same as virtual memory. Virtual memory is useful even in the absence of any disk or swap space at all.
The point is that virtual memory reduces the amount of real memory you need for each thread- each only takes what it really needs. Sure if memory is cheap, it may not matter so much. But even if it is cheap do you really want to give each process 1 gig of space on the off-chance that it might need it? I don't think so.
Virtual memory is when a process thinks it has 1 gigabyte of memory, but it actually only has, say 128 megabytes. It can read or write to any bit of it, and the OS does what is necessary to ensure that it never notices the difference; obviously upto the actual system limits.
Virtual memory and swap space go together very nicely, but one does not imply the other. You can use virtual memory to implement garbage collection for example; with no backing store at all.
I guess there are other ways to do similar things- for example, don't use virtual memory, use real memory and set up the MMU so that each thread can only see its own map. But there are issues with that, and it isn't necessarily faster.
I think once you've switched on the memory management unit; you lose very little by using virtual memory. I don't think it's going to go away any time soon. And the cost of switching on the MMU is very small, given the relatively deep pipelines we have right now with these processors.
Fortunately, I've invented a new invention which I intend to patent. I call it multiple current storage devices. Or "batteries" for short. You plug your device into a wall socket and there are no wires to trip over. I think it's going to be very popular for use with wireless devices.
There's a big difference between manned and unmanned vehicles though.
I think the accident rate for a manned vehicle is nearer to 1 percent. Space Shuttle has had one accident in about 100 launches for example- that's a 1% failure rate. The Russian record for manned launches in recent times is better if anything.
personally I think there is a definite limit on how safe you can make a big tube of explosives for the little mostly-water creatures trying to ride it into orbit....
There's no law of physics that says that. Actually liquid fuelled rocket engines can be very reliable. The XCOR group have never had one spontaneously disassemble, and they've now got more time on their little engines than the whole space shuttle fleet;-) They even ran a very small one indoors at a conference infront of quite a few people!
roll on space-elevators...
Yes, well. They fall down too though. The problem is that they can get severed by space junk or meteor strikes. And we're not quite sure what happens if they get hit by lightning either...
BUT once you have more than one program or thread running the situation is different.
Yes.
Say you have one thread running flat out and another that needs to do 100microseconds of work. With 100 ticks per second you will lose 5 usec to context switching and 9900 usec to waiting for the next context switch.
No! The task does 100 microseconds of work and then calls the sleep command, or does I/O or whatever. This ultimately goes through the kernel and the kernel does an early context switch. It certainly doesn't waste the rest of the timeslice.
Incidentally, the overhead of doing the context switch is much bigger than you say here- one of the things that the kernel has to do is flush the caches as it swaps the virtual memory in and out- that will slow the system for tens of thousands of instructions afterwards.
Anyway, you're wrong about it not improving performance; it certainly can improve latency, which is very definitely a performance metric; but obviously you'll lose some cpu time due to the more frequent context switches that will occur.
Yeah, but we're talking about a real O/S here. One of the reasons '95 crashed so much was because it didn't have virtual memory. Therefore the OS didn't have to page out all the memory at the context switch tick and they could afford to tick more often, because the costs were lower.
I think they more than made up for it in reboot time;-)
The problem occurs when the memory management unit gets modified to maintain the virtual memory 'illusion'. Then you have to flush the caches to maintain consistency. Of course it doesn't happen on every clock tick, you hope.
That means that all the caches above the memory management unit need to get flushed. This includes the program cache; and any other data too.
I did a quick check on the web for this, but I haven't managed to find a good reference to where the MMU is placed in the different architectures yet.
Anyway, that's one of the main reasons the OS scheduling isn't shorter, but any decent OS has to do quite a bit of dorking around at that time.
Slashdot Mirror
Took it apart- could see the burn mark. Luckily we had the parts and managed to repair it.
Hey, who are you calling shifty? ;-)
It takes only 45 minutes for me to airsnort the WEP password of your network. Honestly, how hard is that for us warchalking people to do?
I'd still be worried that it would cool some part of my mobo (obviously not near the processor) down to the dew point; and then "bad things happen"...
Or you could go the fog juice route; yeah grease all over your mobo, just what you need.
It's a bit of both. The existing protocols lack some features you really need to make best use of the bandwidth, for example, node routing and power control are both absolutely critical, and WiFi does neither out of the box.
No. I think he's right. Certainly, if you reduce the power you transmit to the absolute minimum to reach just the nearest nodes then the bandwidth goes up. Then if you route through the other nodes, the bandwidth goes up. Direction aerials, bandwidth goes up. Optimal filtering to make good effect of the reflections in the room, bandwidth goes up. I truly think that the available bandwidth is very, very, very large. Sure it's lots of extra hardware, and there's lots of processing, but they're getting cheaper and cheaper. Also, as the users, and if properly designed, the room, tends to absorb microwaves, then the amount of bandwidth scales with the number of users- the noise floor just simply doesn't keep going up, since the users get in the way.
No it's an attack on certificates. Most certificates have an expiry date, because you think they could have been cracked. Once they have expired, if you have cracked a (presumably relatively short) public key and retrieved the private key you can misrepresent yourself but only if the time reference can be subverted, since the certificate will probably have expired by the time you've managed to do this.
As you noted, Kerberos also has had issues in the past.
Secure systems really need cryptographically signed time references.
There is the slight problem of, according to some estimates, there being more board positions than there are atoms in the universe... But even if you get past that, enumerating all the positions could take 'a little while'.
Actually the story I heard was that the stealth fighters were very visible on the ancient WWII radar that they had on the ships there. The stealth bomber is designed to block out the high frequencies that modern radars use and reflect the rest anywhere but back to where it came from. But the lower frequencies used in WWII aren't nearly as well attenuated; for basic physical reasons. That, plus the fact that they had 'passive' radar on some of the ships making use of single transmitters on other ships meant that they got to see this small cross-section blip fly past at somewhat below the speed of sound.
Semiconductor lasers could be made to work, but they're awkward, you'd need a large array of them and you'd need focusing lenses, and a lot of mucking about and aligning.
Actually it can cause big issues. Many crypto systems rely on knowing what the tme is, so that certificates can be ignored if they are out of date. So if you spend 5 years cracking a certificate, the certs are probably then out of date, but then you hack the ntpd server and suddenly they work again, and ssh succumbing is moments away.
This sounds similar to a scheme that Java supports on some platforms (netscape?); I believe there is a setPrivilege() call.
I'd like to see more of this kind of thing- restrictions to the file space that 'parts' of programs can access should be made, as well as I/O and networking restrictions. Is an email worm going to happen if the OS stops the macros from sending mail? Why should it if somebody else wrote the macro? There's a clear need for better granularity of security.
We've seen how useful personal filewalls are for network interfaces- this needs to be extended to the other services that the OS supports.
Ok. My bad. Guess this enables the change.
It had better be astronomically small otherwise user programs will gradually screw up; and I don't think it is that small in fact.
The point is that virtual memory reduces the amount of real memory you need for each thread- each only takes what it really needs. Sure if memory is cheap, it may not matter so much. But even if it is cheap do you really want to give each process 1 gig of space on the off-chance that it might need it? I don't think so.
Virtual memory is when a process thinks it has 1 gigabyte of memory, but it actually only has, say 128 megabytes. It can read or write to any bit of it, and the OS does what is necessary to ensure that it never notices the difference; obviously upto the actual system limits.
Virtual memory and swap space go together very nicely, but one does not imply the other. You can use virtual memory to implement garbage collection for example; with no backing store at all.
I guess there are other ways to do similar things- for example, don't use virtual memory, use real memory and set up the MMU so that each thread can only see its own map. But there are issues with that, and it isn't necessarily faster.
I think once you've switched on the memory management unit; you lose very little by using virtual memory. I don't think it's going to go away any time soon. And the cost of switching on the MMU is very small, given the relatively deep pipelines we have right now with these processors.
Fortunately, I've invented a new invention which I intend to patent. I call it multiple current storage devices. Or "batteries" for short. You plug your device into a wall socket and there are no wires to trip over. I think it's going to be very popular for use with wireless devices.
I think the accident rate for a manned vehicle is nearer to 1 percent. Space Shuttle has had one accident in about 100 launches for example- that's a 1% failure rate. The Russian record for manned launches in recent times is better if anything.
There's no law of physics that says that. Actually liquid fuelled rocket engines can be very reliable. The XCOR group have never had one spontaneously disassemble, and they've now got more time on their little engines than the whole space shuttle fleet ;-) They even ran a very small one indoors at a conference infront of quite a few people!
roll on space-elevators...
Yes, well. They fall down too though. The problem is that they can get severed by space junk or meteor strikes. And we're not quite sure what happens if they get hit by lightning either...
Yes. Say you have one thread running flat out and another that needs to do 100microseconds of work. With 100 ticks per second you will lose 5 usec to context switching and 9900 usec to waiting for the next context switch.
No! The task does 100 microseconds of work and then calls the sleep command, or does I/O or whatever. This ultimately goes through the kernel and the kernel does an early context switch. It certainly doesn't waste the rest of the timeslice.
Incidentally, the overhead of doing the context switch is much bigger than you say here- one of the things that the kernel has to do is flush the caches as it swaps the virtual memory in and out- that will slow the system for tens of thousands of instructions afterwards.
Anyway, you're wrong about it not improving performance; it certainly can improve latency, which is very definitely a performance metric; but obviously you'll lose some cpu time due to the more frequent context switches that will occur.
It has to do stuff like that to keep the processes address space separate- otherwise one rogue process would kill all the others, like in 95
I think they more than made up for it in reboot time ;-)
All of them AFAIK.
That just doesn't sound right.
Well, it is. Deal ;-)
The problem occurs when the memory management unit gets modified to maintain the virtual memory 'illusion'. Then you have to flush the caches to maintain consistency. Of course it doesn't happen on every clock tick, you hope.
That means that all the caches above the memory management unit need to get flushed. This includes the program cache; and any other data too.
I did a quick check on the web for this, but I haven't managed to find a good reference to where the MMU is placed in the different architectures yet.
Anyway, that's one of the main reasons the OS scheduling isn't shorter, but any decent OS has to do quite a bit of dorking around at that time.