Network Question.

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?

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!

Try pingplotter free and see if there's an increased ratio of dropped packets when the pauses occur.

Thought you may have had it there. Downloaded 500mb from TBB site, single stream, loads of pauses. Ran PP Free at same time and no PL anywhere on the route including my router to TBB. Ping went up to about 100ms while downloading then reduced to about 40ms during pauses. Any other ideas?

Duplicate ACKs are normally an indication of out-of-order TCP packets. Incorrect traffic shaping or weird buffering somewhere could cause that.

When you get the download pauses, does this happen on all sites you test on or only on a specific site?

All sites are effected, but if I use a download manager with 4 streams like DownThemAll no pauses.

Well it's not dropped packets then. Use the 546 seems to be the best plan.

This is a truly an illusive problem!

Ok, another question. When you are downloading, are you maxing out your line speed? (if so, how fast?).

Can you rate-limit the download? (possibly better to download from a site that rate limits their side) to see if you still get pauses during a download running at a slower speed?

It sounds like a buffering problem, or like the Billion is tripping over itself (or something). Still not really sure to be honest.

Try lowering your RWIN or increasing interleaving

In reply to a post by camieabz:

Well it's not dropped packets then. Use the 546 seems to be the best plan.

546 gets way too many CRC errors and reboots every 2-3 days but otherwise ok. Fairly limited on firmware choice too.

In reply to a post by mixt:

This is a truly an illusive problem!

Ok, another question. When you are downloading, are you maxing out your line speed? (if so, how fast?).

Can you rate-limit the download? (possibly better to download from a site that rate limits their side) to see if you still get pauses during a download running at a slower speed?

It sounds like a buffering problem, or like the Billion is tripping over itself (or something). Still not really sure to be honest.

Yes maxing line out at 17.76 mbps on a 19.88 mbps sync. Workaround is to use multiple streams. Router has QoS so could rate limit that way or software in firefox. Probably simplest way is to find a rate limited server possibly in US. Will report back on tests.

In reply to a post by BatBoy:

Try lowering your RWIN or increasing interleaving

Have played with lots of values of Rwin and even tried on Win 7 - no different. Is it possible to increase interleaving from user side?

Even if you set rwin approaching the value for MTU?

I think interleaving depth or even INP is an ISP function, so good luck with the reseller...

Are you on fastpath though?

In reply to a post by BatBoy:

Even if you set rwin approaching the value for MTU?

I think interleaving depth or even INP is an ISP function, so good luck with the reseller...

Are you on fastpath though?

I use TCP Optimzer to set Rwin and have tried several values both slow and fast line speed all a function of 1500 MTU. Billion suggested turning off Jumbo Frames but this made no difference.

Interleaving is on but not sure what depth need to look deeper.

I was thinking you are getting packet loss due to noise and a quick test is to set the rwin to a low multiple of mtu, like 1 or 2 times, just to see if it eliminates the pauses.

But the router is suspect as replacing it fixes the problem...

In reply to a post by mixt:

This is a truly an illusive problem!

Ok, another question. When you are downloading, are you maxing out your line speed? (if so, how fast?).

Can you rate-limit the download? (possibly better to download from a site that rate limits their side) to see if you still get pauses during a download running at a slower speed?

It sounds like a buffering problem, or like the Billion is tripping over itself (or something). Still not really sure to be honest.

Have found a 2 mbps limited download from the states and a 45mb file pause 3 times. That help?

In reply to a post by BatBoy:

I was thinking you are getting packet loss due to noise and a quick test is to set the rwin to a low multiple of mtu, like 1 or 2 times, just to see if it eliminates the pauses.

But the router is suspect as replacing it fixes the problem...

I will try that with Rwin. But Billion Lab cant recreate this and have sent screen shots of their efforts and other users on this forum have confirmed it doesn't happen to them.

It rules out the Billion being overloaded anyway.

Another question. How many platforms do you have available to you? You're doing the download on Windows, right? Can you test the same download on Linux / Mac ? Maybe even a mobile phone? See if pauses still happen on those?

In reply to a post by mixt:

It rules out the Billion being overloaded anyway.

Another question. How many platforms do you have available to you? You're doing the download on Windows, right? Can you test the same download on Linux / Mac ? Maybe even a mobile phone? See if pauses still happen on those?

