Quick heads-up

We've just added a feature. Not documented yet

seb

Hi Seb - any clues?

In reply to a post by Bam16:

Hi Seb - any clues?

Go look

In reply to a post by seb:

Go look

I clicked create... nice!

I created a monitor from Edinburgh for my router which is already monitored from London, to compare. However the Edinburgh monitor is showing 'no data'

In reply to a post by DFScale:

I created a monitor from Edinburgh for my router which is already monitored from London, to compare. However the Edinburgh monitor is showing 'no data'

I was about to say it takes a little bit of time before it populates, but you created it a while back.
The data is being logged the device so this is a bug of some kind. Will get someone to check it over in the morning.

seb

Yes - sorry I did take a look and tried clicking on create. I saw the option to select an Edinburgh server, but didn't know if/how new it was... I created my BQM a while ago and didn't remember the option - didn't know if it was new or my memory failing me...

Thank you anyway

Before I add Edinburgh to my monitoring - what does this warning actually mean?

https://i.postimg.cc/vmVTMWsv/Screenshot-2026-10-26-...

Image link above. Text:

Potential issues detected
Passed LON1 TBB (ncuk.com) (London) - Latency: 5.695ms • Packets: 4/4 • Loss: 0%
Passed EDI1 / Commsworld (Edinburgh) - Latency: 15.801ms • Packets: 4/4 • Loss: 0%
Multiple record types detected - this host may be behind a CDN/proxy (Cloudflare, AWS CloudFront, etc.)

Are they using single IP addresses or ranges?

Nice

Well, it will be when it gets some data

In reply to a post by rmay_uk:

Before I add Edinburgh to my monitoring - what does this warning actually mean?

https://i.postimg.cc/vmVTMWsv/Screenshot-2026-10-26-...

Image link above. Text:

Potential issues detected
Passed LON1 TBB (ncuk.com) (London) - Latency: 5.695ms • Packets: 4/4 • Loss: 0%
Passed EDI1 / Commsworld (Edinburgh) - Latency: 15.801ms • Packets: 4/4 • Loss: 0%
Multiple record types detected - this host may be behind a CDN/proxy (Cloudflare, AWS CloudFront, etc.)

I believe this is because you're linking to a CNAME. The message is a bit unclear and I think originates from us trying to warn people who are monitoring IPs which may not be theirs but we need to clarify that.

seb

In reply to a post by billford:

Nice
Well, it will be when it gets some data

Yeah we're having some issues. Didn't see them in testing and mine works!
Working on it now

In reply to a post by MHC:

Are they using single IP addresses or ranges?

Single IPv4 and IPv6 address which is on the add/edit BQM page.. we will update docs once we fix the bugs.

seb

Thanks

Did put the single ones into my UDM-Pro and seems to be working fine.

In reply to a post by seb:

In reply to a post by billford:

Nice
Well, it will be when it gets some data

Yeah we're having some issues. Didn't see them in testing and mine works!
Working on it now

Dunno if it's any help- if I click "Share", "Generate" and scroll down to Preview the graph shows up...


edit- add share link My Broadband Ping

Edited by billford (Mon 26-Oct-26 12:42:23)

In reply to a post by seb:

We've just added a feature. Not documented yet
seb

If you are planning to ping the same host from both locations, it's best to just add it to the current monitor rather than setting up a new one. You can see them side by side in some places, and we'll be integrating this a bit more later.

In reply to a post by seb:

Working on it now

It works, thanks

The Edinburgh one looks pretty horrible, but considering I live somewhat south of Oxford it's not too surprising

Seems fine for me.

When you click on the front page graph, it automatically brings up the London test. Could there be an option, for those in the North or Scotland to have Edinburgh as default?

In reply to a post by billford:

Dunno if it's any help- if I click "Share", "Generate" and scroll down to Preview the graph shows up...

Just done that myself and my graph now shows up. Indicates to me that the event of generating the graph is an event which triggers some process, which is not triggered by setting up the graph in the first place.

In reply to a post by DFScale:

Just done that myself and my graph now shows up. Indicates to me that the event of generating the graph is an event which triggers some process, which is not triggered by setting up the graph in the first place.

Not saying that doesn't happen, but I think you may just have got lucky with the timing- I was still getting "No Data" on the BQMs in my profile even after generating the shared ones.

