28.2.2023, 22:47
(Tento příspěvek byl naposledy změněn: 01.3.2023, 11:35 uživatelem JiRo.
Důvod úpravy: Překlepy, doplnění informace.
)
139.59 Mbps v SCC testu ve 21:05, dřív jsme to nestihnul... 
Mé připojení: UPC/Vodafone 150/10, lokalita Praha 5, Barrandov.
Pak jsem ještě pustil film, průběh rychlostí na začátku přehrávání, kdy se plní cache, je videt zde:
Počítá se vždy průměrná rychlost z 5 sec přenesených dat na rozhraní eth. Film spuštěn ve 21:08:05.
21:08:06 je neúplná perioda, takže rychlost o hodně nižší než maximální (tady záleží v který čas periody měření se začne načítat stream).
21:0811 - 21:08:51 tady je vidět kolísání maximálního datového toku, to je podle mě vliv vysokého zatížení v prime time. Když ten samý film pustím mimo exponovanou dobu, bude to o hodně pravděpodobněji trvale motat kolem maximální rychlosti (150 Mbps).
Zkusil jsem to tedy ještě o něco později.
Tady už je vidět lepší průběh.
Takže suma sumárum... Ano, vysoké zatížení v exponovanou dobu může ovlivnit maximální rychlost, u mne je to řádově v nízkých jednotkách procent. U jiného providera a jiném profilu cesty mezi koncovým uživatelem a Webshare to samozřejmě může bý jiné a i propad maximální rychlosti může být vyšší. Ale nelze to příčíst na vrub zatížení serevrů Webshare nebo změnách v rychlosti komunikace na rozhraní připojení těchto serverů do páteřní části sítě. To by to přeci pak tak měli všichni...
A ještě jsem přidal jedno měření ráno, po 6:30.
148.59 Mbps v SCC testu.
A opět spuštěn stejný stream.
Porovnáním průběh po začátku přehrávání s předchozími pokusy je myslím celkem jasně vidět rozdíl mezi "prime time" a "ranním provozem". Je také vidět, že případný pokles rychlosti v exponované době se pohybuje skutečně v nízkých jednotkách %. Co ale z toho není vidět, zda a jak moc se na tom poklesu podílí Webshare resp. jeho servery. Tento závěr z toho prostě není možné udělat!
Podle mého je tedy dost pravděpodobný závěr, že pokles rychlosti směrem od/k serverům Webshare oproti jinému měření rychlosti (a tedy i v jiném směru) má na svědomí z větší části něco/někdo po cestě mezi ním a servery, nikoliv tedy servery samotné.
Mé připojení: UPC/Vodafone 150/10, lokalita Praha 5, Barrandov.Pak jsem ještě pustil film, průběh rychlostí na začátku přehrávání, kdy se plní cache, je videt zde:
Počítá se vždy průměrná rychlost z 5 sec přenesených dat na rozhraní eth. Film spuštěn ve 21:08:05.
21:08:06 je neúplná perioda, takže rychlost o hodně nižší než maximální (tady záleží v který čas periody měření se začne načítat stream).
21:0811 - 21:08:51 tady je vidět kolísání maximálního datového toku, to je podle mě vliv vysokého zatížení v prime time. Když ten samý film pustím mimo exponovanou dobu, bude to o hodně pravděpodobněji trvale motat kolem maximální rychlosti (150 Mbps).
Zkusil jsem to tedy ještě o něco později.
Tady už je vidět lepší průběh.
Takže suma sumárum... Ano, vysoké zatížení v exponovanou dobu může ovlivnit maximální rychlost, u mne je to řádově v nízkých jednotkách procent. U jiného providera a jiném profilu cesty mezi koncovým uživatelem a Webshare to samozřejmě může bý jiné a i propad maximální rychlosti může být vyšší. Ale nelze to příčíst na vrub zatížení serevrů Webshare nebo změnách v rychlosti komunikace na rozhraní připojení těchto serverů do páteřní části sítě. To by to přeci pak tak měli všichni...
A ještě jsem přidal jedno měření ráno, po 6:30.
148.59 Mbps v SCC testu.
A opět spuštěn stejný stream.
Porovnáním průběh po začátku přehrávání s předchozími pokusy je myslím celkem jasně vidět rozdíl mezi "prime time" a "ranním provozem". Je také vidět, že případný pokles rychlosti v exponované době se pohybuje skutečně v nízkých jednotkách %. Co ale z toho není vidět, zda a jak moc se na tom poklesu podílí Webshare resp. jeho servery. Tento závěr z toho prostě není možné udělat!
Podle mého je tedy dost pravděpodobný závěr, že pokles rychlosti směrem od/k serverům Webshare oproti jinému měření rychlosti (a tedy i v jiném směru) má na svědomí z větší části něco/někdo po cestě mezi ním a servery, nikoliv tedy servery samotné.