Unfortunately only have Windows (XP) platforms available and Win 7 as a virtual machine. Can try some other virtual machines but they are all Windows. No Mac or Linux to test.

Tried some low Rwin values, 3000 and 12000 on my system. 3000 no pauses after 10 minutes but didnt download all 360 mb at 500 kbps. Then tried 12000 to give a speed of around 2.63 mbps and got a pause after about 5 mins. So it seems that the lower the Rwin value the less ofted the pauses at slower speeds. What this proves I have no idea.

This is a replacement router as well, right? (as in, you got the first Billion router, returned it, and got another one, and this one is still doing it?).

I'm out of ideas but I can only guess there is some conflict between the way the TCP stack on your system and the router's NAT is interacting, because as you say, this problem doesn't show if you go back to your SpeedTouch.

On what system are you doing the downloads on? The host system? Or on a guest system? What OS are the host and guest running? (since you mention you are running some virtual machines). If on the guest system, what OS and what virtualisation software are you using? How are you placing the guest onto your network? (is it via NAT, so we effectively have a double NAT scenario happening on guests) or are you bridging the guest interfaces to the host?

I'm actually up for helping further (if you have the time) - for example, I can setup a large file on my VPS server and let you download it, and run a packet capture server side just to see if there's anything more sinister happening. I don't think much more can be done unless this is done (or you want to send me some of your WIreshark pcap files). Happy to take a look though as it certainly is an intriguing issue. PM if you're interested.

Yes this is the second billion router. Host system is XP have various guest systems which include Win 7. Will PM you with more detail and a wireshark file.

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?

In reply to a post by Banger:

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.

I also see the same behaviour on my connection downloading large test files. I see a slight slow down during the dup-acks, and then a recovery. We are also seeing the same thing on both your routers (right? according to pcap files, but the symptoms are more noticeable on the Billion). So I say this is normal TCP behaviour. What might not be so normal is how the Billion is dealing with (or not dealing with) this TCP behaviour.

The network chap at work says that TCP has a mechanism which aims to double its transfer speed during the initial stages of the connection (and during it too). In other words, TCP is always trying to grab as much speed as possible during the transfer. The mechanism(s) it uses are based both on measuring packet delay between peers, the window size (sliding window position and all that malarkey), and also, dropped packets (missed segments). So, what is happening is the remote server you are downloading from is trying to push the speed up beyond your line rate, at which point, your side detects a missed segment (the modem either dropped this packet, or it never reached you from the ISP), and then coughs and splutters until things are re-negotiated and sorted out (until the next time this same event occurs). It seems the Billion is worse at dealing with this issue than the SpeedTouch - now the question is, why?

It could be that inside the Billion, their routing module (or what ever you want to call it) has a harsh policing policy that just drops packets if things get too fast, where as, possibly in the SpeedTouch, its routing module is a bit more intelligent and prefers to shape packets first (delaying them where possible) before harshly dropping them (policing). That's my guess. And it is purely a guess.

Good that we seem to have narrowed down the mystery a bit though.

Edited by deleted (Sat 11-Feb-12 12:38:31)

I see well that makes sense but brings us back to the billion being a bit harsh on dropped segments. The workaround for me on downloads is to use multiple streams eg 10 so one stream having a hissy fit is hardly noticeable, eg speed drop is a 10th of line speed. That's sorted.

Only problem still remaining is HD video streams which can be as high as 3.5 mbps and dont like the router stopping mid flow as this causes pauses and the never ending (seems like) circle. Need to think of a workaround as the alternative speedtouch with it's fondness of rebooting during video stream isn't an option.

You have a PM.

Cheers got it.

The plot thickens - bare with me.

I have held the same sync on my line since before Christmas. This was just after the changes BT made on 21CN connections to no longer follow stepped BRAS values, but instead, follow (in real-time) the precise line rate of the line. So back when that happened, I set my AA profile to be 99% of BT BRAS and did a re-sync, this showing up on the portal:

24 Dec 2011 10:35:34 Update Updated TxMargin=100->99
16 Dec 2011 20:10:26 Line rate now 12692000 -BT-

Great I thought. Well, now I've just forced another re-sync, obtained a slightly faster sync, and this has now shown up:

Today 14:49:08 Tx rate (adjusted) 0 to 11102483 -Auto-