Edited by billford (Mon 26-Oct-26 14:23:20)

In reply to a post by seb:

If you are planning to ping the same host from both locations, it's best to just add it to the current monitor rather than setting up a new one. You can see them side by side in some places, and we'll be integrating this a bit more later.

Just tried to add the Edinburgh monitoring location but it can't contact my Hostname.... the London one is working ok

That's me being silly... need to add the Edinburgh server IP address to my firewall I think

In reply to a post by Bam16:

That's me being silly... need to add the Edinburgh server IP address to my firewall I think

Yep this is why we added the check on the edit/create pages.
FWIW I had the same problem

seb

In reply to a post by MHC:

Seems fine for me.

When you click on the front page graph, it automatically brings up the London test. Could there be an option, for those in the North or Scotland to have Edinburgh as default?

Whilst technically possible, we would prefer that everyone uses the London-based test node as it gives us consistent data where we have tens of thousands of monitors already, we're going to look at the limits shortly to try and encourage more people to use all the test servers, though. We may default it to include all the servers rather than just the London server. We haven't done that yet because we haven't formally announced it, and there are a few bugs still, clearly.

In reply to a post by billford:

In reply to a post by seb:

Working on it now

It works, thanks

The Edinburgh one looks pretty horrible, but considering I live somewhat south of Oxford it's not too surprising

I'm sure people in Scotland would probably say the same about the London server, although in many cases you might find their traffic comes down to London anyway. This is kind of what this tool will help us uncover

Have just compared the two after 24 hours.

Both very similar except for the increased latency. Both have big spike at the same time - one where I have an overnight speedtest (Ubiquiti) and the second where I was doing a large >100MB upload. The saw tooth effect I get is on both but there is an offset between them

In reply to a post by MHC:

... but there is an offset between them

Likely due to a new BQM taking at least 24 hours to get itself "synchronised" with the time axis. I think it's been like that ever since it started.

They are synced fine - the offset I was referring to is in the "saw tooth". The latency increases by maybe 1ms, then over a period of (at present) 100minutes or so, slowly drops down, before a sudden 1ms increase again - and it repeats.

In reply to a post by MHC:

They are synced fine - the offset I was referring to is in the "saw tooth". The latency increases by maybe 1ms, then over a period of (at present) 100minutes or so, slowly drops down, before a sudden 1ms increase again - and it repeats.

Sawtooth patterns can be caused by CPEs sometimes responding in different ways, and it may be that they are tracking connection status or something like that, which could cause a different pattern. However, that is very interesting. Which UI model are you using?

I have a wave pattern of green/blue (min/average) on one of mine.

Edited by seb (Wed 28-Oct-26 16:20:51)

Mine is a a UDM-Pro

You can possibly access my BQM but it not I can send links

In reply to a post by MHC:

Mine is a a UDM-Pro
You can possibly access my BQM but it not I can send links

Ok your pattern is the same I've seen on a UDR. I might look at the configs to see why that might be when I have a moment.. I think it's related to something which uses CPU resources like security/VPN/IDS/filtering/etc.

Edited by seb (Thu 29-Oct-26 01:41:15)

In reply to a post by seb:

We've just added a feature. Not documented yet

Anyone have any outstanding bugs/issues?

seb

Not here, all good thanks.

No complaints here.

Our monitoring keeps flagging issues but live pings are fine.. think we may have some issues which could affect the 4 pings it checks when you add/edit a monitor. It may have loss under some cases which isn't real loss. We think it's a bug in the Firebrick code that affects live ones but not our dev ones

seb

In reply to a post by seb:

I'm sure people in Scotland would probably say the same about the London server, although in many cases you might find their traffic comes down to London anyway. This is kind of what this tool will help us uncover

Not sure if this is the sort of thing you're looking for... up until last night my BQM's from London and Edinburgh, both IPv4 and IPv6 were all essentially identical apart from the higher base latency from Edinburgh.

Then at 8pm, Edinburgh v6 showed a slight increase in latency, along with a red spike which has repeated every hour on the hour since then.

It didn't show on the Edinburgh v4 until 10pm, with a red blip rather than a spike, then just after 11pm it went back to normal.

