Fiber optic vs VDSL2 connexion

hi everybody optical fiber 1/go

my brother has a 1gb/600 fiber optic no matter what i do his connection is slow, i tried qosify and sqm with nftables rules

but nothing works,

I lowered his connection to 400/400 or 350 /350 since the rt3200 doesn't do more sqm with

do you think it has too good a connection for the game between ""

his ping is on waveform of 10ms

what are the advantages of having a fiber except a speed because I have the impression my feeling is that the vdsl2 is the best currently to play the games I make you share a recent gameplay, my character is fluid, my brother and his fiber has the character three times slower

I think you can still get a bit more speed from the rt3200, by switching from cake to fq-codel. But for a full gigabit SQM, you would need an x86 box.

Regarding VDSL, please realize that it is terminated in an ISP box 100-200 meters from your home. In that box, ISPs typically install their own access concentrator, which has VDSL lines on one end and fiber on the other. So the latency advantage may well be imaginary.

3 Likes

ok do you think it's because I reduce his bandwidth so much that this happens?

there is no real difference between his fiber without router and fiber with router



edit these are the 3 boxs of the provider they use i have the livebox 4 and my brother with his fiber the livebox 5 i see that the livebox 5 has a minimal processor compared to the others

first 1 livebox 6
seconde livebox5
three livebox 4

Based on your first waveform screenshot, I would say that the problem is not bufferbloat. It looks more like packet loss with some retransmissions, because they all are concentrated around 140 ms.

Here are my results, over 5 GHz WiFi, without SQM, on Globe Philippines (which is GPON fiber):

As you can see, they don't give me an A+, but still say that this connection can be used for low-latency gaming.

ok i see

the 4 5 dots grouped on the right means that a group of packages arriving is late? that's right

Yes. However, as they use TCP, these late packets might well be retransmissions due to bad-quality optical cable connections, because that's how TCP hides packet loss. Try reseating the fiber where it enters the modem.

1 Like

ok thanks for help i will try

The waveform test tries the 'impossible' (veridical delay measurements from within the browser*) and does admirably, I would not take each and every sample and deeply interpret it.

About your brother, what link technology PON or AON does he have, and what speedgrade (say GPON or XGSPON)?

*) Especially Safari is prone to produce/show delayed samples purely within the browser, firefox and chrome seem to be better in that regard, not sure however whether they are completely free of that issue.

hello the test was made from chrome google,

in France we use most of the gpon technology

ah my opinion I should think that the livebox 5 is not very powerful compared to the other liveboxes considering the processor

Better than Safari, but still a browser test.

As far as I know soime ISPs use GPON other already switched to XGS-PON, do you know which your brother uses?

Also ant idea about his ISPs segment size? Often ISPs will at most put either 32, 64 or even 128 users into a shared PON segment.

No idea on this, as it is hard to figure this out for someone as bad in french as me. I apologize for this, I should have payed more attention in school.

1 Like

hello, you found a solution for the fiber, it's the same for me

Good evening! @moeller0

Based on the boxes from the pictures, they use gpon, but is there is really a big difference between gpon and xgspon except few ms?

These boxes come with their qos which you cant tune, all under the hood

GPON has a segment capacity of ~2.4/1.2Gbps, XGSPON a gross capacity of 10/10 or if FEC is used (so lokely always) ~8.6/8.6 Gbps. So I would say the biggest difference is throughput :wink:

2 Likes

hi moeller sorry for my absence yes the fiber and openwrt is fire i must admit my game is nervous thanks again

i just need now found a server near of my home for my game and i have a found a solution maybe :slight_smile:

hi @moeller i would like my packets of game udp be 3074

i has make tcpdump can you explain if my packet on cs4 ? maybe 0x80 tos i think after my search

thanks

my game at the moment is very very good

14:49:53.812528 IP (tos 0x80, ttl 52, id 22735, offset 0, flags [DF], proto UDP (17), length 486)
    217.69.14.168.43810 > 192.168.2.160.3074: UDP, length 458
14:49:53.813060 IP (tos 0x20, ttl 56, id 10589, offset 0, flags [DF], proto TCP (6), length 52)
    23.56.109.58.443 > 192.168.2.160.64971: Flags [.], cksum 0xf19b (correct), ack 8417, win 1210, options [nop,nop,TS val 2268380442 ecr 3251354314], length 0
