Συζήτηση για MTU, MRU, MSS, clamping

**deniSun** · 29-09-23, 23:42

Νομίζω ότι το ασφαλέστερο είναι να ορίσουμε σε ether/vlan το max mtu που επιτρέπει η συσκευή
στην περίπτωσή μου 1592/1588
και στο mtu/mru της pppoe σύνδεσης τα 1500.

**x_undefined** · 29-09-23, 23:47

Αρχικό μήνυμα από deniSun

Δεν είναι λογικό αυτό που κάνει.

Το θέμα είναι ότι δεν βγάζει κάποιο άκυρο νούμερο να πεις ότι είναι ξεκάθαρα bug. Βγάζει 1492 που είναι πολύ ύποπτο. Εγώ που είμαι σε πάροχο χωρίς PPPoE και με 1500 MTU, δεν μου έχει βγάλει ποτέ 1492.

- - - Updated - - -

Αρχικό μήνυμα από macro

Ποιο ειναι το tracepath που λες? Για δωσε αυτο απο cmd..

Κώδικας:
ping www.yahoo.com -f -l 1500
Kαι μετα βαλε 1492 στην ιδια εντολη και δες αν απανταει

Αυτό δεν θα τρέξει ποτέ. Με 1500 MTU, το max packet size για ping (ICMP) είναι 1472, όχι 1500.

**deniSun** · 30-09-23, 00:01

Για δείτε κάτι άλλο:
pppoe client mtu/mru: 1500/1500
ether1 mtu: 1524
vlan mtu: 1520

Οι τιμές του pppoe client είναι σίγουρο ότι θα πρέπει να είναι 1500.
Στο vlan υπολογίζω (για ν4) 1492 + 8 + 20 = 1520
Το ehter της vlan θα είναι + 4 = 1524.

ή μήπως θα πρέπει να το πάμε με 1472 και να έχουμε 1500/1504 σε vlan/ether;

Σε όλες τα τεστ tracepath/speedguide παίρνω κανονικά 1500.

**dpap76** · 30-09-23, 00:17

Αρχικό μήνυμα από deniSun

Παρ όλα αυτά κάποιοι θεωρούν ότι για να πάρουν αυτό το "καθαρό" mtu 1500, πρέπει να δηλώσουν >=1520.

Απο αυτό που καταλαβαίνω εγώ πάντως, διαβάζοντας είτε το documentation της mikrotik είτε τα forums της με ποστς απο το 2005, 2012, 2016 που ο καθένας γράφει το κοντό και το μακρύ του και που μάλλον μας μπερδεύουν περισσότερο, καταλήγω οτι για κάποιο αψυχολόγητο λόγο, η MT αποφάσισε (εδώ και χρόνια) οτι ο pppoe header δεν είναι 8 bytes αλλά 20 (!). Δεν έχω ιδέα το σκεπτικό που το έκανε αυτό.

Για να πούμε όμως τα σύκα-σύκα και στην σκάφη-σκάφη, τα routerboards ποτε δεν λανσαρίστηκαν σαν CPE devices που θα αναλάβουν την broadband συνδεση με τον isp και το όποιο PPPoE client/server support που έχουν, το έχουν στο documentation τους στην κατηγορία "VPN"...

οπότε στους υπολογισμούς και τα αυτοματικά που κάνει αν θέλεις να πάρεις 1500 mtu στο pppoe πρέπει να βάλεις 1520. Εκεί καταλήγω οτι βγαίνει το νούμερο 1520 χωρίς ξαναλέω να έχω και μεγάλη εμπειρία από το routeros.

H documentation σελίδα της για το PPPoE πάντως οχι μόνο δεν λέει τίποτα για RFC4638 αλλά ακολουθεί πιστά το original PPPoE rfc που θέλει το mru/mtu να είναι 1492 bytes αλλά πάλι στην ίδια σελίδα, στα options του pppoe client βλέπουμε:

max-mru (integer; Default: 1460) Maximum Receive Unit
max-mtu (integer; Default: 1460) Maximum Transmission Unit

