
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
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. 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
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
Too low allowance, and not all the packets can arrive while they're still timely. _____________________
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
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
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
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
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
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
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. _____________________
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 |