cancel
Showing results for 
Search instead for 
Did you mean: 

TBB Graph - any ideas about this pattern?

Community Veteran
Posts: 471
Thanks: 35
Fixes: 2
Registered: 26-09-2015

TBB Graph - any ideas about this pattern?

I haven't looked at my TBB monitor for a while, but when I looked just now I noticed this odd pattern.  This was during a normal weekday, there would be no user activity corresponding to those peaks at 02:00 and 06:30 and, nobody even home between 07:30 and 18:00. 

The other odd thing is that these latency spikes don't correspond with my logging of RTT pinging outwards from the house.  Note I don't have the whole period because my desktop PC was offline early evening, but the graph covers most of the same time.  On the other hand my probe shows drops where the TBB graph doesn't, and these drops are very few and don't correspond with the TBB episodes either.
Any thoughts?
14 REPLIES
Superuser
Superuser
Posts: 11,272
Thanks: 2,713
Fixes: 22
Registered: 22-08-2007

Re: TBB Graph - any ideas about this pattern?

Tony,
Do you by chance have a Sam Knows internet monitor?
Community Veteran
Posts: 471
Thanks: 35
Fixes: 2
Registered: 26-09-2015

Re: TBB Graph - any ideas about this pattern?

No I don't.    Following what I think is your train of thought, I don't have any easy way of monitoring actual traffic, neither of the routers I have to hand support SNMP.  On the other hand, why would TBB record RTT of over 140ms, when pinging outbound maintains 40-50ms?  Some sort of difference is up vs down traffic shaping?
Superuser
Superuser
Posts: 11,272
Thanks: 2,713
Fixes: 22
Registered: 22-08-2007

Re: TBB Graph - any ideas about this pattern?

What about Win10?  Possibly serving updates upto the Internet?
Community Veteran
Posts: 471
Thanks: 35
Fixes: 2
Registered: 26-09-2015

Re: TBB Graph - any ideas about this pattern?

No Windows 10, but I'm leaning towards a Windows issue.  During the day, when the house was unoccupied, the only end devices live on the network would be our PVR and the desktop PC.  The PVR connection is management only, it doesn't download content. 
Thinking about why latency would show on TBB pinging in, but not PRTG pinging out - I saw somewhere that Plusnet prioritise ping on download traffic - could it be that the prioritise echo-reply specifically, rather than both directions?
Superuser
Superuser
Posts: 11,272
Thanks: 2,713
Fixes: 22
Registered: 22-08-2007

Re: TBB Graph - any ideas about this pattern?

The plot is very 'mechanical' having a duration of an hour at 4.5 hour intervals.  Do you know people local to you with whom you could arrange to set up more TBB BQM monitors?
Will RouterStats work with your router?  Would be interesting to see what's happening with SNRM and error counts.  This is not traffic shaping.
Community Veteran
Posts: 471
Thanks: 35
Fixes: 2
Registered: 26-09-2015

Re: TBB Graph - any ideas about this pattern?

I've been running Router Stats Light, but this doesn't pick up errors as my router doesn't present these.  Logged noise margin doesn't change over that cycle as far as I can see.  My RSL graphs are only two hours, so rather than show the whole day I'll just put up a couple that cover from 08:30 to 12:30
Community Veteran
Posts: 5,080
Thanks: 440
Fixes: 16
Registered: 10-06-2010

Re: TBB Graph - any ideas about this pattern?

But then we'd be back to the debate about how ADSL line errors could possibly explain an increase in latency, and I still don't really think that they can. CRC errors would be visible as packet loss on the ping monitor graphs, not increased latency. If having to use the FEC data to correct errors somehow slows down your modem and it causes an extra 100ms latency, that implies your modem can't do its job properly.
I have noticed that the first packet in a series of incoming ping echo request packets tends to be prioritised as 0x80 (gold), and the rest get 0xA0 (titanium), but I don't know if the one ping packet per second that a TBB monitor sends are far enough apart so that they all end up gold. For the ping monitor running in the other direction, as you send out the ping echo requests, the traffic management then should be expecting the ping responses, so they all get classified titanium.
Community Veteran
Posts: 471
Thanks: 35
Fixes: 2
Registered: 26-09-2015

Re: TBB Graph - any ideas about this pattern?

Quote from: ejs
... I still don't really think that they can. CRC errors would be visible as packet loss on the ping monitor graphs, not increased latency.