και για να δέσει το γλυκό, οταν παρακάτω δείχνει ενα example, εμφανίζεται ενα "auto" απο το πουθενά

Κώδικας:

[admin@MikroTik] > interface pppoe-client print
Flags: X - disabled, I - invalid, R - running
 0  R name="PPPoE-Out" max-mtu=auto max-mru=auto mrru=disabled interface=ether2 user="MT-User"
      password="StrongPass" profile=default keepalive-timeout=10 service-name="pppoeservice" ac-name=""
      add-default-route=no dial-on-demand=no use-peer-dns=no allow=pap,chap,mschap1,mschap2

... άλλα αντ' άλλων ή η ιδέα μου είναι ?

ωστόσο, όπως βλέπουμε στην πράξη από τον denis, μια χαρά μιλάει με 1500 με τον BRAS άρα (silently?) υποστηρίζει ο pppoe client το rfc 4638. είδα και debug output απο κάποιους που δείχνει οτι στέλνει/περνει/καταλαβαίνει τα ειδικά max-payload tags του 4638.

ενδιαφέρουσα πάντως και η παρακάτω σελίδα που δείχνει το max L2 mtu για κάθε hardware μοντέλο της: https://help.mikrotik.com/docs/displ...TU+in+RouterOS

**macro** · 30-09-23, 00:34

Εγω με αυτο που ηθελα να πω ειναι οτι αν το sg analyzer σου δειχνει 1492, οσο και να το βαλεις εσυ, στο τελος ο provider σε βγαζει με 1492 οποτε και αυτο πρεπει να βαλεις. Εγω που τωρα πια ειμαι με LTE, το chateau ηταν default 1500 αλλα εβγαινα με 1372, οπως νομιζω ολοι στη cosmote. Aπο τοτε που το δηλωσα 1372, ολα μου δουλευουν καλυτερα. Και ταχυτητα και η ταχυτητα που πιανει τη μεγιστη ταχυτητα, το browsing, αποκριση, ολα.

Αν κατεβασετε απο την SG το tcp optimizer, στη τελευταια καρτελα mtu/latency μπορεις να δεις με ποσο mtu βγαινεις κανοντας το τεστ

**dpap76** · 30-09-23, 01:29

Αρχικό μήνυμα από deniSun

Για δείτε κάτι άλλο:
pppoe client mtu/mru: 1500/1500
ether1 mtu: 1524
vlan mtu: 1520

Οι τιμές του pppoe client είναι σίγουρο ότι θα πρέπει να είναι 1500.
Στο vlan υπολογίζω (για ν4) 1492 + 8 + 20 = 1520
Το ehter της vlan θα είναι + 4 = 1524.

ή μήπως θα πρέπει να το πάμε με 1472 και να έχουμε 1500/1504 σε vlan/ether;

να διευκρινίσω κάτι που ίσως δεν έχει γίνει κατανοητό: το PPPoE όπως και το PPP είναι layer 2 πρωτόκολλο. Μιλάει με τον ACS/bras κατευθείαν στο mac address του στο data-link layer, κατασκευάζοντας frames που τα δίνει στον ethernet driver για αποστολή στο καλώδιο. Μιλάει απ' ευθείας με raw socket με τον ethernet driver να το πώ προγραμματιστικά (ή με τον vlan driver όταν έχουμε .1q vlans). Με ότι L3 MTU έχει γίνει set το interface είτε αυτό ειναι physical, είτε vlan, είναι παντελώς αδιάφορο, αυτό θα κατασκευάσει το frame που θέλει *με όσο frame payload* αυτό θέλει εφόσον -αφού προστεθούν και τα headers του ethernet- του επιτρέπει ο ethernet driver (= το hardware της κάρτας).

