Web sQuad ISP - Feedback Thread #2

Great, in addition to all the other problems, it looks like the Vumatel batteries have shat the bed lmao - when it rains, it pours, apparently...
 
DarkSt0rm said:
Great, in addition to all the other problems, it looks like the Vumatel batteries have shat the bed lmao - when it rains, it pours, apparently...
Click to expand...
Morning, I believe that vuma was at your place yesterday complaining about the SFP we sent you last year? Will get the guys just to confirm light levels quickly. And the power issue is just a cherry on top - these are generally resolved very quickly by Vuma though.
 
websquadza said:
Morning, we made a few updates again this am. Let me know if you see an improvement?
Click to expand...
Thanks, there's a big improvement since it's much less frequent but still there.
Packet loss on hop #3 has just been steady rising since the test started, and is still rising now.
Really grateful for the support i've been getting.
Screenshot 2024-02-07 101710.png

Edit: The pingplotter doesn't tell the whole story, i still get very frequent packet loss in Valorant and some when I make use of GeForce Now. Seems like if 50% of my line is used (For GeForce Now) then everything gets 10x worse.
Screenshot 2024-02-07 104050.pngScreenshot 2024-02-07 103235.png
 
Last edited:
websquadza said:
Morning, I believe that vuma was at your place yesterday complaining about the SFP we sent you last year? Will get the guys just to confirm light levels quickly. And the power issue is just a cherry on top - these are generally resolved very quickly by Vuma though.
Click to expand...
Yeah. Everything is FUBAR this morning :'( CPE FX Flashing blue as well lol.
 

Attachments

  • 20240207_104503.jpg
    20240207_104503.jpg
    320.8 KB · Views: 11
Also experiencing issues today, connection seems to have gone flakey.

I suspect Vumatel are doing some unscheduled maintenance

Screenshot 2024-02-07 at 15.10.33.png

Super frustrating as my tunnel to an rds db keeps timing out.

Edit == Ticket #038836
 
Last edited:
tm458 said:
Thanks, there's a big improvement since it's much less frequent but still there.
Packet loss on hop #3 has just been steady rising since the test started, and is still rising now.
Really grateful for the support i've been getting.
View attachment 1657770

Edit: The pingplotter doesn't tell the whole story, i still get very frequent packet loss in Valorant and some when I make use of GeForce Now. Seems like if 50% of my line is used (For GeForce Now) then everything gets 10x worse.
View attachment 1657788View attachment 1657790
Click to expand...
Howdy, hop 3 is set to only allow a certain number of ICMPs (Rate limited). However we are trying to see why the losses occur onward. Interesting you mention load related issues, this is a sign of queue issues. So we've asked Vuma to re-provision here. It's an issue we've seen with GPON services in the past. I see the team is keeping you updated.
 
@websquadza is there an issue on Openweb (Randburg)?
Been having speed issues for days,had to drop the MTU significantly
1708070427498.png
 
PsyWulf said:
@websquadza is there an issue on Openweb (Randburg)?
Been having speed issues for days,had to drop the MTU significantly
View attachment 1662339
Click to expand...
Openweb? I'm assuming you mean Openserve?
What are you seeing at 1454 bytes? Windows includes a 38 byte header in the TCP stack, whereas linux/unix/mac adds the 38 bytes on top. On a Eth line, you'll get 1472 max on a 1500 byte. The PPPOE should either establish at 1480 or 1492 depending on your router, so in windows you'll only see 1442 or 1454 respectively.

What router are you using?
 
websquadza said:
Openweb? I'm assuming you mean Openserve?
What are you seeing at 1454 bytes? Windows includes a 38 byte header in the TCP stack, whereas linux/unix/mac adds the 38 bytes on top. On a Eth line, you'll get 1472 max on a 1500 byte. The PPPOE should either establish at 1480 or 1492 depending on your router, so in windows you'll only see 1442 or 1454 respectively.

What router are you using?
Click to expand...
Sorry yes Openserve!

I had to Clamp to 1468 or net was practically dead (Mikrotik)
1708080192988.png

(I misremembered the overhead as 28 though so 1440 + 28 = 1468 but auto MTU killed the net speed)
 
Last edited:
PsyWulf said:
Sorry yes Openserve!

I had to Clamp to 1468 or net was practically dead (Mikrotik)
View attachment 1662447

(I misremembered the overhead as 28 though so 1440 + 28 = 1468 but auto MTU killed the net speed)
Click to expand...
Apologies for the delayed response on this one. I've tested a number of endpoints and am able to get a full 1492 (1500 - 8 byte pppoe header), including an endpoint in Randburg. Please can you log a ticket so we can track this issue?
 
websquadza said:
Apologies for the delayed response on this one. I've tested a number of endpoints and am able to get a full 1492 (1500 - 8 byte pppoe header), including an endpoint in Randburg. Please can you log a ticket so we can track this issue?
Click to expand...
No worries,been stable on the clamped lower MTU so not urgent
Will revert and log if it's still a problem!
 
websquadza said:
Apologies for the delayed response on this one. I've tested a number of endpoints and am able to get a full 1492 (1500 - 8 byte pppoe header), including an endpoint in Randburg. Please can you log a ticket so we can track this issue?
Click to expand...
Ticket logged,had to drop the MTU by another 20 today
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X