Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Where is the packet loss?

Selador Cellardoor
Registered User
Join date: 16 Nov 2003
Posts: 3,082
06-16-2009 02:58
:)
Baloo Uriza
Debian Linux Helper
Join date: 19 Apr 2008
Posts: 895
06-16-2009 13:46
From: Selador Cellardoor
Is it? Then why do two programs designed to measure packet loss report that there isn't any? Certainly something is wrong, because sl is performing very badly.


Quantity. Windows ping sends out one packet every second containing a time stamp, SL sends out larger packets more often. If you want to reproduce these conditions with ping, use ping -f with superuser privs on a linux or macos box (the -f option does not exist in Windows ping), and consider increasing the ping packet size substantially.

From: someone
As I have said, reducing the slider to the extreme left-hand position slightly reduces the packet loss that sl reports, but doesn't get rid of it.


Right, extremes will always do that. Too low allowance, and not all the packets can arrive while they're still timely. Too high an allowance, and the grid sends too many packets, creating the same bottleneck between you and your ISP. There's a reason why the default is in the center of the big, happy medium.
Baloo Uriza
Debian Linux Helper
Join date: 19 Apr 2008
Posts: 895
06-16-2009 13:47
From: Selador Cellardoor
OK, I went into sl today to make that alteration to the bandwidth, and to my delight, discovered that for the first time in nearly a week, packet loss is back to zero, and sl is running ok again.

I can only put it down to an sl glitch, but I am really relieved that things appear to be ok. Many thanks to everybody for their help, and I hope that is an end of it.


I wouldn't mark this down as an SL glitch. SL can't affect your connection's ability to reliably transfer data.
Argent Stonecutter
Emergency Mustelid
Join date: 20 Sep 2005
Posts: 20,263
06-16-2009 13:51
From: Baloo Uriza
Too low allowance, and not all the packets can arrive while they're still timely.
I was just looking at the code that measures packet loss, and the timer starts when another packet is received, not when the event that required the packet occurs. So setting the bandwidth low will slow updates, but it won't generate spurious packet loss indications.
_____________________
Argent Stonecutter - http://globalcausalityviolation.blogspot.com/

"And now I'm going to show you something really cool."

Skyhook Station - http://xrl.us/skyhook23
Coonspiracy Store - http://xrl.us/coonstore
Baloo Uriza
Debian Linux Helper
Join date: 19 Apr 2008
Posts: 895
06-16-2009 13:55
From: Meade Paravane
Or because the sim is borked. This is packet loss as seen by the sim - all the packets could be making it over the wire just fine...


The packet loss and latency (ping) displayed in the SL client are as detected by the SL client. The only stats you get from the sim are the ones under sim stats, not connection.
Baloo Uriza
Debian Linux Helper
Join date: 19 Apr 2008
Posts: 895
06-16-2009 13:58
From: Selador Cellardoor
It could well be a router problem, because I recently changed routers. I really don't see what it can be, though, because the limited options for setup seem to be correct.


Toy routers (typically advertised to home users in the <$200 price range) don't typically have the CPU power or RAM necessary to handle a crushing load. Different makes and models respond differently, I've usually had consistantly crap luck with d-link routers, hit or miss with netgears, and more or less reliably with a lot of work and reflashing to dd-wrt with linksys.

If you need a router that won't crush under the load and you're a hardware guy, consider getting a mini-ATX system together as a router instead, otherwise it might be time to price out something a little more substantial to route your network than some radio shack toy.
Meade Paravane
Hedgehog
Join date: 21 Nov 2006
Posts: 4,845
06-16-2009 14:04
From: Baloo Uriza
The packet loss and latency (ping) displayed in the SL client are as detected by the SL client. The only stats you get from the sim are the ones under sim stats, not connection.

Oops..

But, either way, this is a high-level software stat - not something coming from the network stack. The point was that seeing packet loss reported by SL isn't necessarily an indication of a network problem.
_____________________
Tired of shouting clubs and lucky chairs? Vote for llParcelSay!!!
- Go here: http://jira.secondlife.com/browse/SVC-1224
- If you see "if you were logged in.." on the left, click it and log in
- Click the "Vote for it" link on the left
Baloo Uriza
Debian Linux Helper
Join date: 19 Apr 2008
Posts: 895
06-16-2009 14:06
From: Selador Cellardoor
Ok, the problem appears to be solved - unless it's a false dawn like the last time!

I had a look in my router, and based on what you said earlier, I noticed that there was a default setting of SPI Firewall Protection. I unchecked that, and so far everything seems well, with a zero packet loss in Umber. I have no idea what SPI Firewall Protection is, but it certainly seems that I am better off without it!


Like Argent said, Stateful Packet Filtering. It's nice to have, but it requires a lot of memory and CPU power, something toy routers don't typically have (though this isn't typically a problem for the audience soho routers are geared towards; we as SL users just aren't part of it. They're generally marketing these home routers to casual users who might play Quake or TF2 for an hour or so a month, with maybe two or three people browsing the web the rest of the time, not the constant packet onslaught geeks and SL users tend to sling).
Baloo Uriza
Debian Linux Helper
Join date: 19 Apr 2008
Posts: 895
06-16-2009 14:09
From: Argent Stonecutter
I was just looking at the code that measures packet loss, and the timer starts when another packet is received, not when the event that required the packet occurs. So setting the bandwidth low will slow updates, but it won't generate spurious packet loss indications.


Is it possible this is a relatively recent development? I recall around summer of '06 to winter of '07, it worked more like how I described, I just hadn't had a reason to try cranking it to the low end since. Though this could have been a local factor, since I /was/ succeeding to connect to SL through 250 feet of office building to a public MetroFi node limited to 56kbps...
Argent Stonecutter
Emergency Mustelid
Join date: 20 Sep 2005
Posts: 20,263
06-16-2009 14:26
From: Meade Paravane
But, either way, this is a high-level software stat - not something coming from the network stack. The point was that seeing packet loss reported by SL isn't necessarily an indication of a network problem.
It's UDP. UDP is at the same level in the network stack as ICMP (ping), and it's the same *protocol* used by udping, traceroute, and dig. Packetloss seen by the SL client is exactly as indicative of a network problem as packetloss seen by any other program that's reporting network statistics on a packet-by-packet basis.
_____________________
Argent Stonecutter - http://globalcausalityviolation.blogspot.com/

"And now I'm going to show you something really cool."

Skyhook Station - http://xrl.us/skyhook23
Coonspiracy Store - http://xrl.us/coonstore
1 2