Αυτά στη θεωρία. Τώρα, αν έχουν προγραμματίσει έτσι το routeros ωστε να κάνουν set το mru/mtu που θα χρησιμοποιήσει ο ppp (o ppp! οχι o pppoe! o ppp είναι το virtual interface μας στον οποίον κάνουμε τελικά routing/forwarding IP πακέτα, το ping και όλα τα τεστ) βάση των MTU των interfaces που εμπλέκονται αυτό είναι άλλο καπέλο και μάλλον πατέντα της mikrotik.

Άρα denis, επειδή έχεις ΜΤ, καλώς ίσως κάνεις τις πράξεις που τελικό σκοπό έχουν να επηρεάσουν τα ppp mru/mtu αλλά κανονικά εμείς οι υπόλοιποι δεν θα έπρεπε να μπλέκουμε με αυτό και να ψάχνουμε τα L3 MTU των "απο κάτω" interfaces. Αρκεί μόνο η κάρτα δικτύου του CPE μας να είναι post-2010 και ο pppoe client του CPE μας να υποστηρίζει 4863 ωστε να ρουφιανεψει τον bras οτι μπορούμε να μιλήσουμε με λίγο μεγαλύτερα frames και αρα το L3 mtu του ppp interface να γίνει set στα 1500 bytes.

Spoiler:

- - - Updated - - -

Αρχικό μήνυμα από macro

Αν κατεβασετε απο την SG το tcp optimizer, στη τελευταια καρτελα mtu/latency μπορεις να δεις με ποσο mtu βγαινεις κανοντας το τεστ

προσοχή: ο tcp optimizer είναι για άλλες εποχές και αν τον τρέξουμε και κάνει apply τις προτάσεις του σε windows 11 pc θα τα κάνει όλα σαλάτα.
καντε το test δεν λεω (που το ίδιο τεστ γίνεται και με ping -f -l 1472) αλλά προσοχή στην χρήση του.

Για τα υπόλοιπα αν είμαστε με LTE, με 5G, με wifi κλπ δεν έχω άποψη. ο θεός και η ψυχή τους τι γίνεται στην ζούγκλα εκείνη

ναι, αν δείτε οτι δεν παίζετε με το στανταρντ mtu 1500 που παίζει ολο το Internet θα ήταν ίσως σώφρων να ρυθμίσετε κατάλληλα και το MSS (αφαιρούμε 20 40 bytes) -το γνωστό σε όλους mss clamping- ώστε όλα να γίνουν λίγο πιο snappy απο την εξοικονόμηση του cpu overhead που προκαλεί το fragmentation και να μην ταλαιπωρείτε τζάμπα το router και ο bras. Κάτι τέτοια μάλλον σκέφτηκε και η ΜΤ και βάζει μικρά mtu/mru και κάνει auto handling (Πώς? με ποια πατέντα της?) το MSS ωστε τελικά η εμπειρία χρήσης να είναι καλύτερη και να αποφεύγονται προβλήματα. Φυσικά μόνο για το TCP πρωτόκολλο.

- - - Updated - - -

Αρχικό μήνυμα από BlueChris

Ότι και να κάνω δλδ.. το ίδιο βγάζει από το PC μου σπίτι Windows 10 και από το κινητό.. αλλά παρεμβάλλονται από το pc μέχρι το internet μου πολλά

για να λυθεί η απορία σου πρέπει να βρείς ποιος router στο δρόμο αλλάζει το mtu

to tracepath για linux κάνει αυτή τη δουλειά εύκολα.

σε windows θα πρέπει να κάνεις traceroute (ωστε να δείς ποια hops εμπλέκονται στο path) και μετά για κάθε hop που θα δείς να εμφανίζεται ξεκίνα να το κανεις ping -f -l 1472 μέχρι κάποιο να σου πει fragmentation needed but DF is set. το προηγούμενο hop κάνει την μπινιά

Αν το path δεν αλλάζει και αν το icmp κυλάει ελέυθερα και δεν το κόβει κανενα στριμμένο firewall θα πρέπει να βρείς τον ένοχο.

**slalom** · 30-09-23, 01:46

Ασχολειστε με μια χαζομαρα

