Xilo recommended MTU...

Hi,

I got my order confirmation through from Xilo this morning and everything is as expected. Something caught my eye though, in that the recommend I set the modem up with an MTU of 1432. Whenever I've messed around with MTU in the past, with a view to maximising performance, I've never noted any difference from changing it from its usual default of 1492. My connection has always allowed the maximum transmission without loss/ failure to send/ receive.

I guess I'm intrigued as to the rationale behind Xilo's recommendation. So have any of you other Xilo users changed this? And if so, have you noted any differences in performance when using a more 'usual' setting of 1492?

Cheers,

Paul

I was doubtful that 1432 was going to actually work when I switched, and as I suspected it broke all HTTPS sites, google, banking etc. so I went back to 1492.

I've always run at 1432 without any issue.
Think when I did some testing ages ago that 1492 didn't cause any packet fragmentation so not sure why they recommend 1432?

1432 is considered a safe value... but shouldn't break any sites as per a follow post has indicated (I suspect other issues there as we've never seen such thing happen before).

1492 on some TTB circuits just does not work due to the TTB network as a whole and the template sent is one for all (currently).

Matt

Pinging [173.194.41.112] with 1500 bytes -> ..fragmented
Pinging [173.194.41.112] with 750 bytes ->bytes=750 time=36ms TTL=58
Pinging [173.194.41.112] with 1125 bytes ->bytes=1125 time=39ms TTL=58
Pinging [173.194.41.112] with 1312 bytes ->bytes=1312 time=41ms TTL=58
Pinging [173.194.41.112] with 1406 bytes ->bytes=1406 time=41ms TTL=58
Pinging [173.194.41.112] with 1453 bytes ->bytes=1453 time=43ms TTL=58
Pinging [173.194.41.112] with 1476 bytes -> ..fragmented
Pinging [173.194.41.112] with 1464 bytes ->bytes=1464 time=42ms TTL=58
Pinging [173.194.41.112] with 1470 bytes ->bytes=1470 time=42ms TTL=58
Pinging [173.194.41.112] with 1473 bytes -> ..fragmented
Pinging [173.194.41.112] with 1471 bytes ->bytes=1471 time=43ms TTL=58
Pinging [173.194.41.112] with 1472 bytes ->bytes=1472 time=43ms TTL=58
The largest possible non-fragmented packet is 1472 (1500 - 28 ICMP & IP headers).
You can set your MTU to 1500

On my uno TTB connection

My router is set to 1458 and always has been (changed isp about 3 times).

I read the email from Xilo to mean that 1492 was the preferred MTU?

Mine says "MTU: 1432 or 1492 (Recommended)"

In reply to a post by parsimony:

I read the email from Xilo to mean that 1492 was the preferred MTU?

Mine says "MTU: 1432 or 1492 (Recommended)"

As does mine also.

1492 is a pretty standard MTU setting so I'll continue to set mine as such once I go live on Wednesday. I know what Xilo say about 1432 but I've certainly never heard anyone other than them quote that figure as a safe setting. Hey-ho.

Went live with Xilo yesterday at 1492 and everything seems just fine.

Talk Talk do too

Matt

OK, cheers Matt.

I setup @ 1492 when I changed to Xilo the other week and no problems so far. But if I do then 1432 it is.

Looks like the TTB maintenance work last night went badly: messing about with MTU etc. Did they have to do a roll back in the end?

It must have been very frustrating for you. It's back to normal now for me now but after midnight last night the ppp link was dropping frequently and when it was up the only site I could open was Goggle (but my router MTU is set at 1500.)

In a nutshell, yes.

Most people who were using 1432 as the MTU recommended didn't suffer. A handful had problems with that.

TTB reverted the config and downgraded. All re-appeared once it rebooted. Awaiting post-mortem now.

Slightly frustrated would be a massive understatement!

Matt

Always a good idea to have a 3g dongle at hand when on a TTB connection these days, especially for night birds like me. 99.9% of the time uno "pro" is an excellent service though

Earlier issues all resolved. This appears to have just been a bad upgrade.

Potentially a software issue that was not known about and we'll soon find out if they raise to TAC.

Matt

In reply to a post by uno:

Potentially a software issue that was not known about and we'll soon find out if they raise to TAC.

I had no service to speak of from around midnight to just before midday. Email was timing out (managed to get a couple of very short messages in and out) but web was completely unusable. CHAP died completely for around 30m toward the end.

This would have been seen - full run down on our status page.

Matt