14:49:53.813196 IP (tos 0x20, ttl 52, id 22734, offset 0, flags [DF], proto UDP (17), length 1316)
    217.69.14.168.43810 > 192.168.2.160.3074: UDP, length 1288
14:49:53.821186 IP (tos 0x0, ttl 64, id 57963, offset 0, flags [none], proto UDP (17), length 142)
    192.168.2.160.3074 > 217.69.14.168.43810: UDP, length 114
14:49:53.838174 IP (tos 0x0, ttl 64, id 15051, offset 0, flags [none], proto UDP (17), length 141)
    192.168.2.160.3074 > 217.69.14.168.43810: UDP, length 113
14:49:53.855080 IP (tos 0x0, ttl 64, id 41361, offset 0, flags [none], proto UDP (17), length 141)
    192.168.2.160.3074 > 217.69.14.168.43810: UDP, length 113
14:49:53.858654 IP (tos 0x20, ttl 52, id 22745, offset 0, flags [DF], proto UDP (17), length 1316)
    217.69.14.168.43810 > 192.168.2.160.3074: UDP, length 1288
14:49:53.860002 IP (tos 0x80, ttl 52, id 22747, offset 0, flags [DF], proto UDP (17), length 595)

    217.69.14.168.43810 > 192.168.2.160.3074: UDP, length 567
14:49:53.860638 IP (tos 0x20, ttl 52, id 22746, offset 0, flags [DF], proto UDP (17), length 1316)
    217.69.14.168.43810 > 192.168.2.160.3074: UDP, length 1288
14:49:53.864514 IP (tos 0x0, ttl 64, id 54443, offset 0, flags [none], proto UDP (17), length 218)
    192.168.2.160.3074 > 217.69.14.168.43810: UDP, length 190
14:49:53.870160 IP (tos 0x0, ttl 64, id 199, offset 0, flags [none], proto UDP (17), length 139)
    192.168.2.160.3074 > 217.69.14.168.43810: UDP, length 111
14:49:53.887162 IP (tos 0x0, ttl 64, id 42802, offset 0, flags [none], proto UDP (17), length 141)
    192.168.2.160.3074 > 217.69.14.168.43810: UDP, length 113
14:49:53.904303 IP (tos 0x0, ttl 64, id 21053, offset 0, flags [none], proto UDP (17), length 140)
    192.168.2.160.3074 > 217.69.14.168.43810: UDP, length 112
14:49:53.907680 IP (tos 0x20, ttl 52, id 22753, offset 0, flags [DF], proto UDP (17), length 1316)
    217.69.14.168.43810 > 192.168.2.160.3074: UDP, length 1288
14:49:53.909027 IP (tos 0x80, ttl 52, id 22755, offset 0, flags [DF], proto UDP (17), length 479)
    217.69.14.168.43810 > 192.168.2.160.3074: UDP, length 451
14:49:53.909541 IP (tos 0x20, ttl 52, id 22754, offset 0, flags [DF], proto UDP (17), length 1316)
    217.69.14.168.43810 > 192.168.2.160.3074: UDP, length 1288
14:49:53.911743 IP (tos 0x0, ttl 64, id 27156, offset 0, flags [none], proto UDP (17), length 141)
    192.168.2.160.3074 > 217.69.14.168.43810: UDP, length 113
14:49:53.923736 IP (tos 0x0, ttl 64, id 7162, offset 0, flags [none], proto UDP (17), length 224)
    192.168.2.160.3074 > 217.69.14.168.43810: UDP, length 196
14:49:53.929206 IP (tos 0x0, ttl 64, id 26887, offset 0, flags [none], proto UDP (17), length 139)
    192.168.2.160.3074 > 217.69.14.168.43810: UDP, length 111


Yepp, tos 0x80 is CS4 (see here for reference)

but later you see:

0x20 which is CS1, this is clearly not ideal. My wild guess is that you have maybe a packet size based rule the treats the smaller (458) byte packet differently from the later larger packet (1288).
If this is true the question is, will the game tolerate potential re-ordering between small and large packets and are large port 3074 packets frequent enough to merit special deprioritisation*.

In the reverse direction your packets appear to be marked 0x00 or CS0, but I assume this is because these are captured before your DSCP re-marking code got hold of the packet.

*) Keep in mind that my approach would always be to try to get away with the absolute minimal set of marking rules, elaborate QoS hierarchies can grow complex enough for me not to be able to fully predict them; knowing my limitations I would aim at keeping the rules simple enough for me to understand :wink:

1 Like