114 replies to this topic

[theparasol]

Heb vanmorgen mijn xp1000 geupdated naar 20140109, tot mijn verrassing werd er een nieuwe linux kernel geinstalleerd:

 

Linux xp1000 3.12.1 #1 Mon Jan 6 23:06:34 CET 2014 mips GNU/Linux

 

Echter ik ervaar een zeer trage netwerk interface, die zelfs met ssh zeer langzaam is.

Openwebif en diverse webif van andere progjes die draaien op de box zijn momenteel onbruikbaar langzaam.

Ik zal maar niet beginnen over streaming.

 

Hopelijk ziet iemand kans om het te fixen.

[theparasol]

iets meer info voor de liefhebbers, als er meer nodig is geef maar aan wat je wilt hebben!

 

Mijn netwerkadapter stond op static ip, via menu omgezet naar dhcp en daarna het voorstel om netwerkconfiguratie te activeren....

de raderen draaien al 3 minuten...

 

Hmz... static was 192.168.1.32, een netscan levert met nog steeds draaiende raderen 192.168.1.36 op en ik kan met ssh erin.

 

dit vindt ik in proceslijst:

 

2811     1 root     S     3084   1%   0% udhcpc -R -b -H xp1000 -p /var/run/udhcpc.eth0.pid -i eth0

 

Netwerk nog net zo sloom als voorheen...

Attached Files

•  xp1000techinfo.txt   11.24KB   15 downloads

Edited by theparasol, 9 January 2014 - 23:30.

[HPPli]

Zie niks bijzonders en/of veranderingen na update donderdag 9 januari van mijn XP1000.

Kleine test gaf geen draaiende raderen bij gelijktijdig kijken naar de Oscam-Webif, live beeld op TV en live beeld op PC middels OpenWebif.
Zelfs remote channel realstream van andere STB, gaf geen enkel probleem en dus wederom live beeld op TV en ook (!) live beeld op PC middels OpenWebif.

Denk dat er een "bitje" is omgevallen en wordt dus een verse flash van je XP1000. Kost minder tijd dan de oorzaak proberen te achterhalen
 
P.s. Leuk voor je om te horen denk ik, alle beelden keurig met latest Oscam revisie + backintimev3fix.patch op zowel Inhouse Synology NAS alsmede mijn STB (Vu+Duo2 & XP1000).
Heb hiervoor lange tijd (zonder segfaults of crashes) kunnen "draaien" met de tpreloadedv10.patch van je.

Edited by HPPli, 10 January 2014 - 00:44.

[theparasol]

update: alles verkeer van de box naar elders = sloom, alles richting de box gaat snel.

 

Idd.. verse flash dan maar proberen... eerst ff wat spulletjes veiligstellen

[theparasol]

Jammer van de tijd, probleem blijft helaas...

[HPPli]

Zeker jammer, misschien even terug naar een "verse" flash van 5 januari ?

En ......, kunnen de heren Devs misschien even hierop een "blik" werpen ???

Edited by HPPli, 10 January 2014 - 03:04.

[theparasol]

net na opstarten is het nog snel (120kb/s) van box naar computer, daarna kakt het in naar zelfs permanent 2 of 3  kb/s

Onvoorstelbaar: net alsof ik met een 33k6 modem een file download van een bbs

[HPPli]

Met een normale FTP-connectie op poort 21 (test via WinSCP) zie ik met laatste Pli-update van 9 Jan absoluut veel langzamer "verkeer" vanaf XP1000 !!!

Vergelijk na test; (groot aantal files overzetten vanuit STB naar USB-stick/PC)
XP1000 5.500 B/s
VU+Duo2 1.275 KiB/s
Vu+Duo 700 KiB/s

[theparasol]

Rechtstreeks lan kabel tussen laptop en xp1000: geen effect.

 

Nou ik laat het maar ff zo, alleen verkeer van de box naar andere apparaten gaan niet lekker.

Alle verkeer richting de box gaat wel op normale snelheid zover ik dat kan beoordelen.

 

Streamen gebruik ik toch praktisch niet dus het is al met al momenteel een mooie kijkdoos

