A reference in the article about the equivalence principle reminded me that Einstein stated that there's no experiment that would enable an observer in a constantly accelerating, windowless vehicle to determine that they weren't stationary in a gravitional field.
Your statement does not accurately reflect what Einstein said (it reflects what many high school physics teachers teach that Einstein said). Einstein only required with the equivalence principle that there is no way to tell locally the difference between acceleration and gravity.
In essence, Einstein was wrong about the accelerating, windowless vehicle, but he never uses your particular point of contention in the math for the final theory.
There are as many backups as there are strands of hair on the researchers head (since every strand is a backup). The only problem is the backups are a bit hard to read.
Testing was done using n identical clients, all flooding synchronous requests. i.e. each client sits in a "send, wait for reply" loop.
This is highly unrealistic for most applications, and is exactly the reason you are seeing performance issues. Most likely the server is processing the requests fine, but the client is sending them too slowly.
If your tests accurately reflect the expected usage, you're probably best off not using select() or I/O completion points or anything at all, and instead simply using nonblocking I/O in a loop.
Select() does have a problem with latency, and your lock-step test is exploiting that problem perfectly. In a real world internet environment the latency of the end-to-end connection is almost always going to cancel that out anyway, but if you really do have such non-random usage patterns you should be using that information to predict which filedescriptors are likely to have data instead of select()ing them at all.
The bottleneck is network bandwidth - we get sub-optimum performance except on Gb ethernet.
If the bottleneck is network bandwidth then how can the bottleneck also be select()? The increase in performance when using Gb ethernet might be the decrease in latency, not the increase in bandwidth. But that's just a pure guess.
It would also take away everyone else's anonymity.
I can't see any reason why someone would want to receive unsolicited anonymous email. If they are soliciting the anonymous mail they can allow that key. If someone wants to receive unsolicited anonymous mail, then they can't block spam at the same time.
Firstly, it is the postal service's precautions that have limited the death toll to five
Then why is it that since the irradiation started, no one has been killed by the 99% of the mail which isn't irradiated. Read the article, only mail being sent to federal buildings is being irradiated.
What's the likelyhood that more anthrax will be spread via mail?
Very little mail is being irradiated. I received a total of one letter that was irradiated. Considering that that letter was probably stuck in the Hamilton post office when it was shut down (judging from the postmark), I think they made the right choice.
They've been saying this since the process started. In fact, the plastic bad that my irradiated mail arrived in had the following note on it:
November 2001
Dear Postal Customer:
The mail that is being delivered in this bag has been irradiated at a facility in Bridgeport, New Jersey. The irridiation process used at the Bridgeport facility was tested and found to be effective in destroying anthrax by an interagency team of scientific experts that recommended release of this mail for delivery. While the irradiation process is safe, it can affect some products that might be contained in this mail. The products on this list, if contained in a package or envelope that has been irridiated, should not be used. You should discard them and obtain replacements.
Any biological sample, such as blood, fecal samples, etc., could be rendered useless.
Diagnostic kits, such as those used to monitor blood sugar levels, could be adversely affected.
Photographic film will be fully exposed.
Food will be adversely affected.
Drugs and medicines may not be effective and their safety could be affected.
Eyeglasses and contact lenses could be adversely affected.
Electronic devices would likely be inoperable.
While the irradiation process sucessfully kills anthrax, if your mail contains any suspicious substances we urge you to set it aside and contact local law enforcement authorities. This can help in the investigation.
The group of experts that tested the irradiation process was organized by the White House Office of Science and Technology Policy and included the Armed Forces Radiobiology Research Institute, the Food an Drug Administration, the Department of Agriculture and the National Institute of Standards and Technology.
We apologize for the delay in delivery of this mail and for any inconvienience that may have resulted. Our primary interest is to assure that this mail is safe before being delivered to you. More information is available at 1-800-ASK-USPS.
Thank you for your understanding.
Sincerely,
Thomas G. Day
Vice President, Engineering
The letter was yellow and fell apart to some extent when I opened the envelope.
Select() is only expensive with idle connections. If the connection is not idle then select() only adds a trivial constant overhead.
The only assumption I'm making is that all connections being handled by select() have approximately the same throughput rates. If that assumption is made, then select will scale O(n) on the number of connections, but the number of requests handled per call of select() will also scale O(n) on the number of connections. Amortized over the requests handled, select() only adds a constant overhead.
That's the theory. The reality is that I have yet to see a real world case where there is an even distribution of load and yet select() is the performance bottleneck. I'm not denying that you're seeing a bottleneck at 250 connections. There may not even be a bug anywhere, you might just be seeing the maximum throughput for your particular situation.
Don't get me wrong,/dev/poll and the others are an improvement to select()/poll() in most circumstances. The interface is certainly more appropriate. But in terms of real world scalability, they don't help at all. Show me the benchmark showing otherwise, and I'll show you the flaw (the general flaw is sending only one request per select()).
Tiger Woods didn't lose anything. The idiot credit card companies who gave Taylor the credit cards did, and they probably got it back. Tiger Woods will get the incident reported on his credit report, and credit card companies will require better proof of identity in the future.
This is precisely why I advocate social security numbers being made public knowledge. Only then will SSNs not be used as security devices.
What I'm more worried about is the fact that my SSN is on my driver's license, and I want it OFF.
I couldn't disagree with you more. Personally I want the SSN of everyone listed next to their phone number in the phone book. That is how you stop identity theft.
Lose my walet, and I can lose my idenity.
Bill Gates SSN is 539-60-5125. I'd like to see you steal his identity.
Everyone agrees that encryption is a good idea and we should all be using it, but do you actually know anyone who does?
Sorry about picking nits, but anyone who has ever visited an https site uses encryption. I use encryption every day, to ssh to my server.
I don't use pgp, but that's because it simply isn't easy to use. Across the board use of pgp would pretty much eliminate spam. One day maybe people will see the light.
More than one process can't use the same IP/port pair on a machine.
More than one connection can't use the same 5-tuple of remote address, remote port, protocol, local address, local port. Multiple processes can use the same local address, local port, protocol 3-tuple, but some OSes have problems when multiple processes do an accept on that same 3-tuple from multiple processes. In any case, these limitations can be easily solved by using multiple local IP addresses and/or multiple local ports. I have seen up to 256 IP addresses on a single ethernet card with no problems. If bandwidth becomes a problem before CPU you can add multiple ethernet cards. You can then use round robin DNS to balance the load between different processes, or (preferably) build the port selection into the client/server protocol. Putting just a small bit of intelligence into the client will save you orders of magnitude in terms of simplicity, reliability, and scalability. You also could, but probably shouldn't, use a load balancer, to present a single IP/port combination to the world.
I'm almost tempted to do a quick test to confirm it, but I'm almost certain I've seen the 64K connections/machine broken. This was over a year ago, on FreeBSD. I'd imagine Solaris and Linux are able to do it as well, by this point.
Slashdot has been found to be rigging a government study. Apparently after posting this article tens of thousands of messages came in opposing the Microsoft position. Over 800 messages were found to come from the same email address, and 6000 of the messages simply said "Microsoft Sucks, First Coment!" Slashdot should be reprimanded for this concerted effort to subvert the government's processes.
Basically if you are using select() or poll() and have 10000 connections, you can expect 30% of your timeslice (on a fast machine) to be taken scanning the connection list for available data.
Not exactly. For an instant messaging server, at the least, the more time you spend in select(), the more filedescriptors you are likely to select. You wind up wasting CPU time when there is little activity, but CPU time doesn't matter as long as you are handling requests at least as fast as they are coming in. In actual practice, using select() affects latency (on the order of milliseconds), but amortized the scalability is nearly O(n).
Your performance also goes down the drain after about 250 connections (empirical observation; our server handles async requests which are offloaded to a hardware device for processing, so most server overhead is packet handling).
This is likely a bug in the OS configuration, or the OS kernel. I've seen machines easily handle 10,000 connections without blinking. When testing an instant messaging server I wrote, a pentium III running FreeBSD easily handled 10,000 connections on a single process.
I bought Windows 2.0, Windows 3.0, Windows 3.1415926, Windows 95, Windows 98, Windows ME, Windows RSVP, The Best of Windows, Windows Strikes Back, Windows Does Dallas, and Windows Let's All Buy Bill Gates a House the Size of Vermont.
There's the problem. Windows 2000 and XP are far more stable than any of those. I find Windows 2000 to be more stable than gnome/linux. I haven't used XP enough to compare.
Of course I'm writing this on Gnome/Linux because it's gotten to the point where I only have to reboot every few days.
No copyright infringment suit can be brought against someone making home digital recordings.
if the recording is made using a digital audio recording device. If you burn the mp3s to hard drive, you're not protected, because no "tax" is collected on hard drives. If you burn the mp3s to DAT tape, or Audio CD-R, you are protected.
The point that copy-proof cds violate the spirit of this law is a good one.
Not really, because the CDs work fine in AHRA-covered players, such as audio CD players. What they don't work in is computer CD players, which are not covered by the AHRA because they and the computers they connect to are not made for the primary purpose of audio recording.
it's still legal to make copies, but we won't make it possible.
Actually, the AHRA doesn't even make it legal, it only says that no suit can be brought. Which is part of the reason that mp3.com could still be sued for contributory copyright infringement even though the direct infringers may have been protected under the AHRA.
Check this out... I make a quick 1 minute phone call on my mobile phone to the radio station DJ and, most of the time, they start streaming my requested song to my car very shortly. It's called FM Radio; check it out.
Really? I imagine that if I called any radio stations in my listening area and asked them to play Sgt. Peppers (the album), they'd laugh and hang up.
And other listeners in broadcast range receive the fruits of my excellent musical taste!
Same with this, if you give them the key (or whatever is protecting the stream).
I don't know if you actually dislike the idea or you're just trying to be funny, but I see a huge market for one-way, broadcast, personalizible content.
Hell, it's even a great and relatively cheap distribution channel for multicasting. The big question is how much bandwidth is actually available. I can't imagine $40/month buying me my own broadcast radio station.
Slashdot Mirror
A reference in the article about the equivalence principle reminded me that Einstein stated that there's no experiment that would enable an observer in a constantly accelerating, windowless vehicle to determine that they weren't stationary in a gravitional field.
Your statement does not accurately reflect what Einstein said (it reflects what many high school physics teachers teach that Einstein said). Einstein only required with the equivalence principle that there is no way to tell locally the difference between acceleration and gravity.
In essence, Einstein was wrong about the accelerating, windowless vehicle, but he never uses your particular point of contention in the math for the final theory.
Commerce is not speech. You may have the right to utter the incorrect program, but that doesn't give you the right to sell it.
I agree with you that it isn't a good law, but it doesn't infringe on freedom of speech.
There are as many backups as there are strands of hair on the researchers head (since every strand is a backup). The only problem is the backups are a bit hard to read.
Testing was done using n identical clients, all flooding synchronous requests. i.e. each client sits in a "send, wait for reply" loop.
This is highly unrealistic for most applications, and is exactly the reason you are seeing performance issues. Most likely the server is processing the requests fine, but the client is sending them too slowly.
If your tests accurately reflect the expected usage, you're probably best off not using select() or I/O completion points or anything at all, and instead simply using nonblocking I/O in a loop.
Select() does have a problem with latency, and your lock-step test is exploiting that problem perfectly. In a real world internet environment the latency of the end-to-end connection is almost always going to cancel that out anyway, but if you really do have such non-random usage patterns you should be using that information to predict which filedescriptors are likely to have data instead of select()ing them at all.
The bottleneck is network bandwidth - we get sub-optimum performance except on Gb ethernet.
If the bottleneck is network bandwidth then how can the bottleneck also be select()? The increase in performance when using Gb ethernet might be the decrease in latency, not the increase in bandwidth. But that's just a pure guess.
It would also take away everyone else's anonymity.
I can't see any reason why someone would want to receive unsolicited anonymous email. If they are soliciting the anonymous mail they can allow that key. If someone wants to receive unsolicited anonymous mail, then they can't block spam at the same time.
And preferably find another carrier that tells you this before you send your items through the system.
Or just pay for insurance on your shipments.
Firstly, it is the postal service's precautions that have limited the death toll to five
Then why is it that since the irradiation started, no one has been killed by the 99% of the mail which isn't irradiated. Read the article, only mail being sent to federal buildings is being irradiated.
What's the likelyhood that more anthrax will be spread via mail?
Very little mail is being irradiated. I received a total of one letter that was irradiated. Considering that that letter was probably stuck in the Hamilton post office when it was shut down (judging from the postmark), I think they made the right choice.
They've been saying this since the process started. In fact, the plastic bad that my irradiated mail arrived in had the following note on it:
The letter was yellow and fell apart to some extent when I opened the envelope.
Select() is only expensive with idle connections. If the connection is not idle then select() only adds a trivial constant overhead.
The only assumption I'm making is that all connections being handled by select() have approximately the same throughput rates. If that assumption is made, then select will scale O(n) on the number of connections, but the number of requests handled per call of select() will also scale O(n) on the number of connections. Amortized over the requests handled, select() only adds a constant overhead.
That's the theory. The reality is that I have yet to see a real world case where there is an even distribution of load and yet select() is the performance bottleneck. I'm not denying that you're seeing a bottleneck at 250 connections. There may not even be a bug anywhere, you might just be seeing the maximum throughput for your particular situation.
Don't get me wrong, /dev/poll and the others are an improvement to select()/poll() in most circumstances. The interface is certainly more appropriate. But in terms of real world scalability, they don't help at all. Show me the benchmark showing otherwise, and I'll show you the flaw (the general flaw is sending only one request per select()).
Tiger Woods didn't lose anything. The idiot credit card companies who gave Taylor the credit cards did, and they probably got it back. Tiger Woods will get the incident reported on his credit report, and credit card companies will require better proof of identity in the future.
This is precisely why I advocate social security numbers being made public knowledge. Only then will SSNs not be used as security devices.
What I'm more worried about is the fact that my SSN is on my driver's license, and I want it OFF.
I couldn't disagree with you more. Personally I want the SSN of everyone listed next to their phone number in the phone book. That is how you stop identity theft.
Lose my walet, and I can lose my idenity.
Bill Gates SSN is 539-60-5125. I'd like to see you steal his identity.
Everyone agrees that encryption is a good idea and we should all be using it, but do you actually know anyone who does?
Sorry about picking nits, but anyone who has ever visited an https site uses encryption. I use encryption every day, to ssh to my server.
I don't use pgp, but that's because it simply isn't easy to use. Across the board use of pgp would pretty much eliminate spam. One day maybe people will see the light.
AFAIK, ephemeral ports for sockets are a system-wide resource.
Aren't ephemeral ports only used for outgoing connections, not incoming ones?
More than one process can't use the same IP/port pair on a machine.
More than one connection can't use the same 5-tuple of remote address, remote port, protocol, local address, local port. Multiple processes can use the same local address, local port, protocol 3-tuple, but some OSes have problems when multiple processes do an accept on that same 3-tuple from multiple processes. In any case, these limitations can be easily solved by using multiple local IP addresses and/or multiple local ports. I have seen up to 256 IP addresses on a single ethernet card with no problems. If bandwidth becomes a problem before CPU you can add multiple ethernet cards. You can then use round robin DNS to balance the load between different processes, or (preferably) build the port selection into the client/server protocol. Putting just a small bit of intelligence into the client will save you orders of magnitude in terms of simplicity, reliability, and scalability. You also could, but probably shouldn't, use a load balancer, to present a single IP/port combination to the world.
I'm almost tempted to do a quick test to confirm it, but I'm almost certain I've seen the 64K connections/machine broken. This was over a year ago, on FreeBSD. I'd imagine Solaris and Linux are able to do it as well, by this point.
Slashdot has been found to be rigging a government study. Apparently after posting this article tens of thousands of messages came in opposing the Microsoft position. Over 800 messages were found to come from the same email address, and 6000 of the messages simply said "Microsoft Sucks, First Coment!" Slashdot should be reprimanded for this concerted effort to subvert the government's processes.
If you're thinking of going to the trouble of simulating TCP with raw sockets, UDP seems a simpler alternative to that.
This being an instant messaging server, presumably for the public, UDP would have too many problems going through certain firewalls.
Basically if you are using select() or poll() and have 10000 connections, you can expect 30% of your timeslice (on a fast machine) to be taken scanning the connection list for available data.
Not exactly. For an instant messaging server, at the least, the more time you spend in select(), the more filedescriptors you are likely to select. You wind up wasting CPU time when there is little activity, but CPU time doesn't matter as long as you are handling requests at least as fast as they are coming in. In actual practice, using select() affects latency (on the order of milliseconds), but amortized the scalability is nearly O(n).
Your performance also goes down the drain after about 250 connections (empirical observation; our server handles async requests which are offloaded to a hardware device for processing, so most server overhead is packet handling).
This is likely a bug in the OS configuration, or the OS kernel. I've seen machines easily handle 10,000 connections without blinking. When testing an instant messaging server I wrote, a pentium III running FreeBSD easily handled 10,000 connections on a single process.
A single server can handle at most around 64000 open sockets.
If my memory serves me correctly one can easily break the 64K limit by using multiple processes. This wasn't on Solaris, though.
Is anybody aware of off-the-shelf software and/or hardware solutions (either commercial or freeware)?
Assuming you have control over the protocol, I've written such a server. I don't have the code, but my non-compete agreement has expired.
But if a programmer or other computer worker cannot use their hands, that isn't a disability.
If someone cannot use their hands, that's a disability. It's also not the facts of the case at hand.
Are they also auctioning off the copyright to the code?
I bought Windows 2.0, Windows 3.0, Windows 3.1415926, Windows 95, Windows 98, Windows ME, Windows RSVP, The Best of Windows, Windows Strikes Back, Windows Does Dallas, and Windows Let's All Buy Bill Gates a House the Size of Vermont.
There's the problem. Windows 2000 and XP are far more stable than any of those. I find Windows 2000 to be more stable than gnome/linux. I haven't used XP enough to compare.
Of course I'm writing this on Gnome/Linux because it's gotten to the point where I only have to reboot every few days.
No copyright infringment suit can be brought against someone making home digital recordings.
if the recording is made using a digital audio recording device. If you burn the mp3s to hard drive, you're not protected, because no "tax" is collected on hard drives. If you burn the mp3s to DAT tape, or Audio CD-R, you are protected.
The point that copy-proof cds violate the spirit of this law is a good one.
Not really, because the CDs work fine in AHRA-covered players, such as audio CD players. What they don't work in is computer CD players, which are not covered by the AHRA because they and the computers they connect to are not made for the primary purpose of audio recording.
it's still legal to make copies, but we won't make it possible.
Actually, the AHRA doesn't even make it legal, it only says that no suit can be brought. Which is part of the reason that mp3.com could still be sued for contributory copyright infringement even though the direct infringers may have been protected under the AHRA.
Check this out... I make a quick 1 minute phone call on my mobile phone to the radio station DJ and, most of the time, they start streaming my requested song to my car very shortly. It's called FM Radio; check it out.
Really? I imagine that if I called any radio stations in my listening area and asked them to play Sgt. Peppers (the album), they'd laugh and hang up.
And other listeners in broadcast range receive the fruits of my excellent musical taste!
Same with this, if you give them the key (or whatever is protecting the stream).
I don't know if you actually dislike the idea or you're just trying to be funny, but I see a huge market for one-way, broadcast, personalizible content.
Hell, it's even a great and relatively cheap distribution channel for multicasting. The big question is how much bandwidth is actually available. I can't imagine $40/month buying me my own broadcast radio station.