You're not being limited by ethernet. You're being limited by the built-in "fairness" of TCP: when there is a limited supply of bandwidth, TCP limits its packet rate to share the bandwidth equitably. Adding a second ethernet connection won't do anything to change that: what you need is to work around the semantics of TCP.
In other words, either open two TCP connections (remember back when Netscape used to open four connections at once to speed stuff up?) or hack your TCP implementation to be more aggressive.
If you're dealing with the BSD license, you're fine. BSD is about Open Source: The source code is there, it is open, and you can do what you like with it.
If it is GPL, you're screwed. GPL is about deliberate incompatibility -- it won't co-exist with any other license.
This isn't the answer that you're looking for, but what you suggest shouldn't be a problem.
Even if all you've ever done in your life is programming, being suddenly unable to program should not make you useless. Ok, you can't program any more. But you have years (decades?) of experience: instead of programming, teach others to program. Or move into architectural design -- most of the work there is thinking, drawing pictures, and handwaving -- or even move into (gasp) management.
In my opinion, a programmer who can't do anything other than program probably isn't a good programmer. And we're all good programmers, here, right?
Aren't you going about things rather backwards? You want to send a small *average* data rate, but you want a high *peak* data rate. Those circumstances are exactly when you want to share a fat pipe with thousands of other systems in a colocation facility.
Mean traffic scales linearly with the number of servers. Standard deviation scales with the square root of the number of servers. The greater sigma/mu is, the more important it is to share your pipe with other people.
Cobalt servers are expensive crap. Before you mod this down as flamebait, think about the following:
Say you've got $5000 to spend on a new server. You can get one of two 1U rackmounted servers:
Option 1: 450Mhz processor, 512MB RAM, two 5400RPM 30GB mirrored (RAID-1) drives, lots of free software.
Option 2: Two 1GHz processors, 1024MB RAM, two hot-swappable 10K RPM Ultra-160 SCSI 36GB mirrored (RAID-1) drives, and the identical free software.
Option 1 is a cobalt Raq. Option 2 is a Supermicro 6010L with 1GHz Pentium III processors, Supermicro certified memory, and IBM drives.
What it comes down to is that a $5000 Cobalt RaQ is a $1000 system with a $4000 name.
I'd say to build your own boxes -- I can't imagine anyone here would have trouble working where things go -- but if you don't want to do that, get systems from VA Linux or BSDI; as for software, take a look at webmin, there are very few server applications which do not have webmin plugins, and with webmin you can give restricted access to people as you see fit.
(OT: where did the bandwidth and server space come from, anyway?)
... at least not if the ICANN UDRP is applied. One of the requirements for tranfer of a domain name is that it is being used "in bad faith". No problem there, they are deliberately misleading people. Right?
Wrong.
The four criteria which can construe "bad faith" are:
(i) circumstances indicating that you have registered or you have acquired the domain name primarily for the purpose of selling, renting, or otherwise transferring the domain name registration to the complainant who is the owner of the trademark or service mark or to a competitor of that complainant, for valuable consideration in excess of your documented out-of-pocket costs directly related to the domain name; or
(ii) you have registered the domain name in order to prevent the owner of the trademark or service mark from reflecting the mark in a corresponding domain name, provided that you have engaged in a pattern of such conduct; or
(iii) you have registered the domain name primarily for the purpose of disrupting the business of a competitor; or
(iv) by using the domain name, you have intentionally attempted to attract, for commercial gain, Internet users to your web site or other on-line location, by creating a likelihood of confusion with the complainant's mark as to the source, sponsorship, affiliation, or endorsement of your web site or location or of a product or service on your web site or location.
For the first one, they have shown no sign of wanting to sell the domain name, so that doesn't apply. For the second, AFAIK they haven't "engaged in a pattern of such conduct", so that doesn't apply.
For the third, the WTO isn't a competitor of theirs, so that doesn't apply. And the last doesn't apply because they aren't trying to attrack users for commercial gain.
So even though the domain was obviously registered in bad faith, none of the "bad faith" requirements are met, and the domain shouldn't be transferred according to the UDRP.
Of course, that hasn't stopped WIPO in the past...
You should make your version numbers as complicated as possible, to drive away people who shouldn't be touching your code.
Instead of using simple numbers like 1.1, 2.0, and 3.141592653, use numbers like 2.2.14, 2.3.99, or 2.4.0test12345. You'll see an immediate improvement in the number of clueless newbies who get anywhere near your code.
Another solution is to simply adopt fuzzy names. Call something 4.2-STABLE, but keep on making changes to it, so that when someone reports a bug and says they are running 4.2-STABLE, you can ask "which 4.2-STABLE?" and file the bug report under "user didn't submit enough information".
Just like everyone else on/., IANAL. However, here's my uninformed opinion:
You do have legal recourse.
The US is signatory to the Berne convention which among other things guarantees that
Independently of the author's economic rights, and even after the transfer of the said rights, the author shall have the right to claim authorship of the work and to object to any distortion, mutilation or other modification of, or other derogatory action in relation to, the said work, which would be prejudicial to his honor or reputation.
In addition, 43(a) of the Lanham Act, 15 USC 1125(a)(1)(A) prohibits "false designation of origin, false or misleading description of fact" that is "likely to cause confusion,... mistake," or deception about "the affiliation, connection, or association" of a person with any product or service.
Basically, international law provides that you can claim authorship, and US law provides that they cannot claim authorship.
Writing optimizing compilers is a very hard task, and almost all code is still compiled with compilers optimizing for the 486 (gcc anyone?).
Which is exactly why Intel wrote their own optimizing compiler. They're even writing a Linux version, which is supposed to be undergoing a public beta test in January.
Excuse me? What is algorithmically difficult about a shift? A three-year-old can design a variable shift that takes one cycle. It takes a bit of silicon, but it really pays off since you need shifts all the time (math, address calculation,...)
If it is so easy, show me a variable shift which takes less than O(n log n) transistors and O(log n) stages. I sure can't work out how to do it.
In this extremely well written and technical article...
Yeah, right. Ok, lets address stuff in order:
1. Prime95. Prime95 right now is optimized for current processors. The author received a Pentium 4 system a couple weeks ago, and is rewriting his code right now. When the reoptimization is completed, expect a factor of two improvement.
2. Small L1 cache. The author seems to believe that a larger L1 cache is always good. What he fails to address is that larger caches are inherently slower, and going from a 3 cycle 16KB cache to a 2 cycle 8KB cache improves performance, given a fast L2 cache.
3. No L3 cache. Sure this would have been nice -- but also expensive. Given the intelligence of the i850 chipset (including memory look-ahead reads) and the bandwidth of RDRAM, it isn't really necessary.
4. Instruction decode. Hello? Anyone home? At most 1% of instructions will have to be decoded. That's the point of the trace cache. And yes, Virginia, that cache is large enough.
5. Slow rotates and shifts. That's the price you have to pay if you want a fast clock. Variable shifts are algorithmically expensive (in fact, within a factor of log log N of multiplies, but that's a different matter).
6. Etc. I could go on point by point, but the pattern remains. The author clearly doesn't understand the tradeoffs necessary when designing processors, and looks at one side without considering what it is being traded for.
My opinion is that the Pentium 4 is a very well designed processor. Not only did the designers build a processor which can be run at high speeds, they allowed themselves room to add improvements later without requiring a lengthy redesign of the entire processor. High clock speeds mean that signal flight time is a problem? That's why there are two cycles dedicated to moving data across the processor. Got extra silicon? Double the number of SSE units to allow SSE instructions to complete in half the time. Decide that you want an L3 cache? Throw one on.
Sure the Pentium 4 doesn't perform great on code not optimized for it. But neither did the 486, the Pentium, or the Pentium Pro. And which would you prefer to have right now, a 250MHz 386, or a 1GHz Pentium III?
The problem here isn't bandwidth -- it is latency. Every action you take has to be sent to the remote system before it is processed, introducing a latency of at least 25-50 ms.
You see the same problem if you run X off of a server on a different continent... client-server only works for interactive processes if the client is within a few light-milliseconds of the server.
The real point of QoS isn't to provide bandwidth to high-priority packets at the expense of low-priority packets, or even to reduce latency. The point of QoS is to reduce jitter, because some applications (VoIP) really hate jitter.
Separating internet traffic into high-jitter and low-jitter classes could easily reduce VoIP jitter by a factor of 10.
This was well known about a year ago, when it was announved that the first P4s would be on a.18 micron process, and only after they switch to.13 micron would they release the server/workstation version of the Pentium 4.
Anyway, do you really want two 50W processors inside your case? Wait a minute, I guess that's what a dual K7 system would look like anyway.
Unless you are running a large number of servers and using a consistantly high amount of bandwidth, it is much cheaper to colocate.
When you buy bandwidth at a colocation facility, you are buying a 100mbps ethernet port (cheap), plus a share of an OC3 (or an OC12 or whatever).
When you buy bandwidth to your offices, you are buying a T1/fractional T3/T3/whatever. Economies of scale come in here: at least from AT&T, an OC12 connection is 4 times cheaper than a T1 on a per-gigabyte basis.
Unless you are going to be using a huge amount of bandwidth, it is going to be cheaper to share a fat pipe with other people than to buy a narrow pipe for your self.
I agree with you about the US, but not about Canada.
The conservatives are far from dead -- in fact, I'd say they are more alive than Reform (oops, I mean the Alliance). So far the Reform party (oops, I mean the Alliance) has shown no sign of being able to win any seats east of Manitoba -- and even if they win every seat in BC, Alberta, Saskatchewan, and Manitoba, they would still only have 90 seats.
On the other hand, while the Conservatives have less overall support across Canada, they have far more appeal to voters in Ontario, and are far more likely to succeed the Liberals.
The Reform Alliance party is just as much of a regional party as the BQ: It has no chance of ever forming a government because it can only get seats in under a third of the country. The only way they could form a government would be to join up with the Bloc -- which would be political suicide.
Seriously. Math majors are trained to solve problems, design algorithms, and generally do everything you would ever need except coding. Except that learning to code in C is easy, so you'll find that many math majors can do that as well.
If I wanted to hire a coder, I'd get a CS grad. If I want to hire someone who can think about a problem and work out how to solve it, I'll get a math grad.
Slashdot Mirror
http://slashdot.org/comments.pl?sid=01/01/19/15112 33&cid=72
You're not being limited by ethernet. You're being limited by the built-in "fairness" of TCP: when there is a limited supply of bandwidth, TCP limits its packet rate to share the bandwidth equitably. Adding a second ethernet connection won't do anything to change that: what you need is to work around the semantics of TCP.
In other words, either open two TCP connections (remember back when Netscape used to open four connections at once to speed stuff up?) or hack your TCP implementation to be more aggressive.
And no, I'm not going to tell you how to do that.
If you're dealing with the BSD license, you're fine. BSD is about Open Source: The source code is there, it is open, and you can do what you like with it.
If it is GPL, you're screwed. GPL is about deliberate incompatibility -- it won't co-exist with any other license.
Fortunately, OpenSSH is BSD.
This isn't the answer that you're looking for, but what you suggest shouldn't be a problem.
Even if all you've ever done in your life is programming, being suddenly unable to program should not make you useless. Ok, you can't program any more. But you have years (decades?) of experience: instead of programming, teach others to program. Or move into architectural design -- most of the work there is thinking, drawing pictures, and handwaving -- or even move into (gasp) management.
In my opinion, a programmer who can't do anything other than program probably isn't a good programmer. And we're all good programmers, here, right?
Aren't you going about things rather backwards? You want to send a small *average* data rate, but you want a high *peak* data rate. Those circumstances are exactly when you want to share a fat pipe with thousands of other systems in a colocation facility.
Mean traffic scales linearly with the number of servers. Standard deviation scales with the square root of the number of servers. The greater sigma/mu is, the more important it is to share your pipe with other people.
Cobalt servers are expensive crap. Before you mod this down as flamebait, think about the following:
Say you've got $5000 to spend on a new server. You can get one of two 1U rackmounted servers:
Option 1: 450Mhz processor, 512MB RAM, two 5400RPM 30GB mirrored (RAID-1) drives, lots of free software.
Option 2: Two 1GHz processors, 1024MB RAM, two hot-swappable 10K RPM Ultra-160 SCSI 36GB mirrored (RAID-1) drives, and the identical free software.
Option 1 is a cobalt Raq. Option 2 is a Supermicro 6010L with 1GHz Pentium III processors, Supermicro certified memory, and IBM drives.
What it comes down to is that a $5000 Cobalt RaQ is a $1000 system with a $4000 name.
I'd say to build your own boxes -- I can't imagine anyone here would have trouble working where things go -- but if you don't want to do that, get systems from VA Linux or BSDI; as for software, take a look at webmin, there are very few server applications which do not have webmin plugins, and with webmin you can give restricted access to people as you see fit.
(OT: where did the bandwidth and server space come from, anyway?)
Wrong.
The four criteria which can construe "bad faith" are:
For the first one, they have shown no sign of wanting to sell the domain name, so that doesn't apply. For the second, AFAIK they haven't "engaged in a pattern of such conduct", so that doesn't apply.
For the third, the WTO isn't a competitor of theirs, so that doesn't apply. And the last doesn't apply because they aren't trying to attrack users for commercial gain.
So even though the domain was obviously registered in bad faith, none of the "bad faith" requirements are met, and the domain shouldn't be transferred according to the UDRP.
Of course, that hasn't stopped WIPO in the past...
You should make your version numbers as complicated as possible, to drive away people who shouldn't be touching your code.
Instead of using simple numbers like 1.1, 2.0, and 3.141592653, use numbers like 2.2.14, 2.3.99, or 2.4.0test12345. You'll see an immediate improvement in the number of clueless newbies who get anywhere near your code.
Another solution is to simply adopt fuzzy names. Call something 4.2-STABLE, but keep on making changes to it, so that when someone reports a bug and says they are running 4.2-STABLE, you can ask "which 4.2-STABLE?" and file the bug report under "user didn't submit enough information".
You do have legal recourse.
The US is signatory to the Berne convention which among other things guarantees that
In addition, 43(a) of the Lanham Act, 15 USC 1125(a)(1)(A) prohibits "false designation of origin, false or misleading description of fact" that is "likely to cause confusion,
Basically, international law provides that you can claim authorship, and US law provides that they cannot claim authorship.
For more details, I suggest you read this.
Writing optimizing compilers is a very hard task, and almost all code is still compiled with compilers optimizing for the 486 (gcc anyone?).
Which is exactly why Intel wrote their own optimizing compiler. They're even writing a Linux version, which is supposed to be undergoing a public beta test in January.
Excuse me? What is algorithmically difficult about a shift? A three-year-old can design a variable shift that takes one cycle. It takes a bit of silicon, but it really pays off since you need shifts all the time (math, address calculation, ...)
If it is so easy, show me a variable shift which takes less than O(n log n) transistors and O(log n) stages. I sure can't work out how to do it.
In this extremely well written and technical article...
Yeah, right. Ok, lets address stuff in order:
1. Prime95. Prime95 right now is optimized for current processors. The author received a Pentium 4 system a couple weeks ago, and is rewriting his code right now. When the reoptimization is completed, expect a factor of two improvement.
2. Small L1 cache. The author seems to believe that a larger L1 cache is always good. What he fails to address is that larger caches are inherently slower, and going from a 3 cycle 16KB cache to a 2 cycle 8KB cache improves performance, given a fast L2 cache.
3. No L3 cache. Sure this would have been nice -- but also expensive. Given the intelligence of the i850 chipset (including memory look-ahead reads) and the bandwidth of RDRAM, it isn't really necessary.
4. Instruction decode. Hello? Anyone home? At most 1% of instructions will have to be decoded. That's the point of the trace cache. And yes, Virginia, that cache is large enough.
5. Slow rotates and shifts. That's the price you have to pay if you want a fast clock. Variable shifts are algorithmically expensive (in fact, within a factor of log log N of multiplies, but that's a different matter).
6. Etc. I could go on point by point, but the pattern remains. The author clearly doesn't understand the tradeoffs necessary when designing processors, and looks at one side without considering what it is being traded for.
My opinion is that the Pentium 4 is a very well designed processor. Not only did the designers build a processor which can be run at high speeds, they allowed themselves room to add improvements later without requiring a lengthy redesign of the entire processor. High clock speeds mean that signal flight time is a problem? That's why there are two cycles dedicated to moving data across the processor. Got extra silicon? Double the number of SSE units to allow SSE instructions to complete in half the time. Decide that you want an L3 cache? Throw one on.
Sure the Pentium 4 doesn't perform great on code not optimized for it. But neither did the 486, the Pentium, or the Pentium Pro. And which would you prefer to have right now, a 250MHz 386, or a 1GHz Pentium III?
wasn't IBM working on a supercomputer to be used for calculating protein folding?
You're thinking of Blue Gene, which is supposed to hit 1 petaflop.
Unfortunately it isn't supposed to be operational until 2005.
If you remove all the functionality from a linux kernel, is it still a linux kernel?
I'd say that the question you should be asking is "what is the smallest kernel which will do what I want?"
The problem here isn't bandwidth -- it is latency. Every action you take has to be sent to the remote system before it is processed, introducing a latency of at least 25-50 ms.
You see the same problem if you run X off of a server on a different continent... client-server only works for interactive processes if the client is within a few light-milliseconds of the server.
Note how the pentium 4 is recalled so quickly after it's released
Umm, am I missing something here? The Pentium 4 was never recalled.
The real point of QoS isn't to provide bandwidth to high-priority packets at the expense of low-priority packets, or even to reduce latency. The point of QoS is to reduce jitter, because some applications (VoIP) really hate jitter.
Separating internet traffic into high-jitter and low-jitter classes could easily reduce VoIP jitter by a factor of 10.
Isn't that even more than a playstation 2?
I just went outside, and I CAN'T SEE THE ISS.
Oh, did you mean "visible with the naked eye at night"?
This was well known about a year ago, when it was announved that the first P4s would be on a .18 micron process, and only after they switch to .13 micron would they release the server/workstation version of the Pentium 4.
Anyway, do you really want two 50W processors inside your case? Wait a minute, I guess that's what a dual K7 system would look like anyway.
Bad idea. On a good day 50% of packets get through. For interactive sessions that is a Bad Thing.
If you want remote access you'll have to use something more reliable than packet radio.
I guess there won't be any Real Men around any more. After all, it is a well known fact that Real Men use Multics.
Unless you are running a large number of servers and using a consistantly high amount of bandwidth, it is much cheaper to colocate.
When you buy bandwidth at a colocation facility, you are buying a 100mbps ethernet port (cheap), plus a share of an OC3 (or an OC12 or whatever).
When you buy bandwidth to your offices, you are buying a T1/fractional T3/T3/whatever. Economies of scale come in here: at least from AT&T, an OC12 connection is 4 times cheaper than a T1 on a per-gigabyte basis.
Unless you are going to be using a huge amount of bandwidth, it is going to be cheaper to share a fat pipe with other people than to buy a narrow pipe for your self.
I agree with you about the US, but not about Canada.
The conservatives are far from dead -- in fact, I'd say they are more alive than Reform (oops, I mean the Alliance). So far the Reform party (oops, I mean the Alliance) has shown no sign of being able to win any seats east of Manitoba -- and even if they win every seat in BC, Alberta, Saskatchewan, and Manitoba, they would still only have 90 seats.
On the other hand, while the Conservatives have less overall support across Canada, they have far more appeal to voters in Ontario, and are far more likely to succeed the Liberals.
The Reform Alliance party is just as much of a regional party as the BQ: It has no chance of ever forming a government because it can only get seats in under a third of the country. The only way they could form a government would be to join up with the Bloc -- which would be political suicide.
Seriously. Math majors are trained to solve problems, design algorithms, and generally do everything you would ever need except coding. Except that learning to code in C is easy, so you'll find that many math majors can do that as well.
If I wanted to hire a coder, I'd get a CS grad. If I want to hire someone who can think about a problem and work out how to solve it, I'll get a math grad.