:fill(white):strip_exif()/i/2002174789.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/1361353822.jpeg?f=thumbmini)
Dit is momenteel geen issue meer, omdat ik m'n belangrijkste apparaten direct in m'n modem heb gestopt, maar ik ben toch wel benieuwd waarom dit komt.
Ik heb Ziggo 500/40MBit (en wordt ook werkelijk gehaald bij directe aansluiting).
Switches zijn respectievelijk:
- TP-LINK TL-SG108 - Switch (hierna genoemd Switch 1, huiskamer)
- TP-Link TL-SG105 - Switch (hierna genoemd Switch 2, kantoor)
Kabel zijn allemaal onder 10 meter, dus zou niet veel moeten uitmaken, lijkt me.
De situatie was eerst (alle kabels zijn Cat5e en/of Cat6):
Ziggo Modem > Switch 1 > Switch 2 > Windows PC: ~350MBit internet speedtest
Ziggo Modem > Switch 1 > Mac Mini: 470~500Mbit internet speedtest
Echter als ik via Samba van de Windows PC naar de Mac Mini data kopieer haal ik wel 112MB/s (~900MBit).
Nu heb de kabel die naar Switch 2 loopt direct in de modem gedaan, dus is de extra hop er niet meer (Ziggo Modem > Switch 1 > Switch 2 = Ziggo Modem > Switch 2). Nu haalt de Windows PC ook gewoon 470~500MBit.
Nu is dit topic niet echt meer bedoeld om het snelheidsissue te verhelpen, echter ben ik benieuwd waarom die TP-Link switches tijdens de Internet speedtest wankelen, terwijl als ik via de 2 switches-hop via Samba van de Windows PC naar de Mac Mini wel gewoon 900Mbit haal. Met iperf is de lijn zelfs gewoon netjes puur 1Gbit.
Tijdens het testen heb ik wel bewust de andere devices in de switches laten zitten (deze waren niet aan het downloaden of intranet data aan het verbruiken). De 8-poort was gevuld met 6 devices (nog 1 slot over) en de 5-poort was gevuld met 3 (nog 1 slot over).
Nu is de vraag eigenlijk; waarom verliest de internet-dataflow snelheid terwijl dezelfde dubbele switch-hop via het intranet zelf (over samba/iperf) wel gewoon volle snelheid kan behouden. Is dit een raar congestion issue van de switches wanneer Modem > Switch 1 > Switch 2 verkeer plaatsvind, wat dan niet gebeurd bij intranet-transfer door 2 switches?
(Zowel Samba kopieren als downloaden is meerdere minuten getest, dus er is hoogwaarschijnlijk geen sprake van tijdelijk belasting door andere factoren)
Ik heb Ziggo 500/40MBit (en wordt ook werkelijk gehaald bij directe aansluiting).
Switches zijn respectievelijk:
- TP-LINK TL-SG108 - Switch (hierna genoemd Switch 1, huiskamer)
- TP-Link TL-SG105 - Switch (hierna genoemd Switch 2, kantoor)
Kabel zijn allemaal onder 10 meter, dus zou niet veel moeten uitmaken, lijkt me.
De situatie was eerst (alle kabels zijn Cat5e en/of Cat6):
Ziggo Modem > Switch 1 > Switch 2 > Windows PC: ~350MBit internet speedtest
Ziggo Modem > Switch 1 > Mac Mini: 470~500Mbit internet speedtest
Echter als ik via Samba van de Windows PC naar de Mac Mini data kopieer haal ik wel 112MB/s (~900MBit).
Nu heb de kabel die naar Switch 2 loopt direct in de modem gedaan, dus is de extra hop er niet meer (Ziggo Modem > Switch 1 > Switch 2 = Ziggo Modem > Switch 2). Nu haalt de Windows PC ook gewoon 470~500MBit.
Nu is dit topic niet echt meer bedoeld om het snelheidsissue te verhelpen, echter ben ik benieuwd waarom die TP-Link switches tijdens de Internet speedtest wankelen, terwijl als ik via de 2 switches-hop via Samba van de Windows PC naar de Mac Mini wel gewoon 900Mbit haal. Met iperf is de lijn zelfs gewoon netjes puur 1Gbit.
Tijdens het testen heb ik wel bewust de andere devices in de switches laten zitten (deze waren niet aan het downloaden of intranet data aan het verbruiken). De 8-poort was gevuld met 6 devices (nog 1 slot over) en de 5-poort was gevuld met 3 (nog 1 slot over).
Nu is de vraag eigenlijk; waarom verliest de internet-dataflow snelheid terwijl dezelfde dubbele switch-hop via het intranet zelf (over samba/iperf) wel gewoon volle snelheid kan behouden. Is dit een raar congestion issue van de switches wanneer Modem > Switch 1 > Switch 2 verkeer plaatsvind, wat dan niet gebeurd bij intranet-transfer door 2 switches?
(Zowel Samba kopieren als downloaden is meerdere minuten getest, dus er is hoogwaarschijnlijk geen sprake van tijdelijk belasting door andere factoren)
/u/38159/DirkJan.png?f=community)