Sadly I expected it...

[#1]

mrsystems,
Thanks for the information on the Draytek. Previously we used a Billion Biguard 30, but swapped that to the Draytek a while ago so I'm getting used to the differences. At the moment we've kept QOS out of the equation but will at a later stage after investigating the current problem  look more closely at QOS.  I'm waiting for a break in my schedule to run some of the tests suggested by Adam. We tend to use Ethereal rather than wireshark, but I understand the PN support are more used to looking at wireshark results so we'll be using that to find out what is happening at the protocol level.
As part of the investigation, once advised by PN that we have the correct Business Options 3, we've replaced (temporarily) the entire UTP CAT 5 cable and removed any intermediate devices along the pathway. It turns out a  Netgear  dumb hub may be responsible for data loss and causing network collisions/retransmits. Hubs work at Level 1 of the network layer (hardware) and although their functionality is limited can detect ethernet collisions and issue a "jam" packet to all attached devices. It is quite an old device and maybe dying. When we remove the hub,replaced with a unmanaged switch or direct connection, we get a much better PN video streaming performance.  The hub is between the PN Thomson ADSL router and our external firewall.
However when we use the same hub, in the same circuit position, between the Demon Internet ADSL router and our firewall there is no noticeable degradation in the Demon ADSL service. The Demon service is about 50% faster overall than the PN. So at present we are a bit puzzled.
A couple of months ago after a thunderstorm (before Plusnet) we lost several devices. There was no direct lightning strike, but perhaps an induced surge. The hub was part of that string but apparently undamaged and still working, but maybe there's some lesser damage or it may be unconnected.
We've now ordered an additional small managed switch to replace the hub and to allow us to use mirrored ports on the switch  to attach a protocol analyser. We'll update on here as things progress.
Alaric

[#2]

Quote from: AlaricAdair

mrsystems,

LOL Mr Systems, I like that
Feel free to let me know the model number of your Draytek.  I'm a reseller for Draytek but quite selective about the models I resell.  Draytek generally give you a lot of features for your money and are pretty solid.  The documentation is not brilliant and some features are mutually exclusive, but I have yet to find a sub £500 router where that's not the case.  It's a good idea to keep the firmware updated but just be aware that Draytek have very occasionally issued a dog of a firmware release.
Wireshark forked from Ethereal when they stopped developing Ethereal.  They are basically the same package but Wireshark has a lot more features.
You are right about hubs being Layer 1, they work entirely electrically. Hubs are mainly passive though, they don't issue jam packets or packets of any kind; packets don't exist below Layer 2.  When two stations transmit at once, both signals get mashed, which prevents both stations from receiving their own signal.  Both stations then wait a random interval before retransmitting.  The long name is Carrier Sense Multiple Access Detection (CSMACD) but it's colloquially known as the cocktail party protocol.  If you are chatting in a group at a party and two people talk over each other, they both back off, wait a random time and whoever starts talking first get's to have their say.  That's pretty much how Ethernet works at the electrical level.
Which is all very interesting but is not solving your problem
I can't quite entirely visualise your setup.  PN to Thomson to Hub, got that.  What is the 'external firewall,'  the Draytek or something else?  Does the Draytek have an ADSL modem and Ethernet WAN port, with the ADSL connected to Demon?  It probably doesn't matter but would be nice to know.
The lightening strike may well have spiked the mains and damaged the transceivers in the hub.  I would expect the fault to follow the hub port  though.  Unless it's an obtuse signal mismatch, where the damage causes the transceivers to work near, but not within, tolerance, which results in some interfaces working and others not.  Network kit and mains spikes don't mix.  You might want to invest in some surge protectors.  
However, it sounds suspiciously like you might have a duplex and/or flow control mismatch going on.  Hubs only work with half-duplex interfaces and flow control on all connected interfaces must be set the same.   Otherwise you get high collision rates at minmal bandwidth capacity, which seems to be the problem you have.
You can check the Draytek's Ethernet settings by logging in with Telnet or SSH and typing the command,  port status
No idea how you would check the Thomson.
There were some proprietary full duplex hubs around but they were expensive and rarely worked in a mixed vendor environment.   It's such a long time since I had to do anything with a hub I can't remember if they can even support Auto-configuration - I just remember Autoconfig often caused problems and interfaces had to be configured manually.
Getting shot of the hub is the best plan though.  Switches are too cheap these days to mess around fault finding these sort of issues.

[#3]

Quote from: _Adam_Walker_

Thanks for an informative post there, this is what the community is all about.

Why thank you.  Maybe you could inform me how we might start a dialogue toward PN dispensing with punitive traffic shaping on business products 
Sorry Adam but punitive shaping on Option 3 is the one thing about PN that I intensely dislike.  I am happy to justify that statement.

[#4]

Hi mssystems,
This is what it was:
Plusnet ADSL          BT line ===> Thomson 585 (PN supplied) ===> Hub ===> Draytek (Vigor 2920 WAN1)
Demon ADSL          BT line ===>  Thomson 546 (demon supplied) ===> Draytek (Vigor 2920 WAN2)
The hub is now history, replaced by a borrowed switch (hopefully today it will be a Procurve 1700-8)
This morning, after rebooting the PN Thomson router yesterday afternoon, I found the Error seconds (local/remote) at something like 300,000 / 4 on the PN ADSL router/modem So we sent the boy to follow the cable from the firewall through out to the street where the phone cable enters the building. This is old wiring probably in parts over 35 years old installed during the days of bakelite phone  handsets. The boy found an old phone extension cable hardwired into the old BT junction box just inside the building . There's nothing attached to extension cable,so a few quick snips and it has been removed from the equation.  Presently there are no error seconds showing despite heavy testing.
From the street to the building is new BT cable installed last year after the great bubbling cable incident. A careless decorator with a blowtorch had cooked the old cable outside and it started bubbling on rainy days, but that was all sorted by BT voice engineers well before we used it for PN ADSL.
We're presently waiting for the courier to deliver the Procurve switch so we can use it's mirrored port in conjunction with Wireshark to see what is happening between the PN ADSL router and our Draytek firewall. At the moment streaming video is ok on the PN Business option 3.
Alaric

[#5]

Okay PlusNet I'm sorry. I should not have jumped to the conclusion that you were managing the video streaming on Business Option 3. After our joint investigation we believe we've found the cause of the jerky video performance.
I mentioned in an earlier post we'd found some ancient phone extension wiring (probably been there for 30 years or more) on the BT side of the PlusNet modem. The wiring was well hidden ans wasn't even correctly configured for an extension. No equipment was connected to the extension so we snipped it, conductor by conduction, at the BT junction box. We've never previously used this phone line for ADSL, so the higher frequencies involved with ADSL  probably created some wonderful reflected waveforms on the extension.
Since then the number of Error Seconds recorded on the PN Thomson 858 have dropped from the hundred thousands to one in a 24 hour period. The effective line speed has gone from 4.2M to 6.2M Streamed  video is good, but not quite up to HD quality according to the BBC iPlayer speed test.
So if any one is to blame it is the ghosts of the previous occupants!
We followed a bit of a wild goose chase with the Hub, between the PN ADSL Modem/Router and our internal firewall device, in tracking down the error. It works ok in the circuit now. However to be sure it doesn't create any future problems it has been removed and replaced by an HP Procurve 1007-8 switch. At £53 for a managed switch it is pretty good value. We originally had the hub in circuit so we could monitor the IP traffic when necessary. The mirror ports feature of the 1007 Switch will allow us to do that on the new device.  We believe the simple flow control on the hub couldn't keep up with all of the retransmit traffic created by the forgotten extension cable.
The solution boiled down to the typical process of elimination, isolating each sector of the service until the cause was isolated.  If we'd not done the physical inspection process ourselves it would probably have required an alert BT engineer to carefully inspect our wiring. Several previous ones have not commented on the extension which was strictly speaking illegally wired, though not by us.
Alaric