Less packet loss when torrenting... Wut?

dillinger88 · 07-12-2010, 22:06

Hi all,

I recently took the plunge to upgrade to 50Meg as my packet loss on 20Mb was around 30-40%. Unfortunately, upgrading hasn't given me the improvement I was looking for. I'm still getting horrible packet loss and upload speeds (getting a nice juicy 50Mb downstream though, the upstream bandwidth on my UBR is clearly too crowded, but that's another story.)

Regardless of this, can someone explain to how the phenomenon shown in the graph below can occur?

The period where the packet loss was below 5% was when I was torrenting something, so I decided to close uTorrent to check my connection and my packet loss shot back up.

How can this happen? I'd expect to get more packet loss if I was using more of my upstream bandwidth. Can anyone shed some light?

[img]Download Failed (1)[/img]

Cheers,

Dan

pip08456 · 07-12-2010, 23:26

Quote:

Originally Posted by dillinger88

Hi all,

I recently took the plunge to upgrade to 50Meg as my packet loss on 20Mb was around 30-40%. Unfortunately, upgrading hasn't given me the improvement I was looking for. I'm still getting horrible packet loss and upload speeds (getting a nice juicy 50Mb downstream though, the upstream bandwidth on my UBR is clearly too crowded, but that's another story.)

Regardless of this, can someone explain to how the phenomenon shown in the graph below can occur?

The period where the packet loss was below 5% was when I was torrenting something, so I decided to close uTorrent to check my connection and my packet loss shot back up.

How can this happen? I'd expect to get more packet loss if I was using more of my upstream bandwidth. Can anyone shed some light?

Cheers,

Dan

Dead easy. That may not be your connection as the thinkbroadband ping meter cannot handle dynamic IP addresses which VM use (along with other ISP's)

I can show you one of mine which is totally red-100% packet loss but as my IP addy had changed it is not my cnnection most likely still in the pool to be allocated hence no traffic, no ping reply.

Not mine any more!

Neither's this one.

I've stopped using it because of this. The 2 graphs above are nothing to do with my connection whatsoever but I can still access them with my user/pass as if they were.

qasdfdsaq · 08-12-2010, 00:02

While vaguely possible, that meter's only been active eight hours and with no signs of a modem reboot in that time, I highly doubt his IP will have changed.

pip08456 · 08-12-2010, 00:43

And the graph shows a sign of a modem reboot and a different IP addy assigned HOW?

Does the graph refer to his present IP addy or the one assigned when he registered?

So many questions and no answers and I wouldn't try to either.

Would you like to explain my 2 graphs on the same basis?

qasdfdsaq · 08-12-2010, 01:32

It doesn't, which is my point.

Each graph is exclusive to one IP, to monitor a new/different IP you'd have to set up a new graph. The graph posted refers to the IP address given when the graph was created at ~5pm yesterday. You cannot change the IP of a monitor once it's set up, and that IP has not been given to someone else in that time.

If he were to change IP there would be at least one point on the graph that shows 50%+ packet loss, more likely 100% for however much time until the IP is assigned to someone else (minutes to hours). Assuming the other person turns their modem on the exact same second he turns his off, it'd still take at least 30 seconds for the IP change to occur and therefore at least one minute with 50%+ packet loss, which would clearly show up on the graph.

Your graphs are irrelevant as the IP changes occurred well before the time scale shown on the graph. If the IP monitored by the graph were to change ownership (i.e. from you to someone else) it would be clearly visible on that section of the graph. The monitor is sensitive enough to detect any connectivity changes (such as a 30-60 second modem reboot) that would be required for a change of IP to have occurred during the monitored window.

So
1) The monitor was set up less than a day ago
2) The IP hasn't changed ownership in that time
Therefore unless it is deliberately set up with someone else's IP address that's his connection it's monitoring.

Chrysalis · 08-12-2010, 07:16

pip VM ip's arent normal dynamic tho they are more sticky. They tend to only change in one of the following 2 scenarios.

1 - result of work done by VM which forces user onto different dhcp pool. Me personally this is extrememly rare. Granted it could be more frequent for others.
2 - If changing the equipment connected to modem.

I have had my current ip since mid summer.

my guess is the high loss is caused by errors, and torrenting for some reason is reducing those errors.

dillinger88 · 08-12-2010, 09:52

Hi all,

Thanks for your responses.

My modem hasn't been reset since I started the ping the test and I have double checked that I'm still on the same IP.

For the last few months I have had 20-30% packet loss every night without fail and I'm certain it's down to a UBR fault, though this could mean that it may not be true so I thought I should double check there is nothing else I can do on my computer before I continue my rage at VM.

Any geniuses have a clue why my modem would respond to more ping requests when my utilisation is higher?

I'll try it again tonight to see if it wasn't a coincidence, it just doesn't seem like it is because as I said I have been getting a steady 20-30% packet every night.

Cheers,

Dan

dragon · 08-12-2010, 10:01

Are the upstream power levels out perhaps?

I think there's a sticky at the top of the forum which suggests what they should be.

dillinger88 · 08-12-2010, 10:41

Hi dragon,

I am aware that incorrect power levels can screw a connection and I do check them regularly. I probably should have pointed this out, though.

My downstream power hovers around the 1-2dBmv and my upstream around 48dBmv which are apparently well within the acceptable range so I don't believe this is the case. Hence also why it leads me to believe that it is an upstream utilisation fault on my UBR.

Cheers,

Dan

Chrysalis · 08-12-2010, 12:47

ok 2 more theories.

1 - your torrenting gives you more time slots on a congested ubr and the pings end up using those slots.
2 - your torrenting makes the responses slower to the monitor and less get done as a result giving lower packet loss.

qasdfdsaq · 08-12-2010, 20:56

Yeah, something like that - something to do with DOCSIS scheduling anyway. Probably the same reason my average ping drops in half when I'm downloading heavily (i.e. 8:15-9:45 period). Stop for a few minutes and it shoots back up to double.:

Chrysalis · 09-12-2010, 06:38

graph doesnt look good? you got downstream and upstream congestion by look of it