Nothing much visible at all on either of the London BQMs. I'm with IDNet FTTP and (I think) Zen backhaul, so likely Zen shuffling their routing tables?

Graphs:

Edinburgh: IPv4, IPv6

London: IPv4, IPv6

Due to a brief and lamentable lack of attention on my part, the above no longer work

Edited by billford (Wed 04-Nov-26 18:38:18)

I too have the little blip just after 10:00 pm and about an hour or two of increased latency from EDI before it settled back to teh original pattern

Shortly after I posted, there was a small red blip on the EDI BQM; the latency went back to where it was before and the hourly spikes seem to have disappeared... nothing visible on any of the others.

Your ISP is BT I think? So likely not a Zen backhaul issue (unless Zen/IDNet have read this and decided to do something about it ).

Edited by billford (Wed 04-Nov-26 12:01:18)

My latency from EDI increased from just over 20ms to just under 30ms from 2000 to 0030 approx ad then back to normal. My Lon latency at just under 20ms remained unaffected.

In reply to a post by seb:

Anyone have any outstanding bugs/issues?

Couple of points, not really bugs:

1) The "Share" button only gives a link to the Live graph, the option for a 24-hour "snapshot" seems to have gone (unless I'm missing something). Will it be coming back? (Please )

2) The arrow to go straight from one BQM to the next disappears after you've done a lap... and there's no back arrow. Fixable? (Please )

Correct. Although I don't have the hourly spikes.

At a guess, a switch/node/route was taken out causing the blip.

In reply to a post by billford:

1) The "Share" button only gives a link to the Live graph, the option for a 24-hour "snapshot" seems to have gone (unless I'm missing something). Will it be coming back? (Please )

Click "Detail & History" then "Share this Day"

In reply to a post by billford:

2) The arrow to go straight from one BQM to the next disappears after you've done a lap... and there's no back arrow. Fixable? (Please )

I don't think I remember that. If you press left/right on keyboard it goes between the different graphs on the same monitor (i.e. LON1 or the original source and EDI1)

That all works, so it was me missing something after all, thanks 👍

I hadn't thought of using the keyboard arrows; I was thinking of the right-pointing arrow on a BQM when you click it to get the enlarged version. Nor had I thought of looking at the history to share a specific day's results, but it does make more sense

In reply to a post by billford:

That all works, so it was me missing something after all, thanks 👍

I hadn't thought of using the keyboard arrows; I was thinking of the right-pointing arrow on a BQM when you click it to get the enlarged version. Nor had I thought of looking at the history to share a specific day's results, but it does make more sense

The arrows are there but faint .. but it still goes between the same monitor not different BQMs

In reply to a post by billford:

That all works, so it was me missing something after all, thanks 👍

I hadn't thought of using the keyboard arrows; I was thinking of the right-pointing arrow on a BQM when you click it to get the enlarged version. Nor had I thought of looking at the history to share a specific day's results, but it does make more sense

btw you should add the EDI1 pings to the monitor not create new monitors.. then it's visible on one URL

seb

In reply to a post by seb:

The arrows are there but faint .. but it still goes between the same monitor not different BQMs

My first thought when I read that was Hmmm..., but it turns out that on my setup they're not faint, they're invisible. Until I move the mouse to roughly the right place, then they show up. Hence why I missed them

In reply to a post by seb:

btw you should add the EDI1 pings to the monitor not create new monitors.. then it's visible on one URL

Yeah, I saw your earlier remark about that, but I'd already set mine up by then. I'll tidy it up shortly.

This is quite interesting. When you say Zen backhaul, what exactly do you mean.

I really want to add automatic tracing for the path from the ping node to the user into this system.

In reply to a post by seb:

When you say Zen backhaul, what exactly do you mean.