[theparasol]

nog een toegiftje:

 

root@xp1000:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether b4:9d:b4:00:02:30 brd ff:ff:ff:ff:ff:ff
 

[theparasol]

root@xp1000:~# netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         fritz.box       0.0.0.0         UG        0 0          0 eth0
192.168.1.0     *               255.255.255.0   U         0 0          0 eth0
root@xp1000:~# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:8001            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:netbios-ssn     0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:sunrpc          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:http            0.0.0.0:*               LISTEN
tcp        0      0 xp1000.fritz.box:tproxy 0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:ftp             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:telnet          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:https           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:microsoft-ds    0.0.0.0:*               LISTEN
tcp        0    132 xp1000.fritz.box:ssh    HP5330M.fritz.box:5118  ESTABLISHED
tcp        0      0 xp1000.fritz.box:45557  192.168.1.203:microsoft-ds ESTABLISHED
netstat: /proc/net/tcp6: No such file or directory
udp        0      0 xp1000.fritz.box:43023  0.0.0.0:*
udp        0      0 0.0.0.0:53805           0.0.0.0:*
udp        0      0 0.0.0.0:sunrpc          0.0.0.0:*
udp        0      0 xp1000.fritz.box:netbios-ns 0.0.0.0:*
udp        0      0 0.0.0.0:netbios-ns      0.0.0.0:*
udp        0      0 xp1000.fritz.box:netbios-dgm 0.0.0.0:*
udp        0      0 0.0.0.0:netbios-dgm     0.0.0.0:*
udp        0      0 0.0.0.0:telnets         0.0.0.0:*
udp        0    704 0.0.0.0:mdns            0.0.0.0:*
netstat: /proc/net/udp6: No such file or directory
netstat: /proc/net/raw6: No such file or directory
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  6      [ ]         DGRAM                      1030 /dev/log
unix  2      [ ACC ]     STREAM     LISTENING        777 /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING       1060 /var/run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING       1096 /tmp/.listen.camd.socket
unix  2      [ ACC ]     STREAM     LISTENING       1147 /tmp/hotplug.socket
unix  2      [ ACC ]     STREAM     LISTENING        982 /var/run/rpcbind.sock
unix  2      [ ]         DGRAM                      1054
unix  2      [ ]         DGRAM                      2218
unix  3      [ ]         STREAM     CONNECTED        781
unix  3      [ ]         STREAM     CONNECTED       2168 /tmp/.listen.camd.socket
unix  3      [ ]         STREAM     CONNECTED       1056
unix  3      [ ]         STREAM     CONNECTED        780
unix  2      [ ]         DGRAM                      2158
unix  3      [ ]         STREAM     CONNECTED       1063 /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED       1057
unix  2      [ ]         DGRAM                      1037
unix  3      [ ]         STREAM     CONNECTED       1062
unix  3      [ ]         STREAM     CONNECTED       2167
 

Edited by theparasol, 10 January 2014 - 03:54.

[WanWizard]

Ik zie dat je een fritzbox gebruikt, die wil nog wel eens voor problemen zorgen. Die heeft de box toch niet toevallig in half-duplex of zo gezet?

 

Als je de box een fixed IP geeft, herstart zonder netwerkkabel, en dan een directe connectie met je laptop?

 

Wat is de output van "ethtool eth0", voor en na deze actie?

[cobus]

Idd ik heb ook eens gelezen dat de xp en fritz slecht samen gaan.

Edited by cobus, 10 January 2014 - 08:33.

[Erik Slagter]

De Fritzbox gaat met alle hardware slecht

 

Als je ergens een linux-bakkie hebt staan, dan raad ik aan een flood ping te proberen. Het voordeel van ping boven ftp etc. is dat het compleet door de kernel wordt afgehandeld, een trage userspace kan dus geen invloed hebben.

 

ping -f host... (moet je wel root voor zijn).

 

Je kunt 'm nog harder pesten door de packet size flink groter te maken, naar 1200 bytes bijvoorbeeld. Daarboven kan ook, maar dan krijg je fragmentatie, en dan is de kans wat groter dat je packets gaat kwijtraken.

 

