dear ntl [whoever]...

[td444]

Please oh please can you redistribute users between your upstreams fairly ? Its so frustrating to know that my latency surges are due to NTL's stupid upstream balancing script shoving most people on 1 upstream!

And some members of this forum are ****ed off with me asking them to change it back, rightly so id say. If the dam rebalancing didnt occur, id be a happier bunny.

/rant end

[carlingman]

Can i ask which Modem you use as with some of the older Modems you may be lucky and can change your upstream yourself.

:D

[td444]

No, its not an old surfboard - believe me, I'd do it myself if I could.

[BBKing]

due to NTL's stupid upstream balancing script shoving most people on 1 upstream!

Do you have evidence that it does this? I have evidence that it works fine. You may well have a problem, but the reason probably isn't any fault in the balancing script which has worked wonders on this problem in recent months along with bandwidth doubling and numerous resegmentations.

[td444]

Do you have evidence that it does this? I have evidence that it works fine. You may well have a problem, but the reason probably isn't any fault in the balancing script which has worked wonders on this problem in recent months along with bandwidth doubling and numerous resegmentations.

Yeah I do, give me 10 mins. On the HFC im on, 66% of users are on one stream, the remaining are on the other :S I wouldnt complain if this was a fixed resource, but it isnt as you know. Whilst playing online games with the netgraph active and anything that could interfere with the connection disabled, there's still surges.

[Stop It]

Um, It depends I suppose, Are the upstreams balenced by users, or upstream usage? if its the latter then having 66% of the lowest upstreamers would be of no suprise

[td444]

Um, It depends I suppose, Are the upstreams balenced by users, or upstream usage? if its the latter then having 66% of the lowest upstreamers would be of no suprise

Problem is, there's only a limited amount of code segments in the CDMA mode that docsis v1 works at. If those PC's are on during the day and night, and responding to ARP traffic, they'll eat into the upstream's available code segements, hence my annoyance.

Edit : It could be TDMA , im not 100% in the method in use at PHY layer.

[td444]

As requested.

UBR 10.155.32.0 at 2004 Jul 17, 13:35

Channel Freq Max Usage Users Min Ave Max
MHz kbps kbps ms ms ms
Dnstr 0 402.75? 30342 5973 398 15 44 485
Upstr 1 32.8 5120 937 196 15 48 485
Upstr 3 36.0 5120 318 69 15 44 390
Upstr 4 37.6 5120 112 80 15 38 297
Upstr 6 40.8 5120 139 53 15 37 94

Im guessing the script is useless due to some upstreams being disabled. Im also aware that I can only access upstreams 1-3 due to the HFC config.

[Stop It]

As requested.

UBR 10.155.32.0 at 2004 Jul 17, 13:35

Channel Freq Max Usage Users Min Ave Max
MHz kbps kbps ms ms ms
Dnstr 0 402.75? 30342 5973 398 15 44 485
Upstr 1 32.8 5120 937 196 15 48 485
Upstr 3 36.0 5120 318 69 15 44 390
Upstr 4 37.6 5120 112 80 15 38 297
Upstr 6 40.8 5120 139 53 15 37 94

Im guessing the script is useless due to some upstreams being disabled. Im also aware that I can only access upstreams 1-3 due to the HFC config.
Hmmm, Just used the DOCSdiag thingy, and it shown 6 upstreams , all with 100users, ish, (forgot to copy it) the balencing seems to be working here ok... :p

[td444]

Hmmm, Just used the DOCSdiag thingy, and it shown 6 upstreams , all with 100users, ish, (forgot to copy it) the balencing seems to be working here ok... :p

Its the missing upstreams that have caused this. But my area's always been a bit unbalanced one way or another. So the script doesnt really work for me unforunately.

[B4mbl3]

Hey all

Maybe this might be the cause of my problems ..since around easter time my ping to any gaming server goes sky high from around 4pm to about 11pm and mostly all weekend...the usal servers i play on used to gimme solid 30-40 pings at the time of posting all servers exeed 200ms according to ASE browser.