**x_undefined** · 30-09-23, 03:17

Αρχικό μήνυμα από dpap76

σε windows θα πρέπει να κάνεις traceroute (ωστε να δείς ποια hops εμπλέκονται στο path) και μετά για κάθε hop που θα δείς να εμφανίζεται ξεκίνα να το κανεις ping -f -l 1472 μέχρι κάποιο να σου πει fragmentation needed but DF is set. το προηγούμενο hop κάνει την μπινιά Αν το path δεν αλλάζει και αν το icmp κυλάει ελέυθερα και δεν το κόβει κανενα στριμμένο firewall θα πρέπει να βρείς τον ένοχο.

Υπάρχει και το mturoute που είναι αρκετά χρήσιμο για αυτό.

**deniSun** · 30-09-23, 08:17

Αρχικό μήνυμα από dpap76

H documentation σελίδα της για το PPPoE πάντως οχι μόνο δεν λέει τίποτα για RFC4638 αλλά ακολουθεί πιστά το original PPPoE rfc που θέλει το mru/mtu να είναι 1492 bytes αλλά πάλι στην ίδια σελίδα, στα options του pppoe client βλέπουμε:

max-mru (integer; Default: 1460) Maximum Receive Unit
max-mtu (integer; Default: 1460) Maximum Transmission Unit

Σε εποχή ros6.x δεν μπορούσες να βάλεις mtu >=1500.
Από μια έκδοση και μετά το πρόσθεσαν ως συμβατότητα με το RFC4638.
Το αναφέρουν και στα log (δεν έχω χρόνο να ψάξω για να σου πω από ποια έκδοση και μετά προστέθηκε)
αλλά υπάρχει και σε πολλές αναφορές χρηστών αυτή η αλλαγή.

Σχετικά με το auto... το ανέφερα από την πρώτη στιγμή.
Βάζοντας auto παίρνεις ότι σου προτείνει ο πάροχος.
Στην περίπτωση της cosmote σου δίνει 1492.

Αρχικό μήνυμα από dpap76

η MT αποφάσισε (εδώ και χρόνια) οτι ο pppoe header δεν είναι 8 bytes αλλά 20 (!).

Όχι. Δεν το βλέπω αυτό από κάπου.
Αν δεις στις αναφορές των χρηστών όλοι σχεδόν έχουν διαφορετικά Mtu από τους παρόχους και γι αυτό δίνουν και άλλες τιμές στο mtu.

Η ερώτηση η δική μου είναι το payload με το οποίο ξεκινάμε τους υπολογισμούς ταυτίζεται με το mtu που παίρνεις με auto από τον πάροχος.
Δηλαδή... για το vlan θα πρέπει να έχουμε:
1472 payload + 8 icmp header + 20 ipv4 header
ή
1492 payload + 8 icmp header + 20 ipv4 header

Αρχικό μήνυμα από macro

Εγω με αυτο που ηθελα να πω ειναι οτι αν το sg analyzer σου δειχνει 1492, οσο και να το βαλεις εσυ, στο τελος ο provider σε βγαζει με 1492 οποτε και αυτο πρεπει να βαλεις.

Που το βλέπεις αυτό;
Αφού σου λέω ότι έκανα διάφορες δοκιμές και μου έδειξε κανονικά 1500.
Και μάλιστα λέω ότι αυτό έγινε με δίνοντας ξανά τις ίδιες τιμές και με 2-3 refresh μου έδειξε 1500.
Τι κάνει δηλαδή ο πάροχος;
Αλλάζει δυναμικά το Mtu;

**macro** · 30-09-23, 09:31

δλδ εσυ πιστευεις οτι βγαινεις με 1500? Επειδη με 1492 βγαινεις απο οσο λεει το analyzer. Κανε και αλλου analyzer να το δεις.

**deniSun** · 30-09-23, 10:51

Αρχικό μήνυμα από macro

δλδ εσυ πιστευεις οτι βγαινεις με 1500? Επειδη με 1492 βγαινεις απο οσο λεει το analyzer. Κανε και αλλου analyzer να το δεις.

