I read on another TBB forum that some Thomson routers have problems with some LLU profiles. Wonder if the Billion has a problem with the Default LLU Vivaciti profile and the Speedtouch doesn't?

In reply to a post by Banger:

Been playing with Wireshark and tbh it's a bit above my head. But I am seeing TCP DUP Acks and reassembled segments around the time my large downloads pause. Is the download losing packets and restarting after losing a packet or two?

DUPs are normal in some ways and do indicate packet loss.

I am trying to discern if it's my router or ISP. Pauses are fairly random and Billion cant reproduce the problem. Also if I use a Speedtouch 546 router it doesn't seem to happen or if I use multiple streams on the download eg 4 streams. One would have thought if the router was losing packets/segments it would happen on all download streams. Help!

TCP backs of in response to loss thinking it's a sign of congestion. If you are getting random loss then having more than one stream will help get more throughput as each one will get less loss.

Still seems like a strange problem - are you wired or wireless?

How long are the pauses, as observed from the timestamps on the dump and at app level.

Seeing the dump or parts of it may shed more light .

In reply to a post by legume:

In reply to a post by Banger:

Been playing with Wireshark and tbh it's a bit above my head. But I am seeing TCP DUP Acks and reassembled segments around the time my large downloads pause. Is the download losing packets and restarting after losing a packet or two?

DUPs are normal in some ways and do indicate packet loss.

I am trying to discern if it's my router or ISP. Pauses are fairly random and Billion cant reproduce the problem. Also if I use a Speedtouch 546 router it doesn't seem to happen or if I use multiple streams on the download eg 4 streams. One would have thought if the router was losing packets/segments it would happen on all download streams. Help!

TCP backs of in response to loss thinking it's a sign of congestion. If you are getting random loss then having more than one stream will help get more throughput as each one will get less loss.

Still seems like a strange problem - are you wired or wireless?

How long are the pauses, as observed from the timestamps on the dump and at app level.

Seeing the dump or parts of it may shed more light .

Dump can be found at www.leonard.vivaciti.net/test warning 100 mb file. And I'm wired its a wired only router.

Edited by Banger (Fri 10-Feb-12 19:46:31)

Further testing shows that when I have two downloads running simultaneously the throughput on DU Meter can be seen to half itself as if one stream is pausing for a second and average speed of one download drop by 0.2 mb/s. So legume's theory about multiple streams having less of an effect on overall speed seems correct.

Question is why?

Looking at a capture of the same file but downloaded by the 546 it also has a lot of DUP acks then the dreaded "previous segment lost" but seems able to cope without stopping the stream. Are we getting somewhere?

Here is the 546 capture, http://depositfiles.com/files/gf2wtn8nm - Sorry about the hosting.

Well, I'll throw another idea out here and see if there are any takers: Implementation of NAT / Stateful / Stateless TCP tracking.

Could there be a fundamental difference between how the SpeedTouch tracks connections compared to the Billion? Could it be that one implementation can cope with these missed segments better than the other? (pure speculation this).

Here's something you still may not have tried. Can you put the Billion into pure bridge mode, and then have your Windows XP box directly connect to the internet (so it ends up with a real IP address). This removes NAT from the equation. You could then repeat the download tests and see if things are different. If they are, it could be NAT (maybe) - or, as I said via PM, possibly a difference in the way the Billion shapes or policies traffic that exceeds your line rate (shaping != policing - policing is harsh, and drops packets - shaping is far nicer and tries to first delay packets rather than just dropping them).

In reply to a post by mixt:

Could there be a fundamental difference between how the SpeedTouch tracks connections compared to the Billion? Could it be that one implementation can cope with these missed segments better than the other? (pure speculation this).

I don't suppose there could be a setting or two on one of the routers amiss? Such as MTU/RWIN or similar?

You mean Cone NAT?

Ok I have tried Bridge mode and One to One NAT and results are the same. I have a feeling the problem is in the Billion modem as I can connect the speedtouch to the EWAN port just as a modem and not a router and the problem goes away when the speedtouch becomes a modem and the Billion does the routing.

So to me that rules out the LAN side and possibly routing side and points to the way the modem is handling lost segments in the Billion.

I was trying to get Billion to look at the modem firmware but they seem to have got bored now LOL.

I think your on to something mixt it seems the the Billion is a lot less tolerant of missing segments and says right hold up I'm missing a segment I need to stop until it arrives.

Point is, is this missing segment lark normal or peculiar to my line. If my line is dropping segments is this an ISP problem or overly officious billion router.

In reply to a post by camieabz:

In reply to a post by mixt:

Could there be a fundamental difference between how the SpeedTouch tracks connections compared to the Billion? Could it be that one implementation can cope with these missed segments better than the other? (pure speculation this).

I don't suppose there could be a setting or two on one of the routers amiss? Such as MTU/RWIN or similar?

That's interesting as the default MTU for the connection is 1492 when setting up which I correct manually to 1500 to match my PCs. Also in the router log when left at 1492 the default I get Error cannot set interface MTU at 1500 using default. With the 1500 settings there is no packet fragmentation on ping testing. Rwin is currently set at 513920 and is a multiple of MSS. Have tried lower Rwin values but that starts slowing line speed and pauses are still visible.

Been playing with MTU on the router and tried several values such as 1400, 1000 and 1200 as I vaguely remember AOL problems with some routers but alas no difference.

Could someone download one of the TBB 100mb files and capture it with Wireshark, and host it somewhere so I can compare it to my line?