I agree.  I think the only contrary view comes from people at Plusnet who I suspect aren't really up to understanding things like that. 
However that wasn't really the reason for my post.  I was really wondering if that "signature" of episodes regularly appearing day and night was recognised.    It's not every day, but appeared on the 1st, 2nd and 4th of December, then again yesterday.  But not today or Monday.    My guess is network traffic, our link is quite slow and it doesn't take much particularly in the upload direction to push the RTT up to 100 to 150ms.  I just can't think of any recurring job that would do this.
What marking are you referring to?  I've just done a quick capture on the LAN and as far as I can see all echo-replies come back with dscp 0x28.  I must say I would be surprised if Plusnet are relating echo requests with replies on a stateful basis.
Community Veteran
Posts: 5,080
Thanks: 440
Fixes: 16
Registered: 10-06-2010

Re: TBB Graph - any ideas about this pattern?

Yes, the DSCP Differentiated Services Field in wireshark:
Quote
Differentiated Services Field: 0xa0 (DSCP: CS5, ECN: Not-ECT)

Or the PREC in a firewall (iptables) log if I use a website to ping my IP - the first one gets 0x80, the rest get 0xA0
Quote
IN=ppp0 OUT= MAC= SRC=67.222.132.211 DST=87.112.my.ip LEN=28 TOS=0x00 PREC=0x80 TTL=238 ID=9553 PROTO=ICMP TYPE=8 CODE=0 ID=124 SEQ=8875
IN=ppp0 OUT= MAC= SRC=67.222.132.211 DST=87.112.my.ip LEN=28 TOS=0x00 PREC=0xA0 TTL=238 ID=9554 PROTO=ICMP TYPE=8 CODE=0 ID=124 SEQ=9314
IN=ppp0 OUT= MAC= SRC=67.222.132.211 DST=87.112.my.ip LEN=28 TOS=0x00 PREC=0xA0 TTL=238 ID=9555 PROTO=ICMP TYPE=8 CODE=0 ID=124 SEQ=9328
IN=ppp0 OUT= MAC= SRC=67.222.132.211 DST=87.112.my.ip LEN=28 TOS=0x00 PREC=0xA0 TTL=238 ID=9556 PROTO=ICMP TYPE=8 CODE=0 ID=124 SEQ=9338

If you've got other dscp values, it's possibly your router altering them locally if it applies its own QoS. aesmith's packets have the correct prioritisation markings. The whole Differentiated Services Field is divided into two parts, the DSCP part and the ECN part, and we're only really interested in the DSCP part.
Community Veteran
Posts: 471
Thanks: 35
Fixes: 2
Registered: 26-09-2015

Re: TBB Graph - any ideas about this pattern?

Sorry, I'm the wrong way round.  I was looking at outgoing ping and corresponding incoming replies (which is where I saw 0x2Cool.  I don't have a convenient way of looking at pings from outside, but I expect I'd see the same as you. 
Also the DSCP values didn't look familiar which was why I asked and looked.  I think your device may be counting two more bits on the right, or is that a PPP representation?  I'm used to the 0-63 (decimal) range, but to be honest for our kit we can normally enter names (EF, CS5 etc), so I'd probably have had to look up the number in any case.
Community Veteran
Posts: 5,080
Thanks: 440
Fixes: 16
Registered: 10-06-2010

Re: TBB Graph - any ideas about this pattern?

I'm just going on what wireshark usually gives, yes it can expand the field into two parts:
Differentiated Services Field: 0xa0 (DSCP: CS5, ECN: Not-ECT)
    1010 00.. = Differentiated Services Codepoint: Class Selector 5 (40)
    .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)

The whole hex values are used in this guide for checking the traffic prioritisation. I'll edit my previous post to use a more accurate term.
Community Gaffer
Community Gaffer
Posts: 13,161
Thanks: 930
Fixes: 77
Registered: 04-04-2007

Re: TBB Graph - any ideas about this pattern?

What router do you have?

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

Community Veteran
Posts: 471
Thanks: 35
Fixes: 2
Registered: 26-09-2015

Re: TBB Graph - any ideas about this pattern?

Linksys WAG320N.    I had the Plusnet 2704N in service for a couple of weeks, I'll have to look back and see what dates, and whether the pattern appeared then.  However since it's been far from everyday that may not be conclusive.
Community Veteran
Posts: 471
Thanks: 35
Fixes: 2
Registered: 26-09-2015

Re: TBB Graph - any ideas about this pattern?

Quote from: ejs
I'm just going on what wireshark usually gives,

Cheers, I'd never noticed that Wireshark displays these as 8 bit, maybe because the form I'm familiar with appears as well ...
 
  [tt]Differentiated Services Field: 0xa0 (DSCP 0x28: Class Selector 5; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))[/tt]