Έχω mtu 1500,
Κάνε tracepath, δίνω ping, κάνω mturoute και σε όλα παίρνω κανονικά ένδειξη για mtu 1500.
Τρέχω speedguide και μου δίνει ένδειξη για 1492.

Αλλάζω τιμές στο mtu σε 1500+.
Κάνε tracepath, δίνω ping, κάνω mturoute και σε όλα παίρνω κανονικά ένδειξη για mtu 1500.
Τρέχω ξανά speedguide και μου δίνει πάλι ένδειξη για 1492.
Κάνω 2-3 refresh και μου δίνει ένδειξη 1500.

Αλλάζω ξανά τιμές στο mtu όπως τις είχα στην αρχή (mtu 1500).
Κάνε tracepath, δίνω ping, κάνω mturoute και σε όλα παίρνω κανονικά ένδειξη για mtu 1500.
Τρέχω ξανά speedguide και μου δίνει τώρα ένδειξη για 1500.
Κάνω 2-3 refresh και μου δίνει πάλι ένδειξη 1500.

Από τα παραπάνω έχουμε και λέμε:
Με mtu 1500 τα tracepath/ping/mturoute μου έδιναν πάντα ένδειξη ότι είχα 1500.
Το speeguide μου έδωσε αρχικά ένδειξη 1492.
Με mtu 1500+ τα tracepath/ping/mturoute μου έδιναν ξανά σωστή ένδειξη.
Το speeguide μου έδωσε αρχικά ένδειξη 1492 και μετά από 2-3 refresh μου έδειξε σωστά 1500.
Γυρίζω ξανά σε mtu 1500 και τα tracepath/ping/mturoute εξακολουθούν να μου δίνουν σωστή ένδειξη.
Το speeguide τώρα μου δίνει 1500 και με 2-3 refresh εξακολουθεί να μου δίνει 1500.

Απ όλα αυτά εσύ τι συμπέρασμα βγάζεις;
Ότι οι τρεις από τις τέσσερις δοκιμές έδιναν λάθος ένδειξη και η σωστή ήταν του speedguide το οποίο μετά από refresh έβγαζε άλλα αποτελέσματα;

-------------------

Επιστρέφοντας στα περί ρυθμίσεων.
Αυτό που συμπεραίνω είναι ότι για να έχουμε mtu 1500 σύμφωνα με το RFC4638
σημαίνει ότι θα πρέπει να έχουμε 1472 payload.
Άρα σύμφωνα με αυτά που λένε στο φόρουμ της ΜΤ από εδώ, εδώ και εδώ
για να πάρουμε είμαστε σύμφωνοι με το RFC4638 για mtu 1500 θα πρέπει να έχουμε
pppoe client mtu/mru: 1500/1500
και τα δε vlan/ether1 mtu: 1500/1500 (δεν επηρεάζουν σε κάτι).

Με τις παραπάνω τιμές νέες μετρήσεις:

Κώδικας:

 .\mturoute.exe ftp.mozilla.org
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
+ ICMP payload of 1472 bytes succeeded.
- ICMP payload of 1473 bytes is too big.
Path MTU: 1500 bytes.

Κώδικας:

.\mturoute.exe -t ftp.grnet.gr
mturoute to ftp.grnet.gr, 30 hops max, variable sized packets
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
 1  +-  host: 192.168.5.39  max: 1500 bytes
 2  +-  host: 80.106.125.100  max: 1500 bytes
 3  +-  host: 79.128.242.186  max: 1500 bytes
 4  +-  host: 79.128.240.149  max: 1500 bytes
 5  +-  host: 79.128.227.225  max: 1500 bytes
 6  +-  host: 176.126.38.31  max: 1500 bytes
 7  +-  host: 62.217.100.63  max: 1500 bytes
 8  +-  host: 62.217.96.169  max: 1500 bytes
 9  +-  host: 147.102.222.211  max: 1500 bytes

Κώδικας:

