A line tester will tell you if you've got a physical T1 but can't tell you how much upstream bandwidth is available. Unless the provider is willing to give you SNMP read access to their network (uh, yeah, right, that'll happen), MRTG isn't going to be very helpful either.
The best and most reliable tool for hop-by-hop bandwidth determination we've found is PCHAR:
I'll go you one better. Why spend time thinking about it? Doesn't Linux excel at automation?
DISCLAIMER: This is probably illegal or immoral and I myself would never concieve of actually doing such a thing, much less telling someone else to. For Entertainment value only. There's probably an easier way to do it if you're a WGET expert.
Go to this URL, and save the page source. Copy out the search results, eliminate all the useless BS of the frame, and page, etc. You just want those massive GOTO.COM links.
Run a search-and-replace, replacing all instances of: HREF=/d/sr With HREF=www.goto.com/d/sr
Save the results as/tmp/spammers.
Set up a cron job to run once daily using WGET, like this:
wget -qHr -l1 --spider -i/tmp/spammers
TA DA! Instant drain to spammer resources, the world over. Update your SPAMMERS file every few weeks, as this will probably drive many of them out of business very quickly.
You say that the system achieves 90-95% accuracy, but then your README file says "The accuracy isn't very good because the training set wasn't very amenable to personal emails"
So what gives? Does it work, or not?
As for MAPS, the low hit rate is because it's based on DNS, and the number of unsecured mail servers approaches infinity. You just can't catch 'em as fast as they pop up, you really can't. Searching the text of the email (as your program does) is a better solution but one that can only be adequately implemented in a highly distributed way (i.e., at the client or possibly mailserver level). If you're an ISP and deal with 3 million SPAMs a day, processing the text isn't computationally desirable.
The problem with prioritization is that it works great in theory, then you put the scheme in user-space and it falls apart. What's to stop users from applying a high-priority to their web traffic?
If the users control it, the best you can hope for is "Geeks who know how to set IP Precedence fields get to go first!"
On second thought, maybe that's not a bad thing, after all.:)
Seriously though, unless you're policing the priorities, it's impossible to make this work in the real world; and if you *ARE* policing the priorities, you're more likely to introduce latency that will degrade performance when there isn't a crisis.
*sigh* _________________________________
Re:why such a fast RAMDAC?
on
Nvidia's NV20
·
· Score: 1
You need it to run decent refresh rates on the new 200dpi monitors at 2560x2048.
I want my 42x 126 micron sub-pixels!
_________________________________
It IS interesting to note that the recompiled version also helped the P3 and Athlon. It does seem to indicate the original was not compiled optimally.
If you divide the benchmarks by the clock rate, you get a more objective view of the processors, independant of clock rate. By that measure, the P4 is turning out about.00935 per cycle, while the Athlon is just behind it at.00928, and the P3 behind at.00803. This makes sense - the P4 isn't really much faster than the existing technology (Athlon), but it does allow much higher clock speeds, which was Intel's goal all along. Bully for them, they got what they aimed for.
The small problem of course is that you don't get any of that bang with existing apps, which will undoubtably hurt P4 sales for a while. Strictly looking at bang-for-the-buck, the P4 is a poor choice at the current price points, but most new processors are. If AMD can get the Palomino (smaller,faster Athlon) out the door quickly, with SMP support, they could take a bite out of the server market that would have Intel rubbing their bottoms for some time.
While it's not bulletproof (or would that be bullet-resistant?) security, the system is used by a number of firewalls already:
1) An "inside" user makes a request on a known port (for FTP, this would be 20 or 21) to a server somewhere in the world (the "Outside server").
2) The firewall/gateway/router (FW/GW/R) remembers the inside user who made this connection and the NAT address to which they are being translated.*
3) When the Outside Server makes an inbound request connection to the address that the inside user is being translated to, the FW/GW/R thinks "Hey, this person just asked for a connection on another port, and using my 'FTP' rule, that means that the outside server is likely to ask for a connection on a different port - this must be it!" and passes the connection to the inside address.
Voila - dynamic inbound port assignment without specific client support!
Now, this isn't perfect. Some high-density PAT (port-address translation) environments will require fairly advanced rules in the FW/GW/R, but it works for most of the tier-1 firewalls (Cisco PIX, Checkpoint, etc).
*we'll have to assume that the NAT address translations are persistant for at least a few minutes. Most NAT solutions work this way anyway. _________________________________
..to peer-to-peer connection requests should be intellegence in the firewalls or routers. Once they're aware enough of the application to recognize a "requested" inbound connection that doesn't exactly match an "originated" connection, the problem goes away. Many firewalls already do this with outbound FTP access to eliminate the need for PASV transfers.
If a suitable peer-to-peer protocol were well-documented (read RFC) and widely implemented, it wouldn't take long before the vendors started picking up support for it. Problem solved. _________________________________
Slashdot Mirror
A line tester will tell you if you've got a physical T1 but can't tell you how much upstream bandwidth is available. Unless the provider is willing to give you SNMP read access to their network (uh, yeah, right, that'll happen), MRTG isn't going to be very helpful either.
The best and most reliable tool for hop-by-hop bandwidth determination we've found is PCHAR:
http://www.employees.org/~bmah/Software/pchar/
Or at the very very least, completely replace ICANN, Verisign, Internic, ARIN, and BIND.
DISCLAIMER: This is probably illegal or immoral and I myself would never concieve of actually doing such a thing, much less telling someone else to. For Entertainment value only. There's probably an easier way to do it if you're a WGET expert.
HREF=/d/sr
With
HREF=www.goto.com/d/sr
Save the results as
wget -qHr -l1 --spider -i
TA DA! Instant drain to spammer resources, the world over. Update your SPAMMERS file every few weeks, as this will probably drive many of them out of business very quickly.
You say that the system achieves 90-95% accuracy, but then your README file says "The accuracy isn't very good because the training set wasn't very amenable to personal emails"
So what gives? Does it work, or not?
As for MAPS, the low hit rate is because it's based on DNS, and the number of unsecured mail servers approaches infinity. You just can't catch 'em as fast as they pop up, you really can't. Searching the text of the email (as your program does) is a better solution but one that can only be adequately implemented in a highly distributed way (i.e., at the client or possibly mailserver level). If you're an ISP and deal with 3 million SPAMs a day, processing the text isn't computationally desirable.
_________________________________
The problem with prioritization is that it works great in theory, then you put the scheme in user-space and it falls apart. What's to stop users from applying a high-priority to their web traffic?
:)
If the users control it, the best you can hope for is "Geeks who know how to set IP Precedence fields get to go first!"
On second thought, maybe that's not a bad thing, after all.
Seriously though, unless you're policing the priorities, it's impossible to make this work in the real world; and if you *ARE* policing the priorities, you're more likely to introduce latency that will degrade performance when there isn't a crisis.
*sigh*
_________________________________
You need it to run decent refresh rates on the new 200dpi monitors at 2560x2048.
I want my 42x 126 micron sub-pixels!
_________________________________
It IS interesting to note that the recompiled version also helped the P3 and Athlon. It does seem to indicate the original was not compiled optimally.
.00935 per cycle, while the Athlon is just behind it at .00928, and the P3 behind at .00803. This makes sense - the P4 isn't really much faster than the existing technology (Athlon), but it does allow much higher clock speeds, which was Intel's goal all along. Bully for them, they got what they aimed for.
If you divide the benchmarks by the clock rate, you get a more objective view of the processors, independant of clock rate. By that measure, the P4 is turning out about
The small problem of course is that you don't get any of that bang with existing apps, which will undoubtably hurt P4 sales for a while. Strictly looking at bang-for-the-buck, the P4 is a poor choice at the current price points, but most new processors are. If AMD can get the Palomino (smaller,faster Athlon) out the door quickly, with SMP support, they could take a bite out of the server market that would have Intel rubbing their bottoms for some time.
_________________________________
While it's not bulletproof (or would that be bullet-resistant?) security, the system is used by a number of firewalls already:
1) An "inside" user makes a request on a known port (for FTP, this would be 20 or 21) to a server somewhere in the world (the "Outside server").
2) The firewall/gateway/router (FW/GW/R) remembers the inside user who made this connection and the NAT address to which they are being translated.*
3) When the Outside Server makes an inbound request connection to the address that the inside user is being translated to, the FW/GW/R thinks "Hey, this person just asked for a connection on another port, and using my 'FTP' rule, that means that the outside server is likely to ask for a connection on a different port - this must be it!" and passes the connection to the inside address.
Voila - dynamic inbound port assignment without specific client support!
Now, this isn't perfect. Some high-density PAT (port-address translation) environments will require fairly advanced rules in the FW/GW/R, but it works for most of the tier-1 firewalls (Cisco PIX, Checkpoint, etc).
*we'll have to assume that the NAT address translations are persistant for at least a few minutes. Most NAT solutions work this way anyway.
_________________________________
..to peer-to-peer connection requests should be intellegence in the firewalls or routers. Once they're aware enough of the application to recognize a "requested" inbound connection that doesn't exactly match an "originated" connection, the problem goes away. Many firewalls already do this with outbound FTP access to eliminate the need for PASV transfers.
If a suitable peer-to-peer protocol were well-documented (read RFC) and widely implemented, it wouldn't take long before the vendors started picking up support for it. Problem solved.
_________________________________