Slashdot Mirror

Your boss should have prevented you from abusing your network in this manner. Use rsync with compression enabled and be done with it.

Here's an article about the huge latency caused by bittorrent traffic on your network.

For a fix of your latency problem see: LARTC ultimate traffic conditioner I use it and do not experience these latecies on my *home* network and it also explains reasons for this to occur.

It is not caused only by bittorrent traffic it's caused by any heavy traffic on home networks. It is a fairly common phenomenon with home routers and home internet connection. This is not experienced in serverhousing networks. Also I talk about uploading sustained ~170 MBytes/second on average with peaks of ~3GBytes/second (almost one DVD per second), highly available and to thousands of clients at once all around the world from many servers on many continents.

Bittorrent have more overhead than e.g. rsync. The number of connections isn't really problem (at least in our serverhouse, they can handle, they're paid for it and our clients connect only to our mirrors -- about 10 of them) but the possibility of having any mirror shut down and traffic balancing among all our mirrors ... well I cannot see any possibility of this being done with rsync :-) And it also doesn't qualify as abuse :-) Or you can say CDNs abuse the whole internet :-) Anyway Popcorn Time like client would be great for porn sites :-) cheap hosting + bittorrent + popcorn time and almost CDN like streaming. Perfect use case. I do not condone pirating stuff from intenet, but bittorrent is a great technology which is without it normally implemented by a very very expensive hardware.

Your boss should have prevented you from abusing your network in this manner. Use rsync with compression enabled and be done with it.

Here's an article about the huge latency caused by bittorrent traffic on your network.

For example, if someone modified the code to completely break the entropy generation in a widely used cryptography library in a major Linux distribution, with the effect that you only had to search 32768 possibilities in order break "4096 bit" cryptography, the benefit of open source is that it would be spotted immediately. No, wait... One interpretation of that disaster is that people who were completely unqualified to work on crypto code made a stupid mistake. Another is that people who were most certainly qualified to work on crypto code made an excellent move for the security services.

http://www.formortals.com/terry-childs-network-admin-convicted/

No it didn't, there was no policy. What kind of an idiot writes a policy with mayor-only permissions? He pulled this Mayor-only excuse from his a$$.

Read what the juror said. He said Childs had already given the COO access to the system before. He only had a problem giving access after he found out that he was getting reassigned. So he gave a bad username and password to his boss, the COO, and HR despite the fact that police had already been called to the meeting. Then emailed everyone laughing at them that they can't get in the next day. The cops tried to solve this as an employer/employee issue and then Childs withdrew $10K and left for Nevada the day before his arrest.

This guy was a true piece of work. It's a classic case of an IT employee trying to lock out his employers and it gives us all a bad name. This business that it's his management's fault for giving him too much slack is no excuse. I was given a lot of freedom to act and design when I worked in a similar role and I saw that as a privilege that I earned.

And you need to actually realise there's a bug there. If the effect of a bug is for an application to crash, or (if in some ideal world someone's thought to do this) hit an assert, or an OS to panic, it's in a sense easy: you know that in some way the code has hit an explicit (assert, call to panic) or implicit (dereference zero) pre-condition and died. You know where it died, you have some chance of finding what was happening beforehand depending on the sharpness of your preparation, you have it all. Now, consider the recent Ubuntu ``32K states for certificate generation'' http://www.formortals.com/all-2006-2008-debian-ubuntu-crypto-keys-worthless/ problem. That didn't cause any of the above. It might, in some ideal world, have failed a test suite, but how many distinct certificates do you generate before there's `enough'? And to throw extra fat on the fire, if memory serves the bug was introduced by someone attempting to get a clean pass from a static analysis tool (or gcc -Wall --- it's the same principle). But, for two years, that lurked there. As an open-source and security community, it's a real mark of Cain, and we should understand why it happened. Because it says very bad things about process, correctness and testing.

The original article is here: http://www.f-secure.com/weblog/archives/00001675.html George Ou has "debunked" this "fail" here: http://www.formortals.com/Default.aspx?tabid=36&EntryID=180 This is nothing more than FUD IMHO

Just because they perceive there to be extra capacity doesn't mean there is. Whenever you use additional TCP connections, you take bandwidth at the expense of everyone else because TCP (Jacobson's algorithm) rations on a per-flow basis and not a per-user basis.
http://formortals.com/Home/tabid/36/EntryID/170/Default.aspx

That's not what he said at all if you actually read the article. In fact, at the end of it, he thanked the interest groups for bringing this to the FCC's attention and publically shaming Comcast. The result was that Comcast will stop using TCP resets and implement a protocol agnostic network management system by the end of this year and they're working with BitTorrent corporation and the P4P group to improve BitTorrent efficiency as well as a P2P users' bill of rights and responsibilities. So the process of the public and the FCC putting public pressure and humiliation on Comcast did the trick.

See http://www.itif.org/index.php?id=162 and http://www.formortals.com/Home/tabid/36/EntryID/88/Default.aspx

The problem with the FCC majority decision is that they're trying to enforce something that they said was never intended to be enforceable and they never went through any formal rule making process.

Queueing Theory says that around 70% utilization is when delays occur.

Delays occur whenever anything is waiting in an output queue instead of being immediately transmitted. This could happen at very low average utilization levels if multiple sources all try to send data across a link simultaneously. The delay time is a function of the number of bytes waiting to be transmitted and the transmit speed.

Retransmission delays occur when the output queue gets full, the router drops additional packets as they come in, and the TCP connection hangs until the retried packets come through (700ms for the first one, much more for subsequent dropped packets). To avoid compounding the problem, output queues on routers are typically sized to something a fair bit less than 700ms.

See: Why BitTorrent causes so much latency
http://www.formortals.com/Home/tabid/36/EntryID/57/Default.aspx

But if you can deal with 3 out of 4 things, you can make VoIP usable with a low enough ping. I can't say the same if you want a perfect gaming experience though.

Interesting exploration of the issues here: http://www.formortals.com/Home/tabid/36/EntryID/57/Default.aspx

The Conyers bill didn't pass the last time for good reason. See George Ou's excellent analysis explaining why it would be very bad for the Internet, at http://www.formortals.com/Home/tabid/36/EntryID/34/Default.aspx