![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
so far, so good
i've let the paramour go for a walk by zirself, even though the weather was nice, and i could have used the walk, and would have undoubtedly enjoyed it. but i've been playing all day with tcp/ip traffic control, my firewall, and bittorrent.
i can see why so many people bitch about bittorrent, and never get theirs working well. it's rather complicated, with several factors all affecting not only whether, but also how well bittorrent will work. i am glad i am a geek with some inkling of networking.
i wonder if i could actually write a handholding document for complete non-geeks. *urk*. not going to give in to that temptation just now; but i want to write down what i had to do and why.
i used one of the many sites on the net that analyze bandwidth (uses java) to see what sort of numbers i had to start with. yesterday it was 1067/452 kbps, today 1258/510 kbps -- today's is acceptable (ideal for our plan would be 1536/512 -- i wonder how often we actually do that. i'll run these tests every day for a week.). every website i saw said to start by setting your upload speed at 80% of the available bandwidth; today that would be 408 kbps (of course my client wants this in kBs, to make me convert every time: 51 kBs). download speed i left at unlimited to see just how high i could get it. maximum would be 157 kBs, with nobody else using the connection, and me not doing anything but downloading torrents. not gonna happen. :)
i opened a high port for the bittorrent traffic, both tcp and udp (the tracking database needs the udp port), because as i experienced yesterday, the combination of some ISPs blocking standard p2p ports has led to lots of seeders no longer accepting those ports either because they bring the swarm speed down. *bleh*. wish i had known that right away; that accounted for my miserable speeds the first day, and why azureus continued to claim i have a NAT problem. after switching ports i actually got some "green" connections, though still not many. and today i am back to not having any green ones.
i had to play with the upload speed to find the sweet spot at which it didn't screw itself, which turned out to be 70% yesterday; this might need more tweaking, but today's download speed was good, so i left it. i also no longer see the situation where i'd get an initial burst of high download speed from a new peer, only to find it drop quickly -- because bittorrent uses a "tit for tat" system, that happens when the peer doesn't recognise your uploads. i no longer get those precipitous drops. still, no "green".
so now i am wondering whether telus secretly does traffic shaping, such as it appears shaw is doing (which uses sophisticated packet analysis to determine that you are, indeed, running bittorrent traffic on a non-standard port, and throttle it). fucktards. it's none of their damn business WHAT i do with the upload bandwidth i am paying for! lots of bittorrent traffic is perfectly legitimate. i couldn't find anything about telus doing this, but it's possible. i had lousy download rates all night until i made two changes. my logs were filling with dropped udp packets, so i increased the rate limit to 10/sec 10 bursts. and i modified my azureus startup file to turn on something called "lazy bitfield".
because i found this: when torrents switch from leeching to seeding, the client sends a specific bitfield information. some ISPs detect this info, and send spoofed packets to both peers causing the clients to terminate the connection. when "lazy bitfield" is turned on, the client disguises that field. alas this isn't yet something one can do in the options, it has to be a command line parameter:
start javaw -Dazureus.lazy.bitfield=1 -classpath Azureus2.jar;swt.jar;systray4j.jar org.gudy.azureus2.ui.swt.Main
my download speeds went from a max of 30 kBs with the occasional torrent to 108 kBs today, sustaining rates consistently much higher than yesterday. probably either of those two changes are responsible; tomorrow i'll try a more controlled experiment. there is no "green" however. *sigh*. one more option is to use a different client; bitcomet allows for protocol header encryption, which might fool traffic shaping software. oh -- i just remembered that i auto-upgraded azureus to 2.3.0.7, and the greens went away right after that. hm. could be it's a problem with the upgrade. not rolling back for now though, since my speeds are so good.
i love our cats. i always have company in my room; at least one of them tries to lay down on my wacom pad (but will settle on the other side, snuggled against my left arm if prodded), and bacchus usually curls up under the workbench.
i can see why so many people bitch about bittorrent, and never get theirs working well. it's rather complicated, with several factors all affecting not only whether, but also how well bittorrent will work. i am glad i am a geek with some inkling of networking.
i wonder if i could actually write a handholding document for complete non-geeks. *urk*. not going to give in to that temptation just now; but i want to write down what i had to do and why.
i used one of the many sites on the net that analyze bandwidth (uses java) to see what sort of numbers i had to start with. yesterday it was 1067/452 kbps, today 1258/510 kbps -- today's is acceptable (ideal for our plan would be 1536/512 -- i wonder how often we actually do that. i'll run these tests every day for a week.). every website i saw said to start by setting your upload speed at 80% of the available bandwidth; today that would be 408 kbps (of course my client wants this in kBs, to make me convert every time: 51 kBs). download speed i left at unlimited to see just how high i could get it. maximum would be 157 kBs, with nobody else using the connection, and me not doing anything but downloading torrents. not gonna happen. :)
i opened a high port for the bittorrent traffic, both tcp and udp (the tracking database needs the udp port), because as i experienced yesterday, the combination of some ISPs blocking standard p2p ports has led to lots of seeders no longer accepting those ports either because they bring the swarm speed down. *bleh*. wish i had known that right away; that accounted for my miserable speeds the first day, and why azureus continued to claim i have a NAT problem. after switching ports i actually got some "green" connections, though still not many. and today i am back to not having any green ones.
i had to play with the upload speed to find the sweet spot at which it didn't screw itself, which turned out to be 70% yesterday; this might need more tweaking, but today's download speed was good, so i left it. i also no longer see the situation where i'd get an initial burst of high download speed from a new peer, only to find it drop quickly -- because bittorrent uses a "tit for tat" system, that happens when the peer doesn't recognise your uploads. i no longer get those precipitous drops. still, no "green".
so now i am wondering whether telus secretly does traffic shaping, such as it appears shaw is doing (which uses sophisticated packet analysis to determine that you are, indeed, running bittorrent traffic on a non-standard port, and throttle it). fucktards. it's none of their damn business WHAT i do with the upload bandwidth i am paying for! lots of bittorrent traffic is perfectly legitimate. i couldn't find anything about telus doing this, but it's possible. i had lousy download rates all night until i made two changes. my logs were filling with dropped udp packets, so i increased the rate limit to 10/sec 10 bursts. and i modified my azureus startup file to turn on something called "lazy bitfield".
because i found this: when torrents switch from leeching to seeding, the client sends a specific bitfield information. some ISPs detect this info, and send spoofed packets to both peers causing the clients to terminate the connection. when "lazy bitfield" is turned on, the client disguises that field. alas this isn't yet something one can do in the options, it has to be a command line parameter:
start javaw -Dazureus.lazy.bitfield=1 -classpath Azureus2.jar;swt.jar;systray4j.jar org.gudy.azureus2.ui.swt.Main
my download speeds went from a max of 30 kBs with the occasional torrent to 108 kBs today, sustaining rates consistently much higher than yesterday. probably either of those two changes are responsible; tomorrow i'll try a more controlled experiment. there is no "green" however. *sigh*. one more option is to use a different client; bitcomet allows for protocol header encryption, which might fool traffic shaping software. oh -- i just remembered that i auto-upgraded azureus to 2.3.0.7, and the greens went away right after that. hm. could be it's a problem with the upgrade. not rolling back for now though, since my speeds are so good.
i love our cats. i always have company in my room; at least one of them tries to lay down on my wacom pad (but will settle on the other side, snuggled against my left arm if prodded), and bacchus usually curls up under the workbench.