Superhub : Superhub 2

[Kushan]

It's well known that the SH2 produces poor TBB graphs (in router mode, at least). However it's generally noted to not affect the connection so the current going theory is something to do with the ICMP packets being on a low priority.

[PhilHornby]

Originally Posted by Kushan

However it's generally noted to not affect the connection so the current going theory is something to do with the ICMP packets being on a low priority.

This theory was raised in the Trial - I disproved it to my own satisfaction.

I used the Windows "W32tm" command to measure round-trip times to Virgin Media's NTP server (this was using UDP packets directed at port 123, rather than ICMP). I got very similar results to TBB).



The command I used was:

w32tm /stripchart /computer:ntp.virginmedia.com /dataonly /packetinfo /period:1 (/samples:20)

If you want to reproduce the experiment.

The fact that people can't feel the effect is another matter!

[Sephiroth]

Originally Posted by Kushan

It's well known that the SH2 produces poor TBB graphs (in router mode, at least). However it's generally noted to not affect the connection so the current going theory is something to do with the ICMP packets being on a low priority.

LOL double LOL.

[img]Download Failed (1)[/img]

[progers]

I think Seph's had the black paint out!

[linwelin]

Originally Posted by StevenNT

via retentions dial 150 from a Virgin Media landline, then select menu option 5 then option 3 and they can post you it and all you pay is the postage costs.

phoned them up coming on monday he said there was an activation charge of £20 for it, but because i have had a lot of problems with my net he took the charge off.

[Kushan]

Originally Posted by PhilHornby

This theory was raised in the Trial - I disproved it to my own satisfaction.

I used the Windows "W32tm" command to measure round-trip times to Virgin Media's NTP server (this was using UDP packets directed at port 123, rather than ICMP). I got very similar results to TBB).



The command I used was:

w32tm /stripchart /computer:ntp.virginmedia.com /dataonly /packetinfo /period:1 (/samples:20)

If you want to reproduce the experiment.

The fact that people can't feel the effect is another matter!

I agree that it's up in the air as to the main cause, that's just what's been put forward as a reasonable explanation. So far, I've yet to see anyone suggest another reason.

I would say that if there was an effect on the connection, people would surely have pointed it out by now given how terrible those graphs are.

Originally Posted by Sephiroth

LOL double LOL.

Aren't you the one exception to this rule due to having a different FW version or something?

[Sephiroth]

Nope - same firmware as other triallists who reported a particular peculiarity.

[PhilHornby]

Originally Posted by Kushan

I agree that it's up in the air as to the main cause, that's just what's been put forward as a reasonable explanation. So far, I've yet to see anyone suggest another reason.

I would say that if there was an effect on the connection, people would surely have pointed it out by now given how terrible those graphs are.

It's reasonable to put it forward as a theory ... but it doesn't become fact, just because no one is in a position to disprove it.

But anyway, thinking about it: "priority" would only explain the symptoms when under heavy load - most of the TBB graphs I've seen show the same effects in the dead of night when the connection is not otherwise 'in use'. It would be a strange algorithm that purposefully delayed ICMP echoes, when there was no other work to do.

Here is an overview of the data from my tests. This is a real application, suffering a real degradation in its performance.

My line speed is 30Mbps/2, but with the old Draytek in circuit, the downstream is more like 10Mbps - yet latency improved dramatically.

If these UDP packets had been from a game, or a VOIP application, they would presumably have been affected in exactly the same way.

[jjp2701]

hi everyone i just got the superhub 2 yesterday, and had a load of nightmares with it already, my connection, goes of, for about 5 mins then comes back on, it has happened at random times, i rang them up about this and they said it is a known fault with the superhub 2 at the moment and they are trying to resolve this with a new update soon, anyone else had this problem ?

[Sephiroth]

We'd need to know what "connection goes off" means. Is it that the SH2 reboots (the lights go off and then only the arrow flashes, rtc), or is it wireless that drops but the SH2 doesn't reboot?

You could post the network log and tell us where in time it happened (the log shows 1 hour behind BST).

[jjp2701]

not got a clue how to do a network log, and it happened about 4.40pm, today, it is hard wired my pc connection, so nothing to do with wireless, and i diddnt really look at the superhub 2 when it happend, but my guess is it rebooted itself, for some reason, is there no way of putting the netgear firmware back on and taking virgin firmware off, then it would prob be working perfect

[Sephiroth]

The instructions for getting the configuration data and network logs can be found here.

Please post the Network Log, the Downstream and Upstream stats using copy & paste.

Cheers

[jjp2701]

Downstream Channels
Lock Status Channel ID Frequency Modulation Rx Power RxMER Pre RS Errors Post RS Errors
Locked 38 306750000 Hz 256 QAM 3.0 dBmV 37.9 dB 354 298
Locked 33 266750000 Hz 256 QAM 4.0 dBmV 37.6 dB 815 291
Locked 34 274750000 Hz 256 QAM 3.8 dBmV 37.6 dB 314 307
Locked 35 282750000 Hz 256 QAM 3.9 dBmV 37.9 dB 297 292
Locked 36 290750000 Hz 256 QAM 3.6 dBmV 37.9 dB 295 294
Locked 37 298750000 Hz 256 QAM 2.9 dBmV 38.3 dB 951 951
Locked 39 314750000 Hz 256 QAM 2.3 dBmV 37.6 dB 303 301
Locked 40 322750000 Hz 256 QAM 1.8 dBmV 37.4 dB 300 298




Upstream Channels
Lock Status Channel ID Frequency Modulation Tx Power Mode Channel Bandwidth Symbol Rate
NotLocked 0 0 Hz 0 dBmV 0 Ksym/sec
NotLocked 0 0 Hz 0 dBmV 0 Ksym/sec
Locked 1 45800000 Hz ATDMA 52.3 dBmV 16QAM 6400000 Hz 5120 Ksym/sec
Locked 2 35800000 Hz ATDMA 51.8 dBmV 16QAM 6400000 Hz 5120 Ksym/sec


is that wot u mean m8 ?

[Sephiroth]

Yes please, plus the Network Log pointing out to us the time of day when you had the problem (remembering that the log is one hour behind BST.

[Kushan]

Originally Posted by Sephiroth

Nope - same firmware as other triallists who reported a particular peculiarity.

Really? I must have misread a post (or got you confused with someone else). I apologise.

Originally Posted by PhilHornby

It's reasonable to put it forward as a theory ... but it doesn't become fact, just because no one is in a position to disprove it.

Yes, you are quite right about that. I certainly didn't mean to imply it as fact, it was more I was trying to get across that the SH2 graphs are known about and have been reported and that was just the going theory that I've seen (mostly due to the lack of an alternative theory). I have seen someone post a graph that shows ok at night then hectic in the evening though (hence why my suspicions went straight to the ICMP thing, as my work connection's router definitely does do that and the graphs were remarkably similar) but it seems many people are getting different results with the SH2. One thing the majority do have in common though is that despite the graphs, their connection does seem pretty stable.