138.6% packet loss

Does this mean I'm losing packets that I haven't even sent yet? Lol.

yes

I think it means that they FOUND the lost packets involved and then lost them again....

I think that it means that they're creating anti-packets. This is dangerous, since anti-packets meeting normal packets will result in in both the normal packets and the anti-packets anihilating each other and releasing dangerous particles such as the "lagon", and the no "norezatron".

I'm considering creating a proposal asking LL to make it a priority to fix the bugs which allow SL to produce these dangerous anti-packets. If I do I hope you'll join me in voting for it.

if you aren't recieving any packets (100% loss) and the server isn't recieving any of yours (100% loss) then you encounter a Math Error and have 200% packet loss (100% + 100% = 200%, right?).

138% would be ~70% loss in both directions.

Draco18s:

Cute. I disabled my network connector while logged in, to test that scenario. My bandwidth went to 0 kbps, my ping sim went to 100000 msec. My packet loss indicator stayed at 0.0%. I suppose that packet loss calculations are disabled when SL detects loss of connection. This would make it unlikely that we would ever see 200% packet loss. Maybe 199%. At 200%, the client would assume loss of connection.

Interestingly, I can still click on objects and go into EDIT mode on the objects. I can still show EDIT information on the objects, such as position, size, etc. I can still move objects around. I assume all this is local, from cache. I assume when I log back in, I'll find my changes to objects have been disregarded.

I expected the client to log me off when it detected loss of connection. That didn't happen. To me, it would be reasonable to have the client pop up a LOSS OF CONNECTION dialog or show a connection icon turning red or SOMETHING. It seems like very poor design to allow the user to THINK he is still connected when the connection has been lost. Lindens?

EDIT: I was able to log in at my LAST LOCATION. So, it appears that the last location is saved on the client, not the server. As I expected, my editing changes had not been registered.

Pure guess here:

The "reliable" asset transfer protocol does bandwidth throttling when it begins seeing loss (the SecondLife.log file shows when and how much it clamps). If the reported loss is calculated using some combination of the desired bandwidth (set in Preferences->Network) and the current throttled rate, you could get improper ratios.

Or it could be a sign of the apocolypse...

I was under the impression that SL client / server comm was all UDP (unreliable.) The sims talk amongst themselves using TCP (or TCP over UDP depending on who you ask.)

If someone said TCP over UDP to me, I'd immediately stop asking that person ANYTHING regarding network traffic.

Reminds me of the guy who INSISTED ARP packets were routed over the Internet, in a public forum, in front of 100+ people getting a briefing on a firewall technology.... (eyeroll).

Yeah. I've had the TCP over UDP argument. I argued against it being possible or even desirable. I feel your pain. But, check this thread:

/139/99/96971/1.html

SL uses "reliable UDP" (an implementation of TCP over UDP.) Go figure.

Calling it TCP is an insult to Jon Postel. The "reliable" transport just uses packet sequence numbers and sends NACKs when it sees too many packets after one is dropped from the sequence. The funny thing is that this transport is used for asynchronous services (e.g. texture delivery) where cost savings of a really good, specialized transport would be minimal. More interesting is that the assets are coming out of the asset server over an HTTP (TCP) connection and then being broken up by the sim into fragments before being inefficiently shipped to you.

Adding sequence numbers to UDP does not TCP make. There are no sliding windows, there is no source quench, there are no piggyback ACKs. There seems to be no reason at all to not open a real transport session at login and use 30 years of protocol development and practical deployment for these assets. Hell, Quicktime is loaded and initialized on every login even if you have the streaming video preference turned off. I suppose replacing the asset transport is "not fun".

I tend to agree. As I say, I've had this argument. I asked in ANSWERS and you can read the answer I received from Linden Lab. Additionally, here's a snip of a conversation where Argent Stonecutter and I thrashed it out:


paulie femto: To me, adding TCP-like functionality at the application layer does not constitute TCP over UDP.

Argent: It's functionally indistinguishable from implementing a poor quality TCP implementation. It's not as *good* as really tunneling IP and TCP would be (consider the problems caused by the lack of congestion control that led to my comment in the first place, but it's every bit as hard.

paulie femto: TCP is a transport layer protocol. Faking TCP at the application layer does not constitute TCP OVER UDP.

Argent: Implementing a transort protocol in an application is no different from tunneling, as far as the protocol model goes. You're going back to the transport layer. It's like KA9Q SLIP. KA9Q was a full TCP/IP implementation that runs 100% inside an application program. All the higher layers were modules inside KA9Q, you couldn't route packets back outside the program. Saying that it's not TCP/IP because it's implemented at the application layer in the outer stack is meaningless. What LL is doing is implementing the transport layer in the application, running a very simple low-quality network stack inside SL.

paulie femto: According to the LL response I got in ANSWERS, LL calls what they're doing "reliable UDP," not TCP OVER UDP. I tend to agree.

Argent: It's a reimplementation of the fundamental functionality that distinguishes TCP from UDP. The fact that it's incompatible with DoD TCP just makes it worse.