tracepath -4 ftp.mozilla.org
 1?: [LOCALHOST]                      pmtu 1500
 1:  mikrotik-porthos                                      0.373ms
 1:  mikrotik-porthos                                      0.344ms
 2:  80.106.125.100                                        1.704ms
 3:  79.128.242.186                                        2.969ms
 4:  62.75.3.73                                            2.577ms
 5:  62.75.14.138                                         29.652ms
 6:  62.75.27.178                                         31.459ms asymm 11
 7:  108.170.236.175                                      32.164ms asymm  9
 8:  172.253.73.155                                       30.456ms asymm  7
 9:  28.35.117.34.bc.googleusercontent.com                29.174ms reached
     Resume: pmtu 1500 hops 9 back 7

Κώδικας:

tracepath -6 ftp.grnet.gr
 1?: [LOCALHOST]                        0.025ms pmtu 1500
 1:  2a02:587:1918:2000:ba69:f4ff:fec5:5ded                0.349ms
 1:  2a02:587:1918:2000:ba69:f4ff:fec5:5ded                0.325ms
 2:  no reply
 3:  2a02:580:50da:38f::                                   4.150ms
 4:  no reply
 5:  no reply
 6:  grnet-2.gr-ix.gr                                      8.580ms
 7:  ntua-zogr-2.kolettir.access-link.grnet.gr            10.531ms
 8:  patroklos6.noc.ntua.gr                                9.682ms reached
     Resume: pmtu 1500 hops 8 back 8

Κώδικας:

ping -4 ftp.mozilla.org -s 1472 -Mdo -c 3
PING ftp.mozilla.org (34.117.35.28) 1472(1500) bytes of data.
76 bytes from 28.35.117.34.bc.googleusercontent.com (34.117.35.28): icmp_seq=1 ttl=58 (truncated)
76 bytes from 28.35.117.34.bc.googleusercontent.com (34.117.35.28): icmp_seq=2 ttl=58 (truncated)
76 bytes from 28.35.117.34.bc.googleusercontent.com (34.117.35.28): icmp_seq=3 ttl=58 (truncated)

--- ftp.mozilla.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 29.199/30.056/31.387/0.953 ms

Κώδικας:

ftp.grnet.gr -s 1452 -Mdo -c 3
PING ftp.grnet.gr(patroklos6.noc.ntua.gr (2001:648:2000:de::211)) 1452 data bytes
1460 bytes from patroklos6.noc.ntua.gr (2001:648:2000:de::211): icmp_seq=1 ttl=57 time=11.0 ms
1460 bytes from patroklos6.noc.ntua.gr (2001:648:2000:de::211): icmp_seq=2 ttl=57 time=9.37 ms
1460 bytes from patroklos6.noc.ntua.gr (2001:648:2000:de::211): icmp_seq=3 ttl=57 time=11.1 ms

--- ftp.grnet.gr ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 9.366/10.495/11.092/0.798 ms

Κώδικας:

« SpeedGuide.net TCP Analyzer Results » 
Tested on: 2023.09.30 03:51 
IP address: 94.68.xxx.xxx 
Client OS/browser: Windows 10 (Firefox 118.0) 
 
TCP options string: 020405b40103030801010402 
MSS: 1460 
MTU: 1500 
TCP Window: 262656 (not multiple of MSS) 
RWIN Scaling: 8 bits (2^8=256) 
Unscaled RWIN : 1026 
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840 
BDP limit (200ms): 1051 Mbps (105 Megabytes/s) 
BDP limit (500ms): 420 Mbps (42 Megabytes/s) 
MTU Discovery: ON 
TTL: 114 
Timestamps: OFF 
SACKs: ON 
IP ToS: 00000000 (0)

**macro** · 30-09-23, 11:16

Συμπεραινω οτι τελικα εχεις 1500 αλλα για καποιο λογο καποιες φορες εχεις και 1492. Πιθανο να φταιει μερικες φορες καποια ενδιαμεση δρομολογηση.

