Web Squad ISP

Status
Not open for further replies.
The reason you have to define the packet size on iperf is because iperf's default is sometimes wrong. Setting your MTU to something different on your router without reason is silly.
 
wingnut771 said:
That makes sense

MTU setting 1500, well that's what mines set to.

EDIT: That's trenched, don't know about air.
Click to expand...

Trenched uses active ethernet so 1500 is fine, ariel uses PPPoE so it must be smaller to account for the packet header.

Again, this is not something you need to touch.
 
wingnut771 said:
When he has 95% packet loss, I think it's worth a try.
Click to expand...

No, he does not have 95% packet loss. He needs to use the -l flag on iperf so iperf (which has nothing to do with his router) doesn't generate large packets.
 
Waylander said:
No, he does not have 95% packet loss. He needs to use the -l flag on iperf so iperf (which has nothing to do with his router) doesn't generate large packets.
Click to expand...
I understand, caused by using pppoe.

I don't have that problem because I'm 1500 by default.
 
Waylander said:
No, he does not have 95% packet loss. He needs to use the -l flag on iperf so iperf (which has nothing to do with his router) doesn't generate large packets.
Click to expand...
My situation is unique in that most users can run the iperf without the -l value and the net results are almost identical. When I run the iperf test without the -l value I get a false reading. What's different with my setup? I suspect it is a setting on the ONT. Have suspected it all along. If I run the iperf test connected directly to the ONT I can replicate the anomaly.

There is a history on my line going back almost a year but it came to a head in the last 3-4 months. The net result, on the 23rd November Vumatel swapped out my ONT and my 40% packet loss (reason for the swap out) went to 95% packet loss but on every other parameter performance improved significantly suggesting swapping the ONT was correct and the 95% reading was false.

For the last 3 months I been looking for an answer to the iperf 95% anomaly and tonight is the closest I've gotten to one.
 
Waylander said:
Your router should automatically configure MTU. Don't mess with it unless you have a reason to.
Click to expand...

Agreed, your router should always pick up the correct MTU. Active Ethernet links will always default to 1500. PPPoE connections will always learn 1480 from the PPPoE server. If @sand_man is getting 1492, I'd suggest he forces this to 1480 to account for packet headers.
 
sand_man said:
My situation is unique in that most users can run the iperf without the -l value and the net results are almost identical. When I run the iperf test without the -l value I get a false reading. What's different with my setup? I suspect it is a setting on the ONT. Have suspected it all along. If I run the iperf test connected directly to the ONT I can replicate the anomaly.

There is a history on my line going back almost a year but it came to a head in the last 3-4 months. The net result, on the 23rd November Vumatel swapped out my ONT and my 40% packet loss (reason for the swap out) went to 95% packet loss but on every other parameter performance improved significantly suggesting swapping the ONT was correct and the 95% reading was false.

For the last 3 months I been looking for an answer to the iperf 95% anomaly and tonight is the closest I've gotten to one.
Click to expand...

That 1492 MTU is what's worrying me. https://www.speedguide.net/analyzer.php and let me know what you're getting there.

PPPoE over Vuma is only capable of 1480 as the ethernet port is limited to 1500. If your computer believed this to be 1492, then that will have influenced your tests adversely as the server learns this from you.
 
It would be very strange if it affected anything since iperf will still default above his router's (now lower) MTU and fragment.
 
Waylander said:
@sand_man

Then change your MTU to 1480, and run iperf again (without the -l flag) and see if that resolves it.
Click to expand...
But hang on, MTU in the router settings correct? I can replicate this behavior connected direct to the ONT and also by running the iperf test on different machines!! So does that not rule out the router?
 
sand_man said:
But hang on, MTU in the router settings correct? I can replicate this behavior connected direct to the ONT and also by running the iperf test on different machines!! So does that not rule out the router?
Click to expand...

Yip, on router.

Which network and ISP are you on...?
 
sand_man said:
But hang on, MTU in the router settings correct? I can replicate this behavior connected direct to the ONT and also by running the iperf test on different machines!! So does that not rule out the router?
Click to expand...

Try drop your MTU on your PPPoE settings to 1460 and test without the -l flag. Rare to have to take it this low; but may indicate that the MTU on the ONT is wrong.
 
I am still 100% convinced it is iperf running a very high default buffer.
 
sand_man said:
But hang on, MTU in the router settings correct? I can replicate this behavior connected direct to the ONT and also by running the iperf test on different machines!! So does that not rule out the router?
Click to expand...

Not necessarily. We're trying to figure out if your SP is sending you the wrong MTU (unlikely because it's been two ISPs) or your ONT is problematic (In this case both you computer connected directly and your router will experience the same issue). If the ONT has a different MTU on the ethernet interface (ie <1500 MTU), PPPoE will send you 1480 while it's not supported by your link (we can eliminate this by setting a specific MTU, eg 1460).
 
Status
Not open for further replies.
Back
Top
Sign up to the MyBroadband newsletter
X