So, I suspect initially, AA were not factoring in the ADSL overhead when placing a limiter their side on my broadband. If you do the maths on the above figures, 11102483 is 99% of 11214629.29... which is 87.9% of the actual sync speed reported by my modem, 12755 Kbps (87.9% ADSL over head is about right, yes? I've seen this figure being quoted around).

So the up shot of all this is that for the past 2 months, I have, on occasions, been sent data faster than what my line can handle. Meaning dropped packets, which confirms what I said yesterday when I tested the download files and noticed I was seeing dup-acks and slight periods of reduced download speed, recovering seconds later (much like yourself, but not as prominent). This was because of inbound dropped packets (probably dropped at the BT BRAS limiter, not AA).

I have just re-run the downloads and they are now absolutely full speed, as far as what is reported in the browser progress bar. I also took a pcap whilst doing this. I'm still seeing dup-acks, but when they do occur, they are for literally bursts lasting fractions of a second (4 ms to be precise) but if you compare that to the bursts you get on your Billion pcap, some last as long as 300 ms.

The drastic improvement for me at least is that now AA are applying their shaper their side. In theory, there is no bottle-neck downstream on my connection any more since the data sent should always be 99% of my capable line speed (factoring in ADSL over head) and also, more intelligent shaping from the AA shaper (rather than the dumb policer BT BRAS).

As for your setup, I can't comment (Vivaciti hold the answers). They should apply limits their side as it's the "proper" thing to be doing.

Anyway, it confirms, at least for me, that somewhere, some how, pretty harsh policing is happening on the traffic when you are using the Billion and nicer, smoother shaping is happening with the SpeedTouch.

Finally, with regards to your multiple TCP streams being "better", if you think about this logically, of course they will be. If you are downloading across 4 parallel TCP streams, the back log of data in each connection pipe* is going to be a quarter of what it normally would be at full speed. You will still get pauses on each of these 4 connections, but they will be less, and probably not for as long (and so probably not as noticeable).

* pipe - I like to use the term pipe here as this is essentially how to think of a TCP session. It is a pipe, with a certain cross-sectional area (your capable transmission speed) of a certain length (the time it takes to send / receive packets to / from your peer).

Edited by deleted (Sat 11-Feb-12 16:38:18)

Interesting. I still think the Billion is just too sensitive to overspeed if what u are saying is correct. Your right Vivaciti needs to let me know what, if any shaping they are using, will be Monday for that now. I do know there is some sort of shaping because when I first got connected ITV player was chronic as well as 4oD. They adjusted my profile and sorted it so was getting 2 mbps streaming on those Players, BBC was unaffected. I was using the speedtouch then so may not have noticed any problems on port 80.

Your explanation also fits with my fiddling in the router, forcing ADSL1 and 2 modes at lower line rate as well as applying QoS of 50% in the router. If this shaping takes place after the modem then it will still stall so that would fit.

I've also been attacking Wireshark trying to learn how to use it, finally converting timestamps into something I can understand. But while doing this I found two TCP Analyze Window Full packets in a capture of a single stream I did from the TBB 100mb file. Why would the window be full? Repeating the excersize on a multi-stream download, there was only one TCP Window Full. But on the first capture the timestamp of the first Window full roughly coincided with the pause. Some more googling needed.

The shaping issue (if Vivaciti are shaping) might possible explain why Billion can't reproduce the problem (maybe) - do you even know what ISP they use? Are they even based in the UK? Do they even use the same exchange kit? So many variables there, it's not surprising they can't reproduce it.

Definitely have a chat with Vivaciti for sure. Another related question - are the sync speeds between the SpeedTouch and the Billion substantially different? Does the Billion grab a faster sync? If so, how much faster?

Edited by deleted (Sat 11-Feb-12 16:43:55)

Yes the Speedtouch grabs around 17 meg and the Billion 19 meg. Have a feeling the Billion Engineers are in China but pretty sure Billion UK tested the box.

Been reading about Silly Window Syndrome and this would account for Window Full segments and pauses. Nagle's algorithm is supposed to get rid of SWS so if that wasn't implemented that would account for Full Window packets and pauses. But the curious thing is the Window full in the capture was sent by the Apache server to the Billion, so the Billion sits and twiddles it's thumbs until the server has emptied it's buffer as far as I can tell.

Upstream is 1.2mbps so wouldnt have thought that would overload a TBB server unless the Billion is being aggressive in sending ACK packets too fast. It's just odd how it's so random.

Will see what Viva say.

In reply to a post by Banger:

Yes the Speedtouch grabs around 17 meg and the Billion 19 meg. Have a feeling the Billion Engineers are in China but pretty sure Billion UK tested the box.

Been reading about Silly Window Syndrome and this would account for Window Full segments and pauses. Nagle's algorithm is supposed to get rid of SWS so if that wasn't implemented that would account for Full Window packets and pauses. But the curious thing is the Window full in the capture was sent by the Apache server to the Billion, so the Billion sits and twiddles it's thumbs until the server has emptied it's buffer as far as I can tell.

Upstream is 1.2mbps so wouldnt have thought that would overload a TBB server unless the Billion is being aggressive in sending ACK packets too fast. It's just odd how it's so random.

Will see what Viva say.

I'm still looking at the dump you posted - they are always a pain especially large ones and I am working with tcpdump = text only in linux. I do have tcptrace which makes graphs out of dumps and at first sight it looks like a policer or full buffer is causing multiple losses causing the backoffs. These tend to appear worse when viewed from an app as the data just appears to stop even though it is still coming down the line. When the missing packets get retransmitted a big chunk of data then gets passed to the app (because at application level tcp provides in order byte stream).

As to why it happens only with the billion - I have no idea. It may be something as simple as the higher sync making things different.

One dump can be misleading - I just tried some and they all looked different.

What is the Window full you refer to ( I am not using wireshark so haven't seen that).

Your Billion has nothing to do with tcp as such so doesn't send acks. It's windows that handles that - I notice you have set a > 1meg window, and windows just blindly uses it, so on a close server you would expect to fill any buffers and get loss. I accept this doesn't explain why only the Billion is affected.

Here's a screenshot of the tcptrace throughput graph - note the scale doesn't go down to 0. You can see that it is getting full speed then gets knocked back (by multiple loss) recovers and repeats. This is sort of normal, but in this case it seems there is too much loss/backoff. The large window you set probably doesn't help, but then you may need it for distant servers.

Edit forgot www on url
http://www.andyqos.ukfsn.org/tpt.png

Edited by deleted (Sat 11-Feb-12 21:39:49)

I can't say how AA do things, but IME with entanet on a BT line it's the ISP that polices and BT BRAS that buffers.

Policing if set up right can be acceptable - in someways nicer for latency. When on 20CN it seemed that bras buffers were about 700ms which meant I had to ingress shape.

They seem to be a bit shorter now, but I can still lag myself out if I try. I don't know if this is due to isp policer being closer to BT rate now that profiles are gone or whether the buffers really are smaller (as some would argue they should be - buffer bloat).

As to why it happens only with the billion - I have no idea. It may be something as simple as the higher sync making things different.

Still happens when I force a lower sync by using ADSL1 or vanilla ADSL2 on the Billion.

What is the Window full you refer to ( I am not using wireshark so haven't seen that).

In Wireshark on a download I did today there were a couple of TCP.Analysis.Window.Full packets. But looking at the dump you are looking at there are NONE. This, I'm thinking maybe a complete red herring.

Here's a screenshot of the tcptrace throughput graph - note the scale doesn't go down to 0. You can see that it is getting full speed then gets knocked back (by multiple loss) recovers and repeats. This is sort of normal, but in this case it seems there is too much loss/backoff. The large window you set probably doesn't help, but then you may need it for distant servers.

Useful graph, I would never see most of those slowdowns on DU Meter except maybe the two almost pauses at the end. I have tried smaller Windows, while reducing the amount of pauses I see in the app. there came a point where line speed was limited by the small window size but pauses still appeared and again even on lower sync. of ADSL1. Did you see the link to the capture of the speedtouch on the same file, maybe you could run that through tcptrace and compare. Many thanks for looking at the dumps.

Been playing a bit more with Wireshark and I have found the I/O grapher which produces graphs down to ms granularity similar to the linux equivalent and has its own tcp trace. Some more playing needed.

Edit: Billion did advise turning of Jumbo Packet and this has improved things slightly and I also downloaded tcping.exe but that's not showing any loss on the TCP path to TBB.

Looking at the capture of the Billion when the pause happens there seems to be a slew of re-transmissions and lost segments. But as suggested earlier it could be that the Billion is just being a bit harsh with speeds and backing off way too much and stopping flow.

Edited by Banger (Sun 12-Feb-12 02:15:28)

and as if by magic tried a download tonight of SP3 and NO pauses with a single stream, talk about random.

http://flic.kr/p/bsLSGe

In reply to a post by Banger:

and as if by magic tried a download tonight of SP3 and NO pauses with a single stream, talk about random.

Yea, it's strange.

I looked harder at the last low trough in your first pcap and after a bunch of loss there is actually a delay where windows receives a packet and doesn't ack it for 200ms. I guess it's passing full buffers to the app - I wonder if a different os/more recent windows would do that.

I did get your other dump and it has just as many loss events but with less dramatic results - I haven't had time to look properly.

FWIW setting wireshark to just cap the first 100 bytes of each packet would be enough for this analysis and makes for much smaller pcaps.

In reply to a post by legume:

In reply to a post by Banger:

and as if by magic tried a download tonight of SP3 and NO pauses with a single stream, talk about random.

Yea, it's strange.

I looked harder at the last low trough in your first pcap and after a bunch of loss there is actually a delay where windows receives a packet and doesn't ack it for 200ms. I guess it's passing full buffers to the app - I wonder if a different os/more recent windows would do that.

I did get your other dump and it has just as many loss events but with less dramatic results - I haven't had time to look properly.

FWIW setting wireshark to just cap the first 100 bytes of each packet would be enough for this analysis and makes for much smaller pcaps.

Noted about small pcaps will dig into Wireshark later.

Billion have all but given up saying it is probably and incompatibility with my exchange equipment and my router, guess I will just have to live with it. I have Win 7 as a Guest OS using Microsoft Virtual PC and that does the same, it's looking more and more like the router.

And there is another anomily, small files eg 20mb dont pause at all just large ones around 50mb or bigger.

Edited by Banger (Mon 13-Feb-12 17:51:01)

Some simple ideas to maybe try:

1. Test downloads from another PC on the WAN port of the Billion
2. Test internet downloads using a different modem on the WAN port of the Billion
3. Try a new gigabit LAN card on the PC (sounds an odd idea in theory, but in practice not quite so daft)

In reply to a post by vimto_girl:

Some simple ideas to maybe try:

1. Test downloads from another PC on the WAN port of the Billion
2. Test internet downloads using a different modem on the WAN port of the Billion
3. Try a new gigabit LAN card on the PC (sounds an odd idea in theory, but in practice not quite so daft)

1. Done Same problem, different PC different LAN card.
2. Done Problem cured. Used speedtouch modem on Ewan port problem gone.
3. No spare slots.

In reply to a post by Banger:

In reply to a post by vimto_girl:

Some simple ideas to maybe try:

1. Test downloads from another PC on the WAN port of the Billion
2. Test internet downloads using a different modem on the WAN port of the Billion
3. Try a new gigabit LAN card on the PC (sounds an odd idea in theory, but in practice not quite so daft)

1. Done Same problem, different PC different LAN card.
2. Done Problem cured. Used speedtouch modem on Ewan port problem gone.
3. No spare slots.

Given 1, it's obviously not an ADSL or ISP issue as you wondered.

I would suggest if you cant get your router to function properly as a plain router on a home network, there's little point using internet testing to troubleshoot. Can it function properly as a plain switch...?

reading posts it appears situation is resolved, and is some conflict/bug with WAN ports and the modem. Where these lay will be difficult to figure out

In reply to a post by vimto_girl:

In reply to a post by Banger:

In reply to a post by vimto_girl:

Some simple ideas to maybe try:

1. Test downloads from another PC on the WAN port of the Billion
2. Test internet downloads using a different modem on the WAN port of the Billion
3. Try a new gigabit LAN card on the PC (sounds an odd idea in theory, but in practice not quite so daft)

1. Done Same problem, different PC different LAN card.
2. Done Problem cured. Used speedtouch modem on Ewan port problem gone.
3. No spare slots.

Given 1, it's obviously not an ADSL or ISP issue as you wondered.

I would suggest if you cant get your router to function properly as a plain router on a home network, there's little point using internet testing to troubleshoot. Can it function properly as a plain switch...?

If you mean is there any problem transfering files between PCs the answer is no, so yes it appears to function as a switch correctly.

What I don't understand is if two downloads are running only 1 will stall the other keeps running and vice versa, same with multiple streams.

Edited by Banger (Tue 14-Feb-12 20:59:32)

Just an update on this Billion Engineers are looking at my Wireshark captures to see if they can work it out.