Peak time latency spikes
The more thinly you spread your problem the harder it is for PN to help.
Try to keep things in one thread.
Try to keep things in one thread.
Quote from: AndyH Yeah I think that sounds right. At busy peak periods, the gateway won't respond to pings in a traceroute.
Hmmm... On the other hand, 550ms does seem a long response time during a lower traffic period! My gateway seem better behaved:
Quote --- 195.166.128.193 ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.198/10.355/36.597/6.278 ms
Maybe Kelly's boiling up a cup of coffee on your gateway
No Graph as set up a different router to see if any difference look at it sooo far no good
Quote from: Anotherone But would I be correct in assuming that the following is the next best thing to TBB monitor, but staying within the Plusnet network?
You are using a debugging mode - and checking IP 87.112.xxx.xxx
Not sure. What is it?
Quote from: Bright
Quote from: rja traceroute doesn't use pings. It's sending a series of UDP datagrams...
Indeed, and traceroute shows significant variability in response time, similar to the pings (that I was referring to from earlier messages in the thread). Both seem to have very low priority (as would be expected), but rather more variability than you might expect when not under high load.
This is probably just a red herring, but curious why this should be...
It's my understanding that when you have to send a message to a routing device - rather than through it - that this is handled higher up the interface stack and so involves more work. So, getting a reply from hop 3 might take longer than hop 4 which logically makes no sense! So, arguably you might just be seeing the effect of different hardware - perhaps the first hop is able to context switch less efficiently than the second. Just a theory.
I'm not sure where the priority comes in though. If something is prioritising traffic then that suggests there is a store-and-forward going on somewhere. That would be an "interesting" thing to build given the amounts of traffic that PlusNet have to shift! My understandung of the "priority" of ICMP data was that a link could choose to drop it if heavily loaded. I could easily be wrong though.
Quote from: rja It's my understanding that when you have to send a message to a routing device - rather than through it - that this is handled higher up the interface stack and so involves more work. So, getting a reply from hop 3 might take longer than hop 4 which logically makes no sense! So, arguably you might just be seeing the effect of different hardware - perhaps the first hop is able to context switch less efficiently than the second. Just a theory.
I'm not sure where the priority comes in though...
Sorry, my fault for not being clear (or correct!) in my terminology. I meant the priority of the task/process handling responses to ICMP packets in the router, compared to the processes (or just hardware/firmware) handling normal routing and other packet handling functions. I think we're talking about the same thing, and I agree with your theory
I guess the capacity/loading of each node would also lead to such "illogical" results.I think I was just rather surprised to see response times ranging up to 550ms on AndyH's gateway. And with traceroute using UDP packets I get much longer response times from the gateway than subsequent nodes currently.
Quote from: rja If something is prioritising traffic then that suggests there is a store-and-forward going on somewhere. That would be an "interesting" thing to build given the amounts of traffic that PlusNet have to shift!
I think just DiffServ QoS tagging of traffic using the Arbor E100 platform. That does the DPI for traffic management and the different traffic class queues. May be wrong there, but I got the impression that's how it all works. Hopefully someone else can put me right if I've got that wrong!