Still have packet loss on my Samsung STB

[Dessimat0r]

I've been waiting for a firmware update to fix the packet loss for ages now, but nothing has happened This netstat -s was done just now.

TCP Statistics for IPv4

Active Opens = 8784
Passive Opens = 913
Failed Connection Attempts = 329
Reset Connections = 718
Current Connections = 21
Segments Received = 797056
Segments Sent = 742500
Segments Retransmitted = 29977

[paulyoung666]

have you run dan elwells bb speed test to see what that shows up

[Dessimat0r]

Here are the results, but I don't see how it helps -- I know that I'm on a 1.5mbit connection, after all

Also, the packet loss occurs still occurs when peer to peer applications are open (i.e. when my download and upload are both saturated -- although upload has to be past 15k/s to get significant loss). I've had a repull and everything, but it still has not yet been fixed.

Dan Elwell's Broadband Speed Test (unregistered)
Speed Test Report 04/11/27 18:33 - Quick test

Test conducted at: 27/11/2004 6:33:33 PM
Test sequence: Quick test

Please note that these results are a snapshot of this particular moment. Run the test a few times to ensure maximum accuracy. Although the test has been constructed to be highly accurate, no guarantees can be made to the level of accuracy experienced in everyday use.

Test 1: Ping times to UK servers

Ideally, you should get a result of around 30 ms (lower is better)

linx.net: 23.3 ms
f2s.com: 17.3 ms
linx.net: 20 ms

The results of this test indicate no problems.

Test 2: Ping times to European servers

Ideally, you should get a result of around 50 ms (lower is better)

tux.cprm.net: 59.5 ms
sunsite.cnlab-switch.ch: 131.7 ms
tux.cprm.net: 60 ms

This result is much poorer than expected and should be investigated.

Test 3: Ping times to east-coast USA servers

Ideally, you should get a result of around 120 ms (lower is better)

dulug.duke.edu: 96.3 ms
club.cc.cmu.edu: 102 ms
dulug.duke.edu: 96.5 ms

The results of this test indicate no problems.

Test 4: Ping times to west-coast USA servers

Ideally, you should get a result of around 160 ms (lower is better)

redhat.netnitco.net: 186 ms
ucla.edu: 168.3 ms
mirror.chpc.utah.edu: 145.8 ms

The results of this test indicate no problems.

Test 5: Download speeds from UK servers

Ideally, you should get a result of around 1024 Kb/s (higher is better)

mirror.ac.uk: 947 Kb/s

The results of this test indicate no problems.

Test 6: Upload speeds to the Speed Test Server

Ideally, you should get a result of around 256 Kb/s (higher is better)

Not conducted: You must register this software in order to perform this test.

Please click 'What's This?' for information on registering this software to enable this test.

Test 7: Packet loss en route to a UK server

Ideally, you should get a result of around 0 % (lower is better)

clara.net: 2 %
linx.co.uk: 0 %

A small amount of packet loss has been detected. This should be investigated.

End of testing.

This report was collated using Dan Elwell's Broadband Speed Test. For more information or to download, please visit www.broadbandspeedtest.net.

Generated 27/11/2004 6:33:33 PM using test version 3.0.316 - unregistered COPY

[paulyoung666]

Originally Posted by Dessimat0r

Here are the results, but I don't see how it helps -- I know that I'm on a 1.5mbit connection, after all

Also, the packet loss occurs still occurs when peer to peer applications are open (i.e. when my download and upload are both saturated -- although upload has to be past 15k/s to get significant loss). I've had a repull and everything, but it still has not yet been fixed.

i asked because i was curious how much packet loss was involved , nobody queried what service you were on , nice to be nice when ppl try and help you

[Dessimat0r]

No no, I'm not trying to be nasty at all. The thing is that the packet loss varies in different operating conditions. (i.e. when upload and download are saturated).

On the netstat thing, I know someone who can keep eMule open all day and only get 100 segments retransmitted. On mine, it has creeped up every time I do it over a number of seconds, and when eMule olr whatever is open (it does it with any P2P application which saturates the connection).

[Tezcatlipoca]

You shouldn't saturate the upstream or downstream, as it will (as you've found) affect your connection.

Have a look at this for a bit of info on P2P problems - http://homepage.ntlworld.com/robin.d...mtips/p2p.html

[Dessimat0r]

It dosen't just affect my connection in terms of latency, it affects it in terms of packet loss, which I shouldn't be getting at all. Show me your netstat -s after a while of eMule being on full saturation. I guarantee that you won't get the same 'segments retransmitted' as me.

See http://homepage.ntlworld.com/robin.d.h.walker/cmtips/loss.html

[threadbare]

it's as simple as Matt D suggests - do not saturate either upstream or downstream.

[Chris W]

limit the upstream, and also lower the number of similtaneous connections- not sure if you can do this with emule.... never used it myself!

[Dessimat0r]

Even if I limit my upload to 15k/s, I still get packet loss -- images sometimes do not load, etc. It is not a solution.

I know someone else who, if they match my operating environment, gets no packet loss whatsoever.

[rdhw]

Originally Posted by Dessimat0r

Even if I limit my upload to 15k/s, I still get packet loss -- images sometimes do not load, etc. It is not a solution.

Ultimately, the only way a bandwidth cap can be enforced is by dropping packets. The CMTS/UBR will at first try to enforce the cap by delaying packets in a buffer (or leaky bucket), and hoping that the flow control properties of TCP will cause the rate of arrival of data to slow down. But if the packets continue to flood in, the leaky bucket will overflow and the overflowed packets will be lost. Maybe (or maybe not) this is what is happening to you.

Much depends on your TCP Receive Window, or RWIN, setting. If you have an over-large RWIN setting, it will eventually be impossible for the CMTS/UBR to delay/hold complete TCP Windows (for each of your incoming TCP sessions) in its leaky bucket, and you will lose incoming data. I suggest you run the Tweak Test at http://www.broadbandreports.com/tweaks which will report your active RWIN setting.

Another potent cause of packet loss could be an ethernet duplex mismatch between your STB and the device connected to it. What are the ethernet speed and uplex settings in force there?

[Dessimat0r]

My RWIN is currently at default, and I've tried all duplex settings. BillC told me to use 10 half duplex until the problem was fixed, but that was 3 months ago

Perhaps the answer (in the short term) is to use a ridiculously small RWIN value so any packets which are not recieved can be resent quickly.

I've also changed the network adapter from the one on my motherboard (VIA Rhine) to a PCI one (Realtek), but hasn't affected much.

[BigChin]

If at all possible try and do yourself a favour and get a SACM. The Samsung is jack, I had similar problems and couldn't put up with it. The reliability of my connection is now superb (I've got the 200 SACM version), I can't believe I put up with the STB for so long (Pace didn't have the same problems as the Samsung but it did crash fairly frequently).

[Robc66]

I tried to get an SACM out of them but they wouldnt give me one....
They just kept redirectin me to another department. Would it be possible to buy my own sacm off like ebay and put it in myself? Or wud i have to tell ntl i was doing that?

[Stuart]

Originally Posted by Robc66

I tried to get an SACM out of them but they wouldnt give me one....
They just kept redirectin me to another department. Would it be possible to buy my own sacm off like ebay and put it in myself? Or wud i have to tell ntl i was doing that?

Nope, the only modems NTL allows on it's network are those it supplies.