Superhub Replacing the Superhub 1 with Superhub 2 (in modem mode)

ianch99 · 04-03-2014, 17:15

Just had a call from a very nice chap in the "Social Media Team" (?) who said they were going to send me a shub2 to replace my shub1 free of charge to "improve my service"

As I use the shub in modem mode, is there any reason *not* to swap out the shub1 for the current shub2? Reading past threads on this subject, apparently there is little to gain in modem mode, is this still the case with the current firmware?

I guess I would have a better router available if my N66U ever has problems I suppose ..

StevenNT · 04-03-2014, 18:18

If it's free, why not use it? and yes there is such a thing as the Social Media Team, they are the guy's that manage the @virginmedia twitter account and are very helpful.

Running in "Modem Mode" won't make a huge difference but if your N66U fails you would have a competent wireless modem/router to fall back on.

Sephiroth · 04-03-2014, 19:00

Agreed. The SH2 is a credible device.

Coffeeguy · 06-03-2014, 00:44

Out of interest, did they fix the issue where the SH2 wasn't giving ICMP high enough prio when it was 'busy', thus the 'laggy' tbb graphs compared with the SH1?

Sephiroth · 06-03-2014, 00:58

I wasn't aware of this issue. wouldn't we be seeing it on a heck of a lot of TBB graphs?

Coffeeguy · 06-03-2014, 12:02

Hmm I think I read somewhere that you were the one who had raised the issue during the trial about your TBB graphs having higher than normal avg latency compared to the SH1 in modem mode

tweetiepooh · 06-03-2014, 12:14

But surely dropping ICMP priority when busy is exactly what devices should do? ICMP is low priority traffic (compared to TCP/UDP) so can be delayed or even dropped when things get busy.

Juniper does lower ICMP priority and even lower pinging the device itself. I believe Cisco can behave the same way.

qasdfdsaq · 06-03-2014, 17:34

ICMP is not low priority, that's a common misconception.

Enterprise/carrier grade gear sometimes responds slowly to it on public interfaces but consumer routers do not. Even then, enterprise routers still respond to ICMP at normal/high priority on internal management interfaces.

Sephiroth · 06-03-2014, 19:31

Quote:

Originally Posted by Coffeeguy

Hmm I think I read somewhere that you were the one who had raised the issue during the trial about your TBB graphs having higher than normal avg latency compared to the SH1 in modem mode

Yes - that was on the v1.19 firmware. The subsequent trial releases cured what I had reported.

ianch99 · 06-03-2014, 19:36

Swapped out the shub1 for the shub2 today (around 2:30/3pm) and so far the ping graph looks the same ..

Sephiroth · 06-03-2014, 19:57

In modem mode, the two will look the same.

Ignitionnet · 06-03-2014, 20:06

Quote:

Originally Posted by qasdfdsaq

ICMP is not low priority, that's a common misconception.

Enterprise/carrier grade gear sometimes responds slowly to it on public interfaces but consumer routers do not. Even then, enterprise routers still respond to ICMP at normal/high priority on internal management interfaces.

Depends on the consumer router, seen some Alcatel stuff that responds really slowly.

More widely, not specifically to your good self, Sir, ICMP most certainly isn't slowed down when going through routers, it's not a low priority, it's not any priority it is fast switched and goes on its way.

The reason ICMP is a low priority when aimed at the router itself is that any traffic with a destination of the carrier grade / some enterprise kit leaves the fast switching plane and has to take a slower path. It's handled completely differently to traffic traversing the kit and tends to use contended resources.

Unless a switching plane is overbooked all traffic going in will go out without delay.

TLDR: Unless told to behave otherwise routers handle ICMP not heading for them (their control plane in Cisco-speak) in exactly the same manner as any other traffic.

horseman · 08-03-2014, 06:45

Quote:

Originally Posted by qasdfdsaq

ICMP is not low priority, that's a common misconception.

Enterprise/carrier grade gear sometimes responds slowly to it on public interfaces but consumer routers do not. Even then, enterprise routers still respond to ICMP at normal/high priority on internal management interfaces.

To elaborate back to the basics (in conjunction with your subsequent education from others

) ICMP has many type/code fields in addition to : " The Echo Request ICMP will have a Type field of 8 and a Code field of 0. Echo Replies have a Type field of 0 and a Code field of 0" to thus cover "Destination Unreachable, Source Quench, Redirect" etc etc

qasdfdsaq · 09-03-2014, 19:33

It's not really education when I already know something perfectly well - I just didn't want to go into that much detail when it wasn't relevant to get the point across.

Nonetheless you'll see from my wording and the rest of the thread they're really referring just to echo requests, a router passing data through doesn't "respond to" destination unreachables, etc. they just get passed like any ordinary data onto its destination. You don't send destination unreachables to intermediate routers.

philce · 09-03-2014, 20:58

Well this is the comparison.

Ignore the red timeouts in the second graph, this was me moving network connections.

SH2 "normal mode"

SH2 "Modem Mode" with TP-Link TL-WR741ND v1 running DD-WRT