In tegenstelling tot wat de naam doet vermoeden gaat een flood ping niet op volle snelheid van je interface, het is dus redelijk veilige te gebruiken. Als ik echt wil flooden gebruik ik ((n)u)ttcp, daarmee kun je udp packets op een willekeurige rate afvuren. Het is dan ook heel normaal dat je packet loss hebt, maar dat is een ander verhaal.

[cobus]

Is dat zo dat de fritz met alle hardware slecht gaat ?  het is dacht toch een van de betere modems/routers wie er zijn ?

Edited by cobus, 10 January 2014 - 10:10.

[WanWizard]

Het probleem van de Fritz is de power-save mode waar ze zo over opscheppen (en waarvoor zelfs opties in de interface zitten die dat rapporteren).

 

Een van de acties die ze doen is bij weinig verkeer de interface van de built-in switch terugschakelen naar 10Mbps en wellicht zelfs half duplex, in een poging wat milliwatten te besparen. Een actie die sommige aangesloten toestellen in opperste verwarring achterlaat.

 

Mismatch in de config van beide ethernet poorten is altijd een drama. Bij een mismatch in duplex mode (ene kant full duplex, andere kant half duplex) zul je zien dat bij de start er nog enige doorvoer is, totdat de collisions komen, en dan stort de performance in elkaar.

[Erik Slagter]

Is dat zo dat de fritz met alle hardware slecht gaat ?  het is dacht toch een van de betere modems/routers wie er zijn ?

Ja dat denken veel mensen. Misschien omdat er veel "knopjes" op zitten? Ik heb liever een product dat niet zoveel kan maar dan wel goed.
 
Ik heb er zelf een een maand gehad, als "kadootje" van xs4all. Hij is na een maand retour afzender gegaan, ik kon er geen werkend netwerk mee maken. Vervolgens heb ik het domste adsl-modem gekocht wat er is, die aangesloten op m'n linux firewall en daarna nooit meer een probleem gehad.

Edited by Erik Slagter, 10 January 2014 - 10:19.

[Erik Slagter]

Het probleem van de Fritz is de power-save mode waar ze zo over opscheppen (en waarvoor zelfs opties in de interface zitten die dat rapporteren).
 
Een van de acties die ze doen is bij weinig verkeer de interface van de built-in switch terugschakelen naar 10Mbps en wellicht zelfs half duplex, in een poging wat milliwatten te besparen. Een actie die sommige aangesloten toestellen in opperste verwarring achterlaat.
 
Mismatch in de config van beide ethernet poorten is altijd een drama. Bij een mismatch in duplex mode (ene kant full duplex, andere kant half duplex) zul je zien dat bij de start er nog enige doorvoer is, totdat de collisions komen, en dan stort de performance in elkaar.

Op zich is gigabit wel een flinke energieverstoker en dan hebben we het niet over een paar milliwatts. Ik zie consequent dat gbit switches en gbit nic's zeker twee keer zoveel energie gebruiken dan de 100 mbps varianten.

 

Als AVM voor de energiebesparing netjes EEE zou gebruiken, dan zou dat in principe geen probleem mogen geven.

[MiLo]

Gigbit vreet continu energie omdat hij continu carriers op de lijn heeft staan om die te calibreren. Een gigbit link kan tot wel 1W aan energie verspillen op die manier, afhankelijk van de gebruikte hardware (met name de PHY voor de ingewijden).

Een 100 Mbps lijn is als hij niks te doen heeft ook grotendeels echt "idle". Van giga naar mega is een flinke stap. Van 100 naar 10 is alleen maar zinvol voor "suspend" mode, om een wake-on-lan te kunnen doen. De energie die je zou kunnen sparen door maar 10 Mbps te gebruiken stook je dan op in andere componenten die langer actief zijn.

[cobus]

Is er dan een manier om de fritz zo in te stellen dat hij niet de snelheid omlaag gooit.

 

ps sorry voor deze offtopic vragen.