I have phoned ntl so many times to complain but they refuse to accept there is a problem in my area GU21 and the engineers they send round (3 so far) cant find any faults :/

I connect via sacm ntl200 thing and d-link ethernet card
winxp pro
512 ram
xp2700
pc is clean of virus and adware/spyware

Any help or advice would be greatly appreciated

B4mbl3

[Chrysalis]

interesting how your upstream channels are 5mbit instead of 2mbit and none look overused.

[td444]

interesting how your upstream channels are 5mbit instead of 2mbit and none look overused.

Usage in terms of data and usage in terms of avaliable 'cells' (I know its not ATM, but im not sure if CDMA or TDMA is in use...) are different matters. General users wont get effected much by a small delay in upstreams. Im hoping by next tuesday morning that it'll have balanced out a bit.

[BBKing]

Edit : It could be TDMA , im not 100% in the method in use at PHY layer.

TDMA on the upstreams.

5120 is the new standard upstream width, a result of doubling the available bandwidth per upstream channel (see why I get annoyed when people said that ntl spent nothing on the network - I was working on that project at the time but had to keep schtum).

However, if you're in a microsegmented area (upstream ports split 3+3 rather than in a single block of 6) and two of your three upstreams aren't available, the balancing script can't balance you. Not a fault with the script, but a hardware problem on the UBR/return path set up.

I can find out what UBR you're on from your IP address, if you feel free to give this out. I can then confirm this suspicion and drop a note to someone.

[Stop It]

TDMA on the upstreams.

5120 is the new standard upstream width, a result of doubling the available bandwidth per upstream channel (see why I get annoyed when people said that ntl spent nothing on the network - I was working on that project at the time but had to keep schtum).

However, if you're in a microsegmented area (upstream ports split 3+3 rather than in a single block of 6) and two of your three upstreams aren't available, the balancing script can't balance you. Not a fault with the script, but a hardware problem on the UBR/return path set up.

I can find out what UBR you're on from your IP address, if you feel free to give this out. I can then confirm this suspicion and drop a note to someone.
Bah, My UBR hasnt got that upstream upgrade, wahhhhh... (fails to mention the fact that I have never seen my upload fall below 28k/s in any test :p )

UBR 10.139.144.0 at 2004 Jul 19, 11:14

Channel Freq Max Usage Users Min Ave Max
MHz kbps kbps ms ms ms
Dnstr 0 402.75 30342 239 19 15 27 47
Dnstr 1 402.75 30342 6060 618 15 29 484
Upstr 1 32.8 2560 362 126 15 29 203
Upstr 2 34.4 2560 411 102 15 25 78
Upstr 3 36.0 2560 409 108 15 25 78
Upstr 4 37.6 2560 713 128 15 31 219
Upstr 5 39.2 2560 259 97 15 33 484
Upstr 6 40.8 2560 260 76 15 28 266

And Im on channel 5, yey :p

[td444]

TDMA on the upstreams.

5120 is the new standard upstream width, a result of doubling the available bandwidth per upstream channel (see why I get annoyed when people said that ntl spent nothing on the network - I was working on that project at the time but had to keep schtum).

However, if you're in a microsegmented area (upstream ports split 3+3 rather than in a single block of 6) and two of your three upstreams aren't available, the balancing script can't balance you. Not a fault with the script, but a hardware problem on the UBR/return path set up.

I can find out what UBR you're on from your IP address, if you feel free to give this out. I can then confirm this suspicion and drop a note to someone.


It is a 3+3 area for sure. Its only really at peaktime's I get effected, otherwise its ok.

[lf86]

I'm in Coventry too - my service is fine, however recently I did get resegmented or something because my IP's changed from the 213.xxx range to 82.xxx along with my UBR address also. Anyone know what that was about? My service was out for about 36 hours.

[td444]

Well it appears NTL do listern to their customers :-) It's all good now.

[Ignition]

Hardware issue with uBR card - which is why an upstream on each segment was 'missing'. Once the card had been replaced all upstreams were back and the rebalance system could do its' job again.