Καλο θα ηταν να κανεις analyzer και σε αλλα sites εκτος απο SG, νομιζω οτι το dslreports πρεπει να εχει καποιο tool. Ειχα βρει και αλλου παλαιοτερα αλλα δε θυμαμαι.

Αν μετα απο ολα αυτα συνεχιζε και μου εδινε εστω καποιες φορες 1492, εγω θα το αφηνα εκει. Οι διαφορες νομιζω οτι δεν ειναι καν θεωρητικες, για να μη μιλησω για τη πρακτικοτητα των 8 μοναδων διαφορα. Στα 100mbit και 1400 να το βαλεις, καμια διαφορα δε θα δεις. Αν το εχεις ομως παραπανω, ισως να δεις διαφορες με σπασιματα κολληματα απο καποιους ενδιαμεσους δρομολογητες που να μη το υποστηριζουν.

Γνωμη μου...... εχεις dsl, το πολυ 1492, εχεις cable μπορεις και 1500. Απο οσο θυμαμαι το 1500 στο dsl υποστηριζεται μονο στο pppoa multiplexing.

Aκομη νομιζω οτι αυτη η κουβεντα δεν εχει καποιο πρακτικο οφελος και αναλωνομαστε. Αν βεβαια εσυ εχεις την εντυπωση οτι το 1500 σε απογειωσε οπως λες και δεν ειναι καποιο ψυχολογικο τερτιπι που επαθες, ειμαι οκ και με αυτο και θα το εχω υποψη μου.

Ετσι απο περιεργεια η εντολη απο windows cmd που σου ειπα παραπανω, σου περναει στα 1472 παντα? Αλλιως η επομενη που θα σου περναει ειναι με 1464.

**deniSun** · 30-09-23, 11:28

Αρχικό μήνυμα από macro

Αν βεβαια εσυ εχεις την εντυπωση οτι το 1500 σε απογειωσε οπως λες και δεν ειναι καποιο ψυχολογικο τερτιπι που επαθες, ειμαι οκ και με αυτο και θα το εχω υποψη μου.

Απλή δοκιμή που μπορείτε να κάνετε όλοι σας και ας μην θεωρηθεί διαφήμιση.
Ανοίξτε αυτή την σελίδα και μετρήστε τον χρόνο με ff + app.telemetry Page Speed Monitor (υπάρχει και για chrome).
Δοκιμάστε με 1492 και με 1500.
Ακόμα και χωρίς την μέτρηση η διαφορά είναι τεράστια.
Σε όλες τις υπόλοιπες σελίδες που επισκέπτομαι η διαφορά είναι πολύ μικρότερη αλλά εμφανώς αισθητή.

Αρχικό μήνυμα από macro

αλλα για καποιο λογο καποιες φορες εχεις και 1492

Εγώ πάλι επιμένω ότι το συγκεκριμένο τεστ της speedguide δεν βγάζει πάντα σωστά αποτελέσματα.
Και αυτό αποδεικνύεται με τις δοκιμές που έκανα παραπάνω και με τα όσα επισήμανα..

**netblues** · 30-09-23, 11:28

Καθαρα placebo effect. Σαν τα megabit που λειπουν απο τις 1000ρες :P :P

**deniSun** · 30-09-23, 12:55

Αρχικό μήνυμα από netblues

Καθαρα placebo effect. Σαν τα megabit που λειπουν απο τις 1000ρες :P :P

placebo effect το ότι έχεις γρηγορότερο φόρτωμα σελίδων;
Εγώ το μέτρησα παραπάνω και με παράδειγμα.
Κάνε και εσύ τις μετρήσεις σου να μας διαψεύσεις.

ΥΓ
μην μου πεις ότι έχει μούσια και δεν ξυρίζεσαι οπότε δεν σε ενδιαφέρει η συγκεκριμένη σελίδα.

Θέμα: Συζήτηση για MTU, MRU, MSS, clamping

Bookmarks

Bookmarks

Δικαιώματα - Επιλογές