Slow "Updating" in Minkata.71

[Mac_Fife]

Yes, you did imply that it was a step-change, although Hoikas' observation might still have validity - there could be some "tipping point" that get's reached once traffic volume reaches a certain level that forces a change in route, and since the routes to different servers may have little in common then you may not see the same effect happen on Ghen or elsewhere.

Yup! Is there some way of forcing the route that is taken - eg always go via Aberdeen? Oh, and before I capture loads of irrelevant stuff, did the wireshark guide get updated?

You can't really force a route - part of the principle of the internet is that is determines what seems likely to be the best route to use. And no the Wireshark guide didn't get updated, but I found that the current version of Wireshark doesn't seem to allow you to limit the amount of data grabbed with each packet .

[Treehugger]

I'm well off-topic here but - Happy Birthday, Mac!

[janaba]

Haha ... great, Treehugger, at almost the same time I did it on the MOUL forums lol,
going off-topic with this in the MQO thread, but I've added a happy farewell for it and
so I was on-topic again hehe ... Again, Happy B-Day, Mac ...

Right now I'm even more off-topic than you are lol ...

[Treehugger]

Haha ... great, Treehugger, at almost the same time I did it on the MOUL forums lol,
going off-topic with this in the MQO thread, but I've added a happy farewell for it and
so I was on-topic again hehe ... Again, Happy B-Day, Mac ...

Right now I'm even more off-topic than you are lol ...

oh, a very clever way to get back on topic in the MQO thread, janaba! OK, I'll get back on topic again - I've just given Mac a birthday present of a new load of wireshark capture data! (What else to give the man who has everything?)

[semplerfi]

(What else to give the man who has everything?)

The rest of his life off with pay... colon pee...

[Mac_Fife]

OK, so now we've got 3 dropped packets and 1 out of order packet - that's much more like "normal behaviour" - Now the trick is to try to figure out why?

[Treehugger]

Going off topic for a moment - Happy New Year everyone! Back on topic - now I'm back home, the updating is slow again - grr. To test Hoikas' theory, I'll need to wait for the January sales to end, I suppose. (Assuming this is the sort of seasonal traffic you had in mind, Hoikas .)

Shame I can't specify the route to get to the server - I was using as an analogy the Transport for London travel planner http://journeyplanner.tfl.gov.uk/user/X ... anguage=en - it'll tell you the way it recommends you should get from A-B; but if you specify you want to go via C, because you're enough of a transport geek to know it's a better route, it'll recalculate it for you .

[Mac_Fife]

The problem is that in a TCP/IP network each routing "node" can only specify the address of the next adjacent node, and doesn't allow you to require that routing goes via some specified downstream node. So, for example, your home router will look at the destination addresses and say "that is a local IP, so I'll send that to the local machine with that IP address" or "that is a remote IP, so I'll send it to the ISP's gateway IP address".

Given that you get to the MOULa and Ghen servers without the slowdown you see on Minkata, and given that all three are based in the US, it seems likely that the problem lies at some point after your connection makes landfall in the US. It's often the case that for any given ISP, they will use one preferred link between UK and US and then fan out depending on the final destination. What we might need to try is comparing the routes you get to each of the three servers (using tracetcp) and see what's different.

[Hoikas]

For reference, the Gehn server was based in Ashville, NC. After the emergency migration, it is now based in San Jose, CA.

[Treehugger]

thanks; happy to try new traces: I'll need the MOULa and Gehn equivalents of the Command prompt you gave me, Mac.