Bear in mind that I'm no expert, but as I understood things at the time: when I was on FTTC, Zen were leasing some of BT's (OR's?) fibre bandwidth from the cabinet back to their own network for their own customers; the cabinet was highly populated and congestion (using BT/OR) was fairly frequent so IDNet "sub-leased" some bandwidth from Zen to get my data back to their network, avoiding BT almost entirely... whatever, it worked- the congestion vanished!

I just assumed that something similar would apply with FTTP, but I've no real evidence and never bothered to ask... maybe I should have done, I have a feeling I'm showing my ignorance^* .

I really want to add automatic tracing for the path from the ping node to the user into this system.

Would this be just for your own internal stats or visible to the user? It would be interesting to see what sort of journey my packets go on, and potentially very useful at times



^* Not that I'm too bothered about that, I'm well aware of some huge, sparsely populated areas in my knowledge!

In reply to a post by billford:

In reply to a post by seb:

When you say Zen backhaul, what exactly do you mean.

Bear in mind that I'm no expert, but as I understood things at the time: when I was on FTTC, Zen were leasing some of BT's (OR's?) fibre bandwidth from the cabinet back to their own network for their own customers; the cabinet was highly populated and congestion (using BT/OR) was fairly frequent so IDNet "sub-leased" some bandwidth from Zen to get my data back to their network, avoiding BT almost entirely... whatever, it worked- the congestion vanished!

I just assumed that something similar would apply with FTTP, but I've no real evidence and never bothered to ask... maybe I should have done, I have a feeling I'm showing my ignorance^* .

I'm not exactly sure what IDNet took and where, but I suspect they took a handoff at the telephone exchange or in the region, rather than using BT Wholesale to link back from there to their LNS in a datacentre. This wouldn't cover congestion at the cabinet, but on the backhaul from the telephone exchange. Same would apply to FTTP potentially. It's not really any different to Internet routing except you may not see as much on traces.

In reply to a post by billford:

Would this be just for your own internal stats or visible to the user? It would be interesting to see what sort of journey my packets go on, and potentially very useful at times

There's no reason we wouldn't expose the return traceroute to users if we have it. We can obviously do a trace route on our tools page at any time, anyway if you want it. This would just the benefit of doing it automatically when there's an event or regularly. We have tens of thousands of BQMs, so it's not something that we can do every minute for every BQM, though. We need to think about how they would work.

We have a great internal tool that I've spent some time developing which isn't really in production yet, but I'd like to get a public version of that at some point as well, as it highlights very clearly when there are issues on networks. We're certainly going down the road of analysis more now. I want to get another ping box up quite soon (already agreed with the network hosting it). I'm also trying to get one into Amsterdam but need to find a network (not just one that links it back to LINX).

Once that's done we have another project which is quite exciting

seb

In reply to a post by seb:

btw you should add the EDI1 pings to the monitor not create new monitors.. then it's visible on one URL

??? AFAICS, different monitors is the only simple way to see LON and EDI side by side. Or am I missing something?

In reply to a post by DFScale:

In reply to a post by seb:

btw you should add the EDI1 pings to the monitor not create new monitors.. then it's visible on one URL

??? AFAICS, different monitors is the only simple way to see LON and EDI side by side. Or am I missing something?

When you share a monitor it shows the graphs side by side using the "direct link"

If you use HTML embeds you select which graph and it gives you the code/url. But note that changing the URL will reveal the other graph, so you're not protecting graph by not sharing that URL separately. The sharing function is for the monitor as a whole, including all ping sources.

If you mean the "Your Monitors" page when logged in, yes you're right that summary only shows one graph until you click Details and History.
We're going to see about how we can change that view to allow the different graphs to also be shown, possibly with a tick box option.

e.g .here's a share:
https://www.thinkbroadband.com/broadband/monitoring/...
(will be NO DATA until it starts but by the morning you'll see what I mean).


seb

Edited by seb (Fri 06-Nov-26 02:19:09)

In reply to a post by seb:

e.g .here's a share:
https://www.thinkbroadband.com/broadband/monitoring/...
(will be NO DATA until it starts but by the morning you'll see what I mean).

Thanks! That would be what I am looking for. [never mind no data]

Should have plenty of data now.
We are going to modify the BQM list which shows the previews to include each ping box separately removing the issue on the logged in screen udner my profile.

seb

Looks good now with both LON & EDI showing on the front screen.

I have three running and six traces are there and visible together.

In reply to a post by MHC:

Looks good now with both LON & EDI showing on the front screen.
I have three running and six traces are there and visible together.

Yep it was pushed live last night

If anyone here needs more than five monitors, feel free to ask.
Bonus tip - if you use the same monitor to track two origin servers/nodes/pingboxes (we need to decide what we call these) it only counts as one of your 5 (or whatever your limit may be set to if you've had more from us)


seb