I have a system where I want top performance. So I prepared an extra IDE controller.
Turns out that performance drops from 35Mb per second (manufacturer claims something like 35.4Mb per second) to about 33Mb per second if the second drive on the controller kicks in at another 33Mb per second.
I get about 120Mb per second out of all 4 disks (i.e. 4x 30) , and only 100Mb per second when they are striped together. Well, that's the level of performance, I don't worry anymore, and just leave it with the extra controller unused, as it didn't handle the 160G disks correctly.
The kernel compile is a "benchmark" as a bunch of reasonably separate CPU intensive jobs. If you do good on a kernel compile, you'll do very good on well-parallelizable hardcore computations as well.
Here, we do kernel development. For us it's REAL time that we spend in compiling kernels. I really would like to have a machine that does 23 second kernel compiles...
i find it difficult to envision the "partner finding factor" playing a significant role in the process.
How about "let's mate under the bush with the orange berries.
Anyway, it's complex. Very complex. Things can swing both ways.
The problem is that if you try to eradicate the population where "mate under the orange berries" is the only survival trick, then you will acutally cause "mother nature" to invent the gene for that "trick". It takes millions to billions of random mutations to "invent" such a trait.
Afterwards, however, it's just a gene, which can easily be turned on or off. Then it takes only a couple of thousand of mutations to repopulate the population with that specific trait which was benefitial to survival under attack from the humans.
In the case at hand, the traits that the pressure would promote are: "finding food with lots of competition" and "finding fertile partners". Not for sure traits that would penalize later generations.
example: sickel cell anemia in humans renders them less sensitive to malaria, but also less fit (as in healthy) than the average person.
Half a million people in sub-Saharan Africa are estimated to have been infected with sleeping sickness by the tsetse fly and 80 percent of them will likely die, according to the World Health Organization (WHO).
Hmm. I precict that about 100% will likely die. So far the human race has proven not to be immortal.
But when the modified flies die out, if there are even 2 original flies left, they will easily repopulate. [....] So basically all this will do is screw up natural selection a bit, maybe increasing resistances of the remaining flies and what not.
Natural selection is helped a lot by creating "hard times" for a while, and then easing up on the conditions.
So, the moment you stop injecting the modified flies into the environment, the remaining flies will be much better than the average before....
"The catch is: Each team wants its plane to fly more or less as the Wrights' did." The only problem with that is that as Orville Wright put it, their plane was "exceedingly erratic," so the recreators have made some slight concessions to safety.
What Orville Wright calls erratic, is what we nowadays call "inherently unstable". You want to fly something that is inherently stable.
There are a couple of ways to make a plane stable. Put a tail on it at the back (or move it back further if you already have one), or you can bend the wings backwards.
Those are changes that people "see" from a distance, and people will say: "But that's not the plane that the Wrights flew in 1908! It's different."
Oh, and you could change the profile of the wings, but then you have to have a plane that is almost stable to begin with, because this effect is so small. If carefully designed, you can build a "wing-only" plane (which was thought impossible because most wings are inherently unstable), like the helios (which as a matter of fact has its center of gravity well below the wing, one more trick to make a plane stable!).
There are advantages to building an unstable aircraft. For the Wrights that was: "Oops never thought of that". Currently the excuse is that you can use computers to make the thing stable, and then you don't have to have the inefficient things like a "tail" on the plane...
Why don't you just run with drives mounted read-only, or have everything copied to a ramdisk? Surely you can verify a rule to allow remote access from only certain locations if this is your problem, or even require serial console access.
I like the fact that my firewall logs "breakin attempts". If for instance I intend to open up my "ssh" port but the "last week" shows lots of attempts to talk to my ssh port, I know that something is going on, and that I should reconsider the decision.
One of the great things about DSL is that you have your own connection to the ISP, as opposed to cable modems, which share bandwidth within each neighborhood.
Everybody (most notably DSL providers) is quoting this as a downside of Cable, and an advantage of DSL.
I share something like 2Mbps with my neighborhood. From the central office of my cable company I still share the link with the rest of the customers of my ISP. My cable provider caps me at 512mbps.
ADSL customers have their private 6mbps (but capped to the same 512mbps) link to the ISP, and then share a similar link with the other customers to the "rest of the internet".
No provider will tell you what the capacity of those links are. And they won't tell you when and how much they are congested.
What I do know is that on average, I get (slightly) better download speeds than my friends with ADSL.
I deduct from this that at the moment, my Cable provider has a better internet link than hte averate ADSL provider out here, and that my local segment isn't very crowded.
By the time you get out to the 3rd level of cache, on a 1GHz core, there should be enough slow down that chip to chip interconnect will be adequately fast.
Intel had a problem with the Pentium Pro, remember? The two-chips-in-a-package setup ended up being very expensive.
They then went to multiple chips on a board, which fits into a slot. This proved to be too expensive as well. So they went back to producing single chip CPUs.
Think twice before you say that intel should cost-effectively do multiple chips....
The idea is that you'd make a cluster with a whole bunch of virtual machines, say 1024.
Good plan. There's a large BUT however....
There are two sources for N processors not being N times as fast as one.
First there is the communications overhead. If you have 1024 virtual processors, running on 32 real processors, there are going to be about 32 programs running and communicating on one processor, while they could've gotten by without communicating at all...
Also, the problem may not be divisable in 1024 equal chunks.
If you write your software to scale to 32, there is going to be a parameter that says how many processors there are already. So adjusting it to 64 is not going to be hard.
But test-running on a small (but virtually large!) cluster before running it on the "real cluster" could allow you to guess the magnitude of both "performance impacting issues" before buying time on the expensive "real cluster". So there certainly is a point in doing it that way....
4M pages is not a "mode" that you would put the CPU in. It is a per-table-entry thingy.
For specialized applications (say a machine with 64G of RAM, running HUMOUNGOUS applications) you might chose to run with 4M pages exclusively. Linux doesn't.
In practise you would still use 4k pages for userspace, and 4M pages where it is immediatly obvious that it doesn't make sense to use 4k pages.
... Internal fragmentation would go through the roof.
Think about it. What ISN"T fragmented?
Well two things: The linearly mapped image of main memory for direct access by the kernel and the video memory.
That's exactly where it's used for. For every 4Mb of kernel-memory that you touch, the CPU would have to load 1024 page table entries using 4k pages, and just one for 4M pages. Each of them goes into the TLB and would put pressure on the TLB to evict other entries.
Still, you'd have a hard time measuring a difference.
{
int tot[1024], arr[1024][1024], x, y;
for (x=0;x1024;x++) {
tot[x] = 0;
for (y=0;y1024;y++)
tot[x] += arr[y][x];
}
}
will show something close to the maximum possible difference: You're accessing 1024 different pages, requiring a page table lookup for every single access... Swap the y and the x in the arr[y][x] and the difference has shrunk by a factor of 1000.
Without reading their website, the claim MUST BE FALSE.
The proof is simple.
Suppose we have a 100 bit message. There are 2^100 different messages. Suppose you can compress them on average to 98 bits. Then there can only be 2^98 compressed messages. We lost a couple along the way!
This proves that if you compress SOME messages you will also have to make SOME longer. Not by much, but at least a little. (prepend 1 if "not compressable" prepend zero to the "compressed data stream" and you have a "worst case expansion" of "one bit")
Now compressing normal data is easy. There are a lot of repeats, and other redundancy. So the normal case is that you can compress them. The bad news is that if you enumerate ALL 100-bit messages, ALL compression methods are going to need on average 100 bits or more. This is pure mathematics.
The 2^100 number is a number that is quite large, but if you start talking about compressing a megabyte of data, then I'm already talking about enumerating all 2^8000000 possible messages. That is a thought experiment. But the argument still holds.
-----
I read their pressrelease. It's buzzword compliant bovine excrement. They will attract money and pay the existing people large salaries as long as they
can keep up the charade.
Oh, and they have placed a tactical "practically" in front of the word "random". I can compress "practically random data" by enormous amounts.
If you take the MD5 hash of the string "hi there", and feed that back into the MD5 function, you can generate an endless stream of "practically random" data. Take the first 1Mb of this "practically random" data.
I compressed 1Mbyte of data into the 212 bytes of the previous paragraph! However this is not possible if I let someone else generate the random data any way he pleases, and then have to compress it. They can claim to be "technically correct" up to a point due to this phenomenon....
The process by which a fuel cell works is all 'one way', and unlikely to be degraded in the above way.
Ehmm. Wrong. Fuel cells work on Hydrogen and Oxygen. Oxygen comes from the air. The hyrdogen is extracted from the methanol. The system that is used for that is slowly clogged by any and all impurities that end up in your methanol.
We don't walk around saying that 10 miles high building cannot be built because we have never built one, do we?
Right. But we can do the math to prove that materials like concrete and steel don't work for that kind of structure.
Proper encryption rules state that the adversary knows everything except your keys. In this case we know that the "command structure" is just a bit complex and non-documented. Nothing to do with having to guess at 128 bit encryption keys.
If you monitor the "normal" traffic to the satelite for a month or so, the command-structure should be pretty clear. Checksums on the packets are also deductable. Then it's easy to send a stream of more or less random commands to the satelite. Chances are it will shoot a couple of random pictures, and then spin off uncontrollably back into the atmosphere.
That would be quite a bummer, don't you think?
My recommendation is to have some simple sort of cryptographic authentication. So the groundstation signs "please do XX at t=YY" with a PGP signature. Think for a second to make replay attacks impossible (*). Problem solved.
Roger.
(*) I just did: have a 32 bit command counter, and have the satelite only accept increasing command counters. Normal procedure is to send them in sequence. If the satelite misses a bunch you have 2 billion commands to try and get it to listen again. Normally you wouldn't get into the "other half of the universe" within say 100 years.
I've recently installed two systems for "bare minimum, but usable". Both don't have a console. One is just a router/firewall, but needs a few tools for maintenance comfort. 200Mb.
The other is the "sound server". It needs "xmms" and the stuff needed for comfortable maintenance. 224 Mb.
Both started out as "bare minimum" machines, and stuff only got added on an "as needed" basis. So for example, I recently found "RPM" missing: I had always run rpm on the fileserver that serves the NFSroot for the boxes....
Slashdot Mirror
What I do now is to typedef a pointer_t which can be either int or long, and make sure to use that everywhere pointer arithmetic is required.
Auch.
First: Keep pointers in pointer variables. Try not to cast them back and forth to integer variables.
If you have to, use longs. The C standard requires a long to be able to hold a pointer.
Roger.
I have a system where I want top performance. So I prepared an extra IDE controller.
Turns out that performance drops from 35Mb per second (manufacturer claims something like 35.4Mb per second) to about 33Mb per second if the second drive on the controller kicks in at another 33Mb per second.
I get about 120Mb per second out of all 4 disks (i.e. 4x 30) , and only 100Mb per second when they are striped together. Well, that's the level of performance, I don't worry anymore, and just leave it with the extra controller unused, as it didn't handle the 160G disks correctly.
Roger.
The kernel compile is a "benchmark" as a bunch of reasonably separate CPU intensive jobs. If you do good on a kernel compile, you'll do very good on well-parallelizable hardcore computations as well.
Here, we do kernel development. For us it's REAL time that we spend in compiling kernels. I really would like to have a machine that does 23 second kernel compiles...
Roger.
As a small ISP (just over 10 customers, over 40 domains) I have just printed a letter to Ab.Fab which asks them not to send any mail to my clients.
Given the ruling, I think they will have to comply with that.
I hope that lots of others do the same. Especially if you can legally claim to control more than a couple of domains.
I used the address that I found on their site as "how to find us":
ab.fab Interactive Media Group
Postbus 9088
1180 MB Amstelveen
[the netherlands]
I hope that this will at least stop the "spamfactories".
Roger.
A quote from the GPL:
The source code for a work means the preferred form of the work for making modifications to it.
The GPL states that you should provide the source code with your binary, and it correctly defines the term "source code".
Not just "the stuff that the compiler uses as input", but the preferred form for making modifications.
Case closed.
Roger.
i find it difficult to envision the "partner finding factor" playing a significant role in the process.
How about "let's mate under the bush with the orange berries.
Anyway, it's complex. Very complex. Things can swing both ways.
The problem is that if you try to eradicate the population where "mate under the orange berries" is the only survival trick, then you will acutally cause "mother nature" to invent the gene for that "trick". It takes millions to billions of random mutations to "invent" such a trait.
Afterwards, however, it's just a gene, which can easily be turned on or off. Then it takes only a couple of thousand of mutations to repopulate the population with that specific trait which was benefitial to survival under attack from the humans.
Roger.
Fully agreed.
In the case at hand, the traits that the pressure would promote are: "finding food with lots of competition" and "finding fertile partners". Not for sure traits that would penalize later generations.
example: sickel cell anemia in humans renders them less sensitive to malaria, but also less fit (as in healthy) than the average person.
as in: Unlikely to reach the age of 30.
Roger.
[ Reply to This | Parent ]
From the article:
Half a million people in sub-Saharan Africa are estimated to have been infected with sleeping sickness by the tsetse fly and 80 percent of them will likely die, according to the World Health Organization (WHO).
Hmm. I precict that about 100% will likely die. So far the human race has proven not to be immortal.
Roger.
But when the modified flies die out, if there are even 2 original flies left, they will easily repopulate. [....] So basically all this will do is screw up natural selection a bit, maybe increasing resistances of the remaining flies and what not.
Natural selection is helped a lot by creating "hard times" for a while, and then easing up on the conditions.
So, the moment you stop injecting the modified flies into the environment, the remaining flies will be much better than the average before....
Roger.
The article claims 6 Watts of power output.
My previous laptop used about 20W, my current one has a spec stating over 60W on the bottom.
So for a reasonable laptop (25W), it would be more like 20 minutes of pumping would give you 5 minutes of battery life...
Roger.
"The catch is: Each team wants its plane to fly more or less as the Wrights' did." The only problem with that is that as Orville Wright put it, their plane was "exceedingly erratic," so the recreators have made some slight concessions to safety.
What Orville Wright calls erratic, is what we nowadays call "inherently unstable". You want to fly something that is inherently stable.
There are a couple of ways to make a plane stable. Put a tail on it at the back (or move it back further if you already have one), or you can bend the wings backwards.
Those are changes that people "see" from a distance, and people will say: "But that's not the plane that the Wrights flew in 1908! It's different."
Oh, and you could change the profile of the wings, but then you have to have a plane that is almost stable to begin with, because this effect is so small. If carefully designed, you can build a "wing-only" plane (which was thought impossible because most wings are inherently unstable), like the helios (which as a matter of fact has its center of gravity well below the wing, one more trick to make a plane stable!).
There are advantages to building an unstable aircraft. For the Wrights that was: "Oops never thought of that". Currently the excuse is that you can use computers to make the thing stable, and then you don't have to have the inefficient things like a "tail" on the plane...
Roger.
Why don't you just run with drives mounted read-only, or have everything copied to a ramdisk? Surely you can verify a rule to allow remote access from only certain locations if this is your problem, or even require serial console access.
I like the fact that my firewall logs "breakin attempts". If for instance I intend to open up my "ssh" port but the "last week" shows lots of attempts to talk to my ssh port, I know that something is going on, and that I should reconsider the decision.
Roger.
One of the great things about DSL is that you have your own connection to the ISP, as opposed to cable modems, which share bandwidth within each neighborhood.
Everybody (most notably DSL providers) is quoting this as a downside of Cable, and an advantage of DSL.
I share something like 2Mbps with my neighborhood. From the central office of my cable company I still share the link with the rest of the customers of my ISP. My cable provider caps me at 512mbps.
ADSL customers have their private 6mbps (but capped to the same 512mbps) link to the ISP, and then share a similar link with the other customers to the "rest of the internet".
No provider will tell you what the capacity of those links are. And they won't tell you when and how much they are congested.
What I do know is that on average, I get (slightly) better download speeds than my friends with ADSL.
I deduct from this that at the moment, my Cable provider has a better internet link than hte averate ADSL provider out here, and that my local segment isn't very crowded.
Roger.
By the time you get out to the 3rd level of cache, on a 1GHz core, there should be enough slow down that chip to chip interconnect will be adequately fast.
Intel had a problem with the Pentium Pro, remember? The two-chips-in-a-package setup ended up being very expensive.
They then went to multiple chips on a board, which fits into a slot. This proved to be too expensive as well. So they went back to producing single chip CPUs.
Think twice before you say that intel should cost-effectively do multiple chips....
Roger.
Does anybody know if I will be able to run this on my PDT-11?
(Which as far as I know has a whopping 56k words of RAM).
Roger.
The idea is that you'd make a cluster with a whole bunch of virtual machines, say 1024.
Good plan. There's a large BUT however....
There are two sources for N processors not being N times as fast as one.
First there is the communications overhead. If you have 1024 virtual processors, running on 32 real processors, there are going to be about 32 programs running and communicating on one processor, while they could've gotten by without communicating at all...
Also, the problem may not be divisable in 1024 equal chunks.
If you write your software to scale to 32, there is going to be a parameter that says how many processors there are already. So adjusting it to 64 is not going to be hard.
But test-running on a small (but virtually large!) cluster before running it on the "real cluster" could allow you to guess the magnitude of both "performance impacting issues" before buying time on the expensive "real cluster". So there certainly is a point in doing it that way....
Roger.
4M pages is not a "mode" that you would put the CPU in. It is a per-table-entry thingy.
For specialized applications (say a machine with 64G of RAM, running HUMOUNGOUS applications) you might chose to run with 4M pages exclusively. Linux doesn't.
In practise you would still use 4k pages for userspace, and 4M pages where it is immediatly obvious that it doesn't make sense to use 4k pages.
Roger.
The AMD erratum says that it is an issue if bit 21 of an address is actually 1. Thus you may have been lucky in where your video card got mapped.
Roger.
... Internal fragmentation would go through the roof.
Think about it. What ISN"T fragmented?
Well two things: The linearly mapped image of main memory for direct access by the kernel and the video memory.
That's exactly where it's used for. For every 4Mb of kernel-memory that you touch, the CPU would have to load 1024 page table entries using 4k pages, and just one for 4M pages. Each of them goes into the TLB and would put pressure on the TLB to evict other entries.
Still, you'd have a hard time measuring a difference.
{
int tot[1024], arr[1024][1024], x, y;
for (x=0;x1024;x++) {
tot[x] = 0;
for (y=0;y1024;y++)
tot[x] += arr[y][x];
}
}
will show something close to the maximum possible difference: You're accessing 1024 different pages, requiring a page table lookup for every single access... Swap the y and the x in the arr[y][x] and the difference has shrunk by a factor of 1000.
Roger.
Better? Better???
They decided not to use the (albeit small) performance benefit that the processor offers, and then claim to be better.
Yeah. Right.
Roger.
Nope Won't work:
The spammers find a "open relay" (like they do now) and put the burden on those "other hosts".
Roger.
Without reading their website, the claim MUST BE FALSE.
The proof is simple.
Suppose we have a 100 bit message. There are 2^100 different messages. Suppose you can compress them on average to 98 bits. Then there can only be 2^98 compressed messages. We lost a couple along the way!
This proves that if you compress SOME messages you will also have to make SOME longer. Not by much, but at least a little. (prepend 1 if "not compressable" prepend zero to the "compressed data stream" and you have a "worst case expansion" of "one bit")
Now compressing normal data is easy. There are a lot of repeats, and other redundancy. So the normal case is that you can compress them. The bad news is that if you enumerate ALL 100-bit messages, ALL compression methods are going to need on average 100 bits or more. This is pure mathematics.
The 2^100 number is a number that is quite large, but if you start talking about compressing a megabyte of data, then I'm already talking about enumerating all 2^8000000 possible messages. That is a thought experiment. But the argument still holds.
-----
I read their pressrelease. It's buzzword compliant bovine excrement. They will attract money and pay the existing people large salaries as long as they
can keep up the charade.
Oh, and they have placed a tactical "practically" in front of the word "random". I can compress "practically random data" by enormous amounts.
If you take the MD5 hash of the string "hi there", and feed that back into the MD5 function, you can generate an endless stream of "practically random" data. Take the first 1Mb of this "practically random" data.
I compressed 1Mbyte of data into the 212 bytes of the previous paragraph! However this is not possible if I let someone else generate the random data any way he pleases, and then have to compress it. They can claim to be "technically correct" up to a point due to this phenomenon....
Roger.
The process by which a fuel cell works is all 'one way', and unlikely to be degraded in the above way.
Ehmm. Wrong. Fuel cells work on Hydrogen and Oxygen. Oxygen comes from the air. The hyrdogen is extracted from the methanol. The system that is used for that is slowly clogged by any and all impurities that end up in your methanol.
Roger.
We don't walk around saying that 10 miles high building cannot be built because we have never built one, do we?
Right. But we can do the math to prove that materials like concrete and steel don't work for that kind of structure.
Proper encryption rules state that the adversary knows everything except your keys. In this case we know that the "command structure" is just a bit complex and non-documented. Nothing to do with having to guess at 128 bit encryption keys.
If you monitor the "normal" traffic to the satelite for a month or so, the command-structure should be pretty clear. Checksums on the packets are also deductable. Then it's easy to send a stream of more or less random commands to the satelite. Chances are it will shoot a couple of random pictures, and then spin off uncontrollably back into the atmosphere.
That would be quite a bummer, don't you think?
My recommendation is to have some simple sort of cryptographic authentication. So the groundstation signs "please do XX at t=YY" with a PGP signature. Think for a second to make replay attacks impossible (*). Problem solved.
Roger.
(*) I just did: have a 32 bit command counter, and have the satelite only accept increasing command counters. Normal procedure is to send them in sequence. If the satelite misses a bunch you have 2 billion commands to try and get it to listen again. Normally you wouldn't get into the "other half of the universe" within say 100 years.
4) *think* about package selection, with a coffee
I've recently installed two systems for "bare minimum, but usable". Both don't have a console. One is just a router/firewall, but needs a few tools for maintenance comfort. 200Mb.
The other is the "sound server". It needs "xmms" and the stuff needed for comfortable maintenance. 224 Mb.
Both started out as "bare minimum" machines, and stuff only got added on an "as needed" basis. So for example, I recently found "RPM" missing: I had always run rpm on the fileserver that serves the NFSroot for the boxes....
Roger.