I mitt föregående inlägg testade att CG3100 i NAT-läge och mätte antal anslutningar samt responstid. Jag har nu även testat med bridge-läget samt använt ytterligare en maskin för att mäta responstiden mot modemet lokalt.
Mätresultaten visar att CG3100 orkar 150 anslutningar i bryggat läge. Lokalt stiger responstiden mot modemet från 1ms till 20-25ms och packet loss ligger på runt 10%. Låt mig upprepa det, 25ms och 10% packet loss lokalt.
För att tillhöra en tjänst som prissätts 400-500kr i månaden är det under all kritik att ha ett modem som inte hanterar fler anslutningar och ger packet loss och hög responstid innan du ens kommit ut mot internet.
tisdag 15 november 2011
måndag 14 november 2011
Prestanda med Netgear CG3100
CG3100 är ett kabelmodem från Netgear, detta modemet använder Comhem framförallt till sina 100mbit- och 200mbit-tjänster. Jag har länge varit nyfiken på hur många anslutningar CG3100 klarar av pålitligt men även hur modemet fungerar under hög last.
För att mäta detta satte jag upp en testmiljö. Normalt är det inga problem att mäta lokalt, men i och med att det är ett kabelmodem var jag tvungen att sätta upp en mätserver på internet.
Testsystem
CG3100-modemet körs med mjukvara v0028 i NAT-läge. Det som är ändrat från default-inställningarna är att tjänsterna och wlan är avstängt, samt att ett par portar har öppnats för testet.
Min testserver på internet består av en OpenBSD-maskin med gigabitlänk och mot modemet sitter en Linuxmaskin ansluten med 100mbit direkt mot CG3100.
Jag låter OpenBSD-maskinen starta 500 TCP-instanser av iperf och mäter antal anslutningar samt ping mot modemet. Då jag kör 100mbit mellan modemet och testmaskinen kan jag tyvärr inte mäta packet loss tillförlitligt.
Resultat
Vid försök på 500 anslutningar stannar modemet vid exakt 120 anslutningar och håller sig där konstant. Överföringshastigheten är då på 11.5MB/s vid en intern snittping mot modemet på 47ms.
Med v0028 fryser inte modemet som med tidigare firmwares utan klarar sig stabilt i över 1.5 timmar, då jag väljer att avsluta testet.
Sammanfattningsvis kan man säga att modemet håller den utlovade hastigheten, men det är också allt. 120 anslutningar är inte mycket och att gå från ~1ms till ~47ms under last är på tok för mycket.
Testmedotik:
iperf körs i TCP-läge, klienten (maskinen som skickar data) startas med
for i in $(jot 100) ; do iperf -c hostname & done
Servern (maskinen som tar emot data) körs med
iperf -s
Anledningen till att inte -P flaggan används är att den inte fungerar pålitligt nog och inte verkar fungera alls under OpenBSD som testservern kör.
Överföringshastighet mäter jag med programvaran slurm. slurm -i eth0
Antal anslutningar mäter jag med snmp-datan i proc.
cat /proc/net/snmp | tail -5 | head -1 | awk '{print $10}'
Detta kommandot fungerar fint med min konfiguration, men för andra konfigurationer rekommenderar jag att du tittar på hela outputen från cat /proc/net/snmp.
Responstid mäts lokalt med ping mellan Linuxdatorn och modemet, ping 192.168.0.1. Jag lät 500 paket sätta snittvärdet.
För att mäta detta satte jag upp en testmiljö. Normalt är det inga problem att mäta lokalt, men i och med att det är ett kabelmodem var jag tvungen att sätta upp en mätserver på internet.
Testsystem
CG3100-modemet körs med mjukvara v0028 i NAT-läge. Det som är ändrat från default-inställningarna är att tjänsterna och wlan är avstängt, samt att ett par portar har öppnats för testet.
Min testserver på internet består av en OpenBSD-maskin med gigabitlänk och mot modemet sitter en Linuxmaskin ansluten med 100mbit direkt mot CG3100.
Jag låter OpenBSD-maskinen starta 500 TCP-instanser av iperf och mäter antal anslutningar samt ping mot modemet. Då jag kör 100mbit mellan modemet och testmaskinen kan jag tyvärr inte mäta packet loss tillförlitligt.
Resultat
Vid försök på 500 anslutningar stannar modemet vid exakt 120 anslutningar och håller sig där konstant. Överföringshastigheten är då på 11.5MB/s vid en intern snittping mot modemet på 47ms.
Med v0028 fryser inte modemet som med tidigare firmwares utan klarar sig stabilt i över 1.5 timmar, då jag väljer att avsluta testet.
Sammanfattningsvis kan man säga att modemet håller den utlovade hastigheten, men det är också allt. 120 anslutningar är inte mycket och att gå från ~1ms till ~47ms under last är på tok för mycket.
Testmedotik:
iperf körs i TCP-läge, klienten (maskinen som skickar data) startas med
for i in $(jot 100) ; do iperf -c hostname & done
Servern (maskinen som tar emot data) körs med
iperf -s
Anledningen till att inte -P flaggan används är att den inte fungerar pålitligt nog och inte verkar fungera alls under OpenBSD som testservern kör.
Överföringshastighet mäter jag med programvaran slurm. slurm -i eth0
Antal anslutningar mäter jag med snmp-datan i proc.
cat /proc/net/snmp | tail -5 | head -1 | awk '{print $10}'
Detta kommandot fungerar fint med min konfiguration, men för andra konfigurationer rekommenderar jag att du tittar på hela outputen från cat /proc/net/snmp.
Responstid mäts lokalt med ping mellan Linuxdatorn och modemet, ping 192.168.0.1. Jag lät 500 paket sätta snittvärdet.
fredag 4 november 2011
Dumpa och återställa MySQL-databas
Om man vill ta backup eller förflytta en MySQL-databas mellan två datorer är det praktiskt att kunna dumpa databasen till en fil.
För att exportera
mysqldump -u användarnamn -p --all-databases > dump.sql
För att importera
mysql --verbose -user användarnamn -p < dump.sql
Källa:
patrickpatoray.com
För att exportera
mysqldump -u användarnamn -p --all-databases > dump.sql
För att importera
mysql --verbose -user användarnamn -p < dump.sql
Källa:
patrickpatoray.com
Prenumerera på:
Inlägg (Atom)