Pi nicht mehr per Netzwerk erreichbar, aber aktiv

  • So, der erste Versuch der Übersetzung eines Kernels für den Pi auf meinem Arbeitsrechner ist gescheitert. Irgend etwas fehlt noch. Aber damit habe ich schon fast gerechnet. Jedoch ist das nicht das, was mich jetzt am meisten wundert, ich werde weitere Versuche unternehmen.

    Allerdings habe ich bei der Konfiguration gesehen, daß der Kernel für den Pi nur USB1 unterstützt, nicht USB1.1 und nicht USB2. Die kompletten Optionen für USB1.1 und USB2 sind überhaupt nicht vorhanden: die Module für EHCI und UHCI existieren nicht.

    Also ist der Pi wohl nur mit einem USB1-Hub ausgestattet. Das erklärt einerseits den schlechten Durchsatz auf dem Netzwerk und könnte außerdem ein weitere Ursache des "Mysteriums" sein.

  • Hallöle PInguin,


    ...
    daß der Kernel für den Pi nur USB1 unterstützt, nicht USB1.1 und nicht USB2. Die kompletten Optionen für USB1.1 und USB2 sind überhaupt nicht vorhanden: die Module für EHCI und UHCI existieren nicht.

    Also ist der Pi wohl nur mit einem USB1-Hub ausgestattet. Das ...

    ich fürchte, da bist Du schief gewickelt.
    Der RPi hat USB 2.0. Sonst würden uns ja alle, inkl. -> wikipedia <- anschwindeln. Naja, das mag vielleicht hin und wieder auf den einen oder anderen Anbieter zutreffen :fies: ... aber - wie gesagt - Wikipedia?
    Welche Kernel-Konfiguration hast Du verwendet bzw. wo hast Du die her?

    neugierige Grüsse,
    -ds-

  • Ich bin nach dieser Anleitung vorgegangen.

    Beim Befehl "make menuconfig" werden im Gegensatz zur Kernelkonfiguration auf meinem Arbeitsrechner keine Optionen für die Module für USB1.1 und USB2 angeboten. Für mich (als Laie) sieht das so aus, als ob diese Module aus dem Kernel entfernt wurden.

  • Hallo Dreamshader,


    Code
    Da hab' ich noch was im Hinterkopf, dass der RPi ja einen internen Hub hat von dem aber nur zwei Ports nach aussen geführt wurden. Die anderen Ports verwendet die CPU selbst ( z.B. für diesen USB2Ethernet Adapter ).

    Nach meinen Erfahrungen und Ausgaben von z.B. dmesg wird Alles, was am USB-Anschluss hängt, als eigenständiges USB-Gerät erkannt. Jeder USB-Adapter, jedes Y-Kabel, .... Aus den 2 USB-Ports können dann noch wesentlich mehr werden.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • So Leutz,
    ich glaube, langsam hab' ich für heute genug geschwafelt und Unsinn verzapft :) ...


    Ich bin nach dieser Anleitung vorgegangen.
    Beim Befehl "make menuconfig" ...

    Also die kenn' ich nicht und sie scheint ja auch nicht so 100%ig zu sein.
    Empfehlen kann ich Dir allerding -> diese <- Anleitung.
    Um die Konfiguration Deines laufenden Systems zu übernehmen machst Du vor dem Compiler-Lauf ein

    Code
    zcat /proc/config.gz > .config

    .
    Abr ich glaube, das steht auch in der verlinkten Anleitung.

    Ach ja, Andreas: das mit dem internen USB-Hub stimmt schon. Und Y-Kabel werden doch nicht angezeigt, Du Schlawiner ... willst Du hier unbedarfte Besucher in die Wüste schicken :)
    ...
    Bis später, ich wollte noch meine Ergebnisse dieses sysbench posten.
    -ds-

  • Hallo Dreamshader,

    hier ein Auszug aus meinem dmesg:

    An meinem Raspberry hängt nur einem USB-Port etwas. Der andere Port ist nicht belegt. Ein USB-Hub ist auch nicht angeschlossen.
    Daraus geht hervor, dass der Raspberry jede am USB-Hub angeschlossene Komponente inkl. Adapter etc. erkennt.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Hallo zusammen,
    hier mal meine Versuche auf der RPi B-Variante mit

    Code
    Linux raspberrypi 3.10.36+ #664 PREEMPT Mon Apr 7 14:01:14 BST 2014 armv6l GNU/Linux

    als Betriebssystem.
    Beim ersten Test,

    Code
    sysbench --test=cpu --cpu-max-prime=20000 run


    dem CPU Bench kommt folgendes heraus:

    Spoiler anzeigen

    pi@raspberrypi ~ $ sysbench --test=cpu --cpu-max-prime=20000 run
    sysbench 0.4.12: multi-threaded system evaluation benchmark

    Running the test with following options:
    Number of threads: 1

    Doing CPU performance benchmark

    Threads started!

    Done.

    Maximum prime number checked in CPU test: 20000


    Test execution summary:
    total time: 1349.9744s
    total number of events: 10000
    total time taken by event execution: 1349.9069
    per-request statistics:
    min: 132.20ms
    avg: 134.99ms
    max: 2191.57ms
    approx. 95 percentile: 136.81ms

    Threads fairness:
    events (avg/stddev): 10000.0000/0.00
    execution time (avg/stddev): 1349.9069/0.00


    top sagt dazu:

    Spoiler anzeigen


    top - 05:40:52 up 2:34, 1 user, load average: 0,85, 0,35, 0,16
    Tasks: 69 total, 1 running, 68 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 98,4 us, 1,3 sy, 0,0 ni, 0,0 id, 0,0 wa, 0,0 hi, 0,3 si, 0,0 st
    KiB Mem: 448176 total, 83852 used, 364324 free, 23120 buffers
    KiB Swap: 102396 total, 0 used, 102396 free, 33140 cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    2617 pi 20 0 5380 1120 860 S 97,2 0,2 1:58.28 sysbench


    Ruckler sind schon zu spüren (wen wunderts), allerdings ist der RPi nicht abgestürzt. Ich hab keinen Desktop in Benutzung und auch weder Maus noch Tasten angeschlossen. Zum Verhalten dieser Teile kann ich daher im Moment leider nichts beitragen.

    Nach Aufsetzen eines NFS-Servers habe ich mich an die Benchmarks für Datei-Operationen herangemacht.
    Also, nach Einhängen des NFS-Laufwerks ergibt sich folgendes Bild auf dem Server:
    mount zeigt:

    Spoiler anzeigen


    /dev/root on / type ext4 (rw,noatime,data=ordered)
    devtmpfs on /dev type devtmpfs (rw,relatime,size=215824k,nr_inodes=53956,mode=755)
    tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=44820k,mode=755)
    tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
    proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
    sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
    tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=89620k)
    devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
    /dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
    nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
    /dev/sda1 on /media/netdrive type ext4 (rw,relatime,data=ordered)
    rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)


    df -m zeigt:

    Spoiler anzeigen


    Dateisystem 1M-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
    rootfs 3599 2245 1164 66% /
    /dev/root 3599 2245 1164 66% /
    devtmpfs 211 0 211 0% /dev
    tmpfs 44 1 44 1% /run
    tmpfs 5 0 5 0% /run/lock
    tmpfs 88 0 88 0% /run/shm
    /dev/mmcblk0p1 56 19 38 34% /boot
    /dev/sda1 37426 48 35455 1% /media/netdrive


    ifconfig zeigt:

    Spoiler anzeigen


    wlan0 Link encap:Ethernet Hardware Adresse 7c:dd:90:2d:4f:b2
    inet Adresse:192.168.1.113 Bcast:255.255.255.255 Maske:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
    RX packets:12123 errors:0 dropped:0 overruns:0 frame:0
    TX packets:9935 errors:0 dropped:0 overruns:0 carrier:0
    Kollisionen:0 Sendewarteschlangenlänge:1000
    RX bytes:1490645 (1.4 MiB) TX bytes:2017301 (1.9 MiB)


    und auf dem Client zeigt mount:

    Spoiler anzeigen


    /dev/root on / type ext4 (rw,noatime,data=ordered)
    devtmpfs on /dev type devtmpfs (rw,relatime,size=215824k,nr_inodes=53956,mode=755)
    tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=44820k,mode=755)
    tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
    proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
    sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
    tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=89620k)
    devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
    /dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
    192.168.1.113:/media/netdrive on /mnt type nfs (rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.113,mountvers=3,mountport=43301,mountproto=udp,local_lock=all,addr=192.168.1.113)


    df -m zeigt:

    Spoiler anzeigen


    Dateisystem 1M-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
    rootfs 7641 2553 4734 36% /
    /dev/root 7641 2553 4734 36% /
    devtmpfs 211 0 211 0% /dev
    tmpfs 44 1 44 1% /run
    tmpfs 5 0 5 0% /run/lock
    tmpfs 88 0 88 0% /run/shm
    /dev/mmcblk0p1 56 19 38 34% /boot
    192.168.1.113:/media/netdrive 37426 48 35455 1% /mnt


    ifconfig zeigt:

    Spoiler anzeigen


    wlan0 Link encap:Ethernet Hardware Adresse 7c:dd:90:0c:9b:1a
    inet Adresse:192.168.1.111 Bcast:255.255.255.255 Maske:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
    RX packets:2878 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1716 errors:0 dropped:0 overruns:0 carrier:0
    Kollisionen:0 Sendewarteschlangenlänge:1000
    RX bytes:349002 (340.8 KiB) TX bytes:250549 (244.6 KiB)


    Während des Laufs sagt top auf dem Server:

    Spoiler anzeigen


    top - 18:03:06 up 12:57, 1 user, load average: 1,70, 1,05, 0,50
    Tasks: 91 total, 1 running, 90 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 1,4 us, 45,4 sy, 0,0 ni, 42,6 id, 0,0 wa, 0,0 hi, 10,7 si, 0,0 st
    KiB Mem: 448180 total, 425232 used, 22948 free, 9720 buffers
    KiB Swap: 102396 total, 0 used, 102396 free, 368992 cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    8613 root 20 0 0 0 0 S 28,3 0,0 0:27.10 kworker/u2:0
    8553 root 20 0 0 0 0 S 11,3 0,0 0:09.76 nfsd
    8555 root 20 0 0 0 0 S 7,4 0,0 0:14.45 nfsd
    8116 root 20 0 0 0 0 S 1,3 0,0 1:08.51 kworker/u2:2
    8629 pi 20 0 5216 1376 1032 R 1,3 0,3 0:00.16 top
    3 root 20 0 0 0 0 S 0,3 0,0 0:10.87 ksoftirqd/0
    7 root 20 0 0 0 0 S 0,3 0,0 0:15.43 rcu_preempt
    20 root 20 0 0 0 0 S 0,3 0,0 0:05.23 kswapd0
    7363 root 20 0 0 0 0 S 0,3 0,0 0:07.40 kworker/0:1
    1 root 20 0 2144 712 608 S 0,0 0,2 0:03.30 init
    2 root 20 0 0 0 0 S 0,0 0,0 0:00.02 kthreadd
    5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
    8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
    9 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_sched
    10 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 khelper
    11 root 20 0 0 0 0 S 0,0 0,0 0:00.01 kdevtmpfs
    12 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 netns


    und auf dem Client:

    Spoiler anzeigen


    top - 18:01:09 up 7:25, 2 users, load average: 1,99, 1,03, 0,45
    Tasks: 77 total, 3 running, 74 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 2,1 us, 30,1 sy, 0,0 ni, 0,0 id, 47,5 wa, 0,0 hi, 20,2 si, 0,0 st
    KiB Mem: 448176 total, 425228 used, 22948 free, 8140 buffers
    KiB Swap: 102396 total, 0 used, 102396 free, 383056 cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    2645 root 20 0 0 0 0 S 34,7 0,0 0:37.21 kworker/u2:3
    2717 root 20 0 0 0 0 S 3,9 0,0 0:28.67 kworker/u2:2
    13 root 20 0 0 0 0 R 3,2 0,0 0:08.53 kworker/0:1
    2150 root -56 0 87528 1132 576 S 2,2 0,3 3:09.10 pilight-daemon
    2719 pi 20 0 5220 1356 1024 R 1,6 0,3 0:00.16 top
    1976 root 20 0 27976 1584 1124 S 1,0 0,4 0:16.01 rsyslogd
    2700 root 20 0 0 0 0 S 0,6 0,0 0:10.22 kworker/u2:0
    3 root 20 0 0 0 0 R 0,3 0,0 0:01.63 ksoftirqd/0
    7 root 20 0 0 0 0 S 0,3 0,0 0:01.12 rcu_preempt
    2449 pi 20 0 9948 1652 1000 S 0,3 0,4 0:00.81 sshd
    2718 root 20 0 5348 1108 868 D 0,3 0,2 0:02.34 sysbench
    1 root 20 0 2148 720 616 S 0,0 0,2 0:02.43 init
    2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd
    5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
    8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh

    root@raspberrypi:/mnt# time sysbench --test=fileio --file-total-size=2G --file-num=16 prepare
    sysbench 0.4.12: multi-threaded system evaluation benchmark

    16 files, 131072Kb each, 2048Mb total
    Creating files for the test...

    real 26m26.412s
    user 0m0.220s
    sys 0m15.070s
    root@raspberrypi:/mnt#

    Nach dem Test zeigt mount auf dem Server:

    Spoiler anzeigen


    /dev/root on / type ext4 (rw,noatime,data=ordered)
    devtmpfs on /dev type devtmpfs (rw,relatime,size=215824k,nr_inodes=53956,mode=755)
    tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=44820k,mode=755)
    tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
    proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
    sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
    tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=89620k)
    devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
    /dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
    nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
    /dev/sda1 on /media/netdrive type ext4 (rw,relatime,data=ordered)
    rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)


    df -m zeigt:

    Spoiler anzeigen


    Dateisystem 1M-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
    rootfs 3599 2245 1163 66% /
    /dev/root 3599 2245 1163 66% /
    devtmpfs 211 0 211 0% /dev
    tmpfs 44 1 44 1% /run
    tmpfs 5 0 5 0% /run/lock
    tmpfs 88 0 88 0% /run/shm
    /dev/mmcblk0p1 56 19 38 34% /boot
    /dev/sda1 37426 2096 33407 6% /media/netdrive


    und ifconfig zeigt:

    Spoiler anzeigen


    wlan0 Link encap:Ethernet Hardware Adresse 7c:dd:90:2d:4f:b2
    inet Adresse:192.168.1.113 Bcast:255.255.255.255 Maske:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
    RX packets:1594401 errors:0 dropped:0 overruns:0 frame:0
    TX packets:849411 errors:0 dropped:0 overruns:0 carrier:0
    Kollisionen:0 Sendewarteschlangenlänge:1000
    RX bytes:2262355988 (2.1 GiB) TX bytes:80331925 (76.6 MiB)


    und auf dem Client zeigt mount:

    Spoiler anzeigen


    /dev/root on / type ext4 (rw,noatime,data=ordered)
    devtmpfs on /dev type devtmpfs (rw,relatime,size=215824k,nr_inodes=53956,mode=755)
    tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=44820k,mode=755)
    tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
    proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
    sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
    tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=89620k)
    devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
    /dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
    192.168.1.113:/media/netdrive on /mnt type nfs4 (rw,relatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.111,local_lock=none,addr=192.168.1.113)


    df -m zeigt:

    Spoiler anzeigen


    Dateisystem 1M-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
    rootfs 7641 2553 4734 36% /
    /dev/root 7641 2553 4734 36% /
    devtmpfs 211 0 211 0% /dev
    tmpfs 44 1 44 1% /run
    tmpfs 5 0 5 0% /run/lock
    tmpfs 88 0 88 0% /run/shm
    /dev/mmcblk0p1 56 19 38 34% /boot
    192.168.1.113:/media/netdrive 37426 2096 33407 6% /mnt


    ifconfig zeigt:

    Spoiler anzeigen


    wlan0 Link encap:Ethernet Hardware Adresse 7c:dd:90:0c:9b:1a
    inet Adresse:192.168.1.111 Bcast:255.255.255.255 Maske:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
    RX packets:828621 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1588094 errors:0 dropped:0 overruns:0 carrier:0
    Kollisionen:0 Sendewarteschlangenlänge:1000
    RX bytes:60974477 (58.1 MiB) TX bytes:2300922651 (2.1 GiB)


    Der Server meckerte während des Laufs ziemlich heftig:

    Spoiler anzeigen


    [46591.690793] ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
    [46591.692174] ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
    [46591.693609] ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
    [46929.801821] ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 5 in queue 2
    ...
    [47504.419638] ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 3 in queue 2
    [47504.421087] ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 3 in queue 2
    [47504.422437] ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 3 in queue 2
    [47504.423748] ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 3 in queue 2
    [47504.427755] ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 15 in queue 2
    [47504.429392] ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 15 in queue 2

    Die Meldung kommt gefühlte 1000 mal. Der Client hingegen schweigt still :) ...

    Dieser Endstand ist jetzt de Ausgangs-Situation für den zweiten Bench mit Datei-Zugriffen.

    root@raspberrypi:/mnt# sysbench --test=fileio --file-total-size=2G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 --file-num=16 run
    sysbench 0.4.12: multi-threaded system evaluation benchmark

    Ergebnis:

    Spoiler anzeigen


    Running the test with following options:
    Number of threads: 1
    Initializing random number generator from timer.

    Extra file open flags: 0
    16 files, 128Mb each
    2Gb total file size
    Block size 16Kb
    Number of random requests for random IO: 0
    Read/Write ratio for combined random IO test: 1.50
    Periodic FSYNC enabled, calling fsync() each 100 requests.
    Calling fsync() at the end of test, Enabled.
    Using synchronous I/O mode
    Doing random r/w test
    Threads started!
    Time limit exceeded, exiting...
    Done.

    Operations performed: 5846 Read, 3897 Write, 1552 Other = 11295 Total
    Read 91.344Mb Written 60.891Mb Total transferred 152.23Mb (519.63Kb/sec)
    32.48 Requests/sec executed

    Test execution summary:
    total time: 300.0008s
    total number of events: 9743
    total time taken by event execution: 244.6767
    per-request statistics:
    min: 0.10ms
    avg: 25.11ms
    max: 1260.02ms
    approx. 95 percentile: 72.12ms

    Threads fairness:
    events (avg/stddev): 9743.0000/0.00
    execution time (avg/stddev): 244.6767/0.00


    Während dieses zweiten Benchmark gibt ein top auf dem Server

    Spoiler anzeigen


    top - 19:22:20 up 14:16, 1 user, load average: 1,88, 0,80, 0,36
    Tasks: 90 total, 2 running, 88 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 1,4 us, 30,3 sy, 0,0 ni, 31,4 id, 28,5 wa, 0,0 hi, 8,3 si, 0,0 st
    KiB Mem: 448180 total, 423592 used, 24588 free, 26936 buffers
    KiB Swap: 102396 total, 0 used, 102396 free, 351688 cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    8553 root 20 0 0 0 0 S 12,5 0,0 0:46.92 nfsd
    8297 root 20 0 0 0 0 S 10,9 0,0 2:43.79 kworker/u2:1
    8684 root 20 0 0 0 0 S 4,5 0,0 0:16.34 kworker/u2:0
    8116 root 20 0 0 0 0 S 2,2 0,0 2:57.48 kworker/u2:2
    7361 root 20 0 0 0 0 D 1,3 0,0 0:08.58 usb-storage
    8556 root 20 0 0 0 0 R 1,3 0,0 0:33.04 nfsd
    8716 pi 20 0 5216 1376 1032 R 1,3 0,3 0:00.15 top
    3 root 20 0 0 0 0 S 0,6 0,0 0:17.89 ksoftirqd/0
    7501 root 20 0 0 0 0 S 0,6 0,0 0:01.52 jbd2/sda1-8
    7 root 20 0 0 0 0 S 0,3 0,0 0:21.06 rcu_preempt
    20 root 20 0 0 0 0 S 0,3 0,0 0:08.71 kswapd0
    1662 root 20 0 1748 492 408 S 0,3 0,1 0:25.84 ifplugd
    2480 pi 20 0 9700 1804 988 S 0,3 0,4 0:07.68 sshd
    1 root 20 0 2144 712 608 S 0,0 0,2 0:03.49 init
    2 root 20 0 0 0 0 S 0,0 0,0 0:00.02 kthreadd
    5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
    8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh


    aus und der Client meint während des Laufs bei der Eingabe von top:

    Spoiler anzeigen


    top - 19:20:01 up 8:44, 2 users, load average: 0,51, 0,13, 0,09
    Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 0,4 us, 24,6 sy, 0,0 ni, 0,4 id, 69,4 wa, 0,0 hi, 5,3 si, 0,0 st
    KiB Mem: 448176 total, 434500 used, 13676 free, 3312 buffers
    KiB Swap: 102396 total, 0 used, 102396 free, 399328 cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    2750 root 20 0 0 0 0 S 18,2 0,0 0:03.30 kworker/u2:1
    13 root 20 0 0 0 0 S 3,9 0,0 0:53.34 kworker/0:1
    2150 root -56 0 87528 1132 576 S 2,3 0,3 4:08.99 pilight-daemon
    2754 root 20 0 5380 1272 944 S 1,3 0,3 0:00.32 sysbench
    2756 pi 20 0 5220 1356 1024 R 1,3 0,3 0:00.16 top
    2741 root 20 0 0 0 0 S 1,0 0,0 0:05.68 kworker/u2:2
    3 root 20 0 0 0 0 S 0,3 0,0 0:06.82 ksoftirqd/0
    1 root 20 0 2148 720 616 S 0,0 0,2 0:02.60 init
    2 root 20 0 0 0 0 S 0,0 0,0 0:00.01 kthreadd
    5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
    7 root 20 0 0 0 0 S 0,0 0,0 0:04.22 rcu_preempt
    8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
    9 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_sched
    10 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 khelper
    11 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kdevtmpfs


    Tja, und last but not least die "Statistik" nach dem Lauf.
    Beim Server zeigt mount an:

    Spoiler anzeigen


    /dev/root on / type ext4 (rw,noatime,data=ordered)
    devtmpfs on /dev type devtmpfs (rw,relatime,size=215824k,nr_inodes=53956,mode=755)
    tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=44820k,mode=755)
    tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
    proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
    sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
    tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=89620k)
    devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
    /dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
    nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
    /dev/sda1 on /media/netdrive type ext4 (rw,relatime,data=ordered)
    rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)


    df -m zeigt:

    Spoiler anzeigen


    Dateisystem 1M-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
    rootfs 3599 2246 1163 66% /
    /dev/root 3599 2246 1163 66% /
    devtmpfs 211 0 211 0% /dev
    tmpfs 44 1 44 1% /run
    tmpfs 5 0 5 0% /run/lock
    tmpfs 88 0 88 0% /run/shm
    /dev/mmcblk0p1 56 19 38 34% /boot
    /dev/sda1 37426 2096 33407 6% /media/netdrive


    ifconfig zeigt:

    Spoiler anzeigen


    wlan0 Link encap:Ethernet Hardware Adresse 7c:dd:90:2d:4f:b2
    inet Adresse:192.168.1.113 Bcast:255.255.255.255 Maske:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
    RX packets:1730679 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1038896 errors:0 dropped:0 overruns:0 carrier:0
    Kollisionen:0 Sendewarteschlangenlänge:1000
    RX bytes:2336934294 (2.1 GiB) TX bytes:324343062 (309.3 MiB)


    und beim Client zeigt mount:

    Spoiler anzeigen


    /dev/root on / type ext4 (rw,noatime,data=ordered)
    devtmpfs on /dev type devtmpfs (rw,relatime,size=215824k,nr_inodes=53956,mode=755)
    tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=44820k,mode=755)
    tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
    proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
    sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
    tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=89620k)
    devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
    /dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
    192.168.1.113:/media/netdrive on /mnt type nfs4 (rw,relatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.111,local_lock=none,addr=192.168.1.113)


    df -m zeigt:

    Spoiler anzeigen


    Dateisystem 1M-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
    rootfs 7641 2553 4734 36% /
    /dev/root 7641 2553 4734 36% /
    devtmpfs 211 0 211 0% /dev
    tmpfs 44 1 44 1% /run
    tmpfs 5 0 5 0% /run/lock
    tmpfs 88 0 88 0% /run/shm
    /dev/mmcblk0p1 56 19 38 34% /boot
    192.168.1.113:/media/netdrive 37426 2096 33407 6% /mnt


    ifconfig zeigt:

    Spoiler anzeigen


    wlan0 Link encap:Ethernet Hardware Adresse 7c:dd:90:0c:9b:1a
    inet Adresse:192.168.1.111 Bcast:255.255.255.255 Maske:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
    RX packets:1016787 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1723212 errors:0 dropped:0 overruns:0 carrier:0
    Kollisionen:0 Sendewarteschlangenlänge:1000
    RX bytes:300640325 (286.7 MiB) TX bytes:2378163800 (2.2 GiB)

    Jetzt hoffe ich, dass der ganze Kram hier auch irgendwie hilfreich ist.
    War jedenfalls mal eine nette Abwechslung zu meinen Displays ...

    cu,
    -ds-

  • Na holla dreamshader :thumbs1:

    Prima, na da lässt sich je etwas entnehmen:
    Das Ruckeln kommt, weil die Konsole nicht mehr jedes Paket bekommt, offenbar timing-Probleme in dem überlastetem RPi... das ist "normal", das Log hast du ja gefunden :lol:

    Wie es aussieht, hast du auch keine IP-Abhänger gehabt... nicht mal Paketverluste... bei mir haben sich die Paketverluste auf >1400 angehäuft... naja, das Timing klappt dann nicht mehr so ganz geschmeidig... Ich habe auch keinen lupenreinen WLAN-Kanal, da hängen noch andere Mieter mit drauf bzw. dicht daneben... keine Aufregung..

    Nach meinen aktuellen Messungen sehe ich meine Vermutung erhärtet... Aber mal zum Test:

    Messaufbau:
    Netzteil: wie in Post 23 beschrieben
    Strommessung: (in den Bildern rot:( mit 0,12 Ohm Shunt in der Masseleitung der Versorgungsspannung
    Spannungsmessung: (in den Bildern gelb:( vom gleichem Massepunkt wie Strommessung nach +5V vor den Shunt
    Raspi: WLAN, 3 LEDs (aus), 3 DS1820 an 1W (unbenutzt)

    1. Messung (Leerlauf)
    wie in Post 25 unverändert (warum auch?)

    2. Messung (100% CPU Last wie gestern beschrieben mit sysbench)
    Der "Basis"-Strom erhöht sich "geringfügig" ca. 370mA...

    ytpqeywt.png%20%20

    der Pulsspitzenstrom liegt nun bei ca. 753mA.

    s2jza8ss.png

    Das ist keine dramatischen Erhöhung, jedenfalls nicht so, wie ich erwartet hätte. Die CPU scheint also nicht der wirkliche Stromfresser zu sein...

    Aber nun mal was Interessantes: Die Spannungen:
    Mein NT liefert etwas über 5V, genauer ca. 5,08V als "Grundspannung"

    ffykwbff.png

    Wenn die Pulse da sind, erhöht sich die Spannung !!!
    Ich diskutier das dann mal am Ende...

    cgmhsa45.png

    3. Messung: hohe WLAN-Load durch Anlegen von 16 File a 128MB auf einem remote stehenden NAS LW. (per mount verbunden)
    Der Grundstrom erhöht sich auf fast 500mA, WLAN zieht Strom :D

    r5thf4k5.png

    Und: Der Spitzenpegel nähert sich 860mA (!), war teilweise drüber, aber diese Messung hab ich nicht als Bild...

    8rcti5g7.png


    Ich schick diesen Post jetzt mal ab (wegen max. 10 Bilde/Post) und schreibe meine Einschätzung dann weiter...

  • Es gibt eine gute und eine schlechte Nachricht.

    Zuerst die Gute: wir sind mit diesem Problem definitiv nicht alleine. Auf https://github.com/raspberrypi/linux/issues gibt es etliche Hilferufe wegen abgerissener Netzwerk- und USB-verbindungen.

    Die schlechte Nachricht: dieser Fehler existiert wohl schon seit 2012, denn schon da gab es die ersten, die dieses Phänomen beobachteten.

    Beispiele:
    https://github.com/raspberrypi/linux/issues/470
    https://github.com/raspberrypi/linux/issues/136

    Ich habe jetzt mal wie in einigen der Beiträge dort in /boot/cmdline.txt folgende Einträge hinzugefügt:

    Code
    smsc95xx.turbo_mode=N dwc_otg.speed=1

    Der zweite Parameter setzt den USB-Chip auf USB-1.1-Geschwindigkeit, also max 12MBit. Damit reduziert sich zwar auch die maximale Netzwerkgeschwindigkeit auf 10MBit, und Geräte, die USB-2 benötigen, wie z.B. USB-Kameras, laufen damit nicht an den USB-Ports.

    Da ich aber keine solchen Geräte an dem Pi hängen habe, und meine Außenleitung sowieso nicht mit 100MBit mithalten kann, ist diese Reduzierung für mich in Ordnung. Ob sie überhaupt etwas bringt, müssen die nächsten Stunden zeigen.

    Bisher (seit ca 3 Stunden) habe ich danach noch keinen Ausfall wieder gehabt. Im Gegenteil: ich habe sogar irgend wie den Eindruck, als wenn der Pi besser läuft: im Syslog tauchte bisher kein einziges "lost connection" o.ä. auf, und selbst der Lighttpd scheint die Wiki-Seiten schneller auszuliefern.

    Ich weiß, daß das eigentlich nicht sein kann, aber das ist mein subjektiver Eindruck: die Verbindungen erscheinen schneller. Selbst bei der Verbindung per ssh (mit Pub-Key) scheint es schneller zu gehen, bis der Cursor da ist. Und "top" zeigt weniger Auslastung an, wenn ich mich mit OwnCloud verbinde.

    Vielleicht erscheint mir die Kiste auch nur schneller, weil ich müde bin. Werde jetzt erst mal darüber schlafen und morgen mal in die Logdateien gucken.

  • Die Spannung hat sich weiter erhöht...

    ktei6qcp.png

    und erreicht in den Spitzen wieder 5,4V

    7me4enlo.png

    Der Vollständigkeit halber auch mal der Abstand der Peaks: 17,3 mySec, konstant (!)

    9xcqunhg.png
    So, was will uns das alles sagen?

    Offenbar habe ich ein NT, das progressiv regelt (also eigentlich falsch) und bei Lasterhöhung die Spannung bis auf 5,4V anhebt.
    In wie weit das auf Dauer gut geht, wage ich nicht zu beurteilen, in meinem Szenario tauchen diese Lasten nicht auf, insofern werde ich lediglich einen Kühlkörper spendieren und gut.

    Die Frage, die jetzt im Raum steht ist allerdings: Was machen andere (Handy-) NT bei den Pulsen? Spannung erhöhen, einbrechen oder ideal wegregeln?

    Und damit ergibt sich ein Indiz, dass evtl. eine einbrechende Spannung über den Linearregler bis zur CPU oder dem USB/Ethernet-Chip durchschlägt hier Fehler induziert.

    Nun müßte man diese Messung mal mit einem NT der instabileren Fraktion machen... am besten dann mit Speisung über MicroUSB ...

    Jo, ich hau mich erstmal hinne.... nächtle...

  • Moin!

    So, ich bin (halbwegs) ausgeschlafen, und der Pi läuft seit ca. 12 Stunden mit den von mir hinzugefügten Parametern in /boot/cmdline.txt ruhig und ohne Macken. Im syslog taucht seit dem keine einzige Meldung auf, die auf Probleme mit dem Netzwerk und/oder USB hinweisen. Vorher hatte ich sehr häufig diese Meldungen im syslog:

    Code
    ERROR::dwc_otg_hcd_urb_enqueue:515: Not connected

    und

    Code
    smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup


    Die sind seit gestern Nacht nicht wieder aufgetaucht. Außerdem habe ich in der letzten Stunde intensiv mit dem auf dem Pi laufenden DokuWiki gearbeitet und ich fühle, daß es besser "flutscht". Ich weiß nicht, wie ich es ausdrücken soll, aber es geht einfach besser. Vorher musste ich manchmal mehrere Sekunden warten, bis nach dem Klick auf "Speichern" der Vorgang auch wirklich abgeschlossen war. Das geht jetzt definitiv und messbar schneller!

    Eine mögliche Erklärung dafür wäre, daß der verbaute USB-Chip nicht wirklich für den Betrieb im High-Speed-Modus geeignet ist. Ich weiß aus Erfahrung, daß vieles, was sich auf dem Markt befindet, das Label "USB 2.0 High-Speed" nicht wirklich verdient hat. Die Hersteller nehmen meistens die billigsten Chips, die unter Laborbedingungen und mit großzügigen Runden in den Berechnungen gerade so eben die Spezifikation erfüllen, nur, damit sie sich erdreisten können, auf die Verpackungen "USB 2.0 High-Speed" zu drucken, und weil sie wissen, daß sie keine juristischen Konsequenzen fürchten müssen.

    Am krassesten macht sich das bei USB-Speicher bemerkbar, aber ich habe auch schon PCI-Karten in der Hand gehabt, mit denen ältere Rechner mit USB-2.0 nachgerüstet werden können, die aber noch nicht einmal den USB-1.1-Standard schaffen. Damit einen Scanner zu betreiben ist dann eine Tagesaufgabe. :(

    Ich will jetzt nicht sagen, daß die Hersteller des Raspberry "geschummelt" haben. Meistens ist es so, daß die Hersteller von PC-Harware eher von den Chip-Herstellern, also den Zulieferern, betrogen werden. Nicht selten wird in der laufenden Produktion sogar völlig andere Ware geliefert, als während der Entwicklung des Endproduktes für die Testzwecke zur Verfügung gestellt wurde. Oder die Produktions-Sorgfalt wurde aus Kostengründen heruntergefahren.

    Wie dem auch sei: wenn es daran liegen sollte, daß der USB-Chip nicht geeignet für den Betrieb im High-Speed-Modus ist, wäre das eine Erklärung für die Ausfälle. Und auch für den besseren Datendurchsatz beim Ausliefern von Web-Seiten, denn weniger Datenfehler auf dem Bus bedeutet, daß weniger Wiederholungen nötig sind, und das wiederum bedeutet im Endeffekt höhere Effizienz. Was nützt ein Formel-1-Rennwagen, der alle 50 Meter ausgeht? Den kann ich mit einem konstant fahrenden Trabbi locker ausstechen!

    Zentris: könntest Du mit Deinem Ozzi-Guck vielleicht dahingehend mal Messungen machen? Ich bin kein richtiger Elektroniker, aber ich bin sicher, das man das messen können muss.

    Kann es nicht sogar sein, daß wir Ursache und Wirkung vertauscht haben? Bisher sind wir davon ausgegangen, daß die Spannungseinbrüche den USB-Chip lahmlegen. Kann es nicht auch umgekehrt sein, daß die Spannungsspitzen (oder Lastspitzen) das Ergebnis der Datenkollisionen auf dem Bus sind, weil der Chip kein High-Speed verträgt?

    Für mich als Nicht-Elektriker hört sich das logisch an. Aber ich lasse mich da gerne eines Besseren belehren.

    Einmal editiert, zuletzt von PInguin (14. April 2014 um 10:43)

  • Nach über 20 Stunden Betrieb mit gedrosseltem USB-Chip kann ich eine positive Bilanz ziehen: ich habe heute nicht nur mit dem Wiki auf dem Pi gearbeitet, sondern auch mit apt viele Pakete installiert, deinstalliert, neu installiert, wieder deinstalliert, wieder neuinstalliert, usw, bis die Leitung glühte. Zwischendurch immer den Cache geleert, damit apt die Sachen auch jedesmal neu runterladen muss. Und kein einziges mal hat mich der Pi dabei angeschwiegen!

    Das Netzwerk ist stabil, und im syslog stehen seit dem Neustart genau 9 (in Worten: neun) neue Zeilen. Davon sind 3 von ddclient, der die IP beim DynDNS-Dienst alle 5 Stunden erneuert hat, 5 Zeilen sind von Postfix, der eine Nachricht versendet hat, und eine, die erste, ist die Startmeldung vom Syslogd selber.

    Vor diesen Boot-Parametern hatte ich mehrere hundert Einträge pro Tag im Syslog, davon 99% Meldungen vom USB-System, daß neue Geräte gefunden wurden, daß Verbindungen abgebrochen sind, usw.

    Für mich sieht es sehr danach aus, daß "das Mysterium" mit dem Drosseln des USB-Chips beendet ist!

    Natürlich kann diese Drosselung nicht die letztendliche Lösung sein, sondern höchstens eine Linderung der Symptome. Aber ich glaube, jetzt haben wir einen festen Ansatzpunkt, an dem man gezielt weitersuchen kann.

    Bracew, Andreas: probiert es doch bitte auch einmal mit diesen Bootparametern aus und berichtet uns dann, ob es etwas gebracht hat.

    ______

    Ergänzung 15.04.14, 15:30h:

    Auch am Tag 2 nach dem Hinzufügen der Boot-Parameter habe ich noch keinen Ausfall des Netzwerkes erlebt! Der Pi läuft immer noch stabil, egal, wie sehr ich das Wiki und die OwnCloud darauf in Anspruch nehme!

    ________
    Ergänzung 2, 15.04.14, 19:00h:
    Also mein Pi läuft jetzt mit stabiler Netzwerkverbindung. Sobald ich den Parameter dwc_otg.speed=1 aus der cmdline.txt entferne, übersteht das Netzwerk nicht mal das erste "apt-get update". Das ist beliebig reproduzierbar!

    Leider habe ich jetzt das Problem, daß weder die USV, noch die Maus, die ich zum Runterfahren und Neustarten angeschlossen habe (mit triggerhappy), erkannt werden. Irgendwas ist ja immer. ;)

    Als nächstes werde ich also probieren, ob ich die Peripherie-Geräte wieder ans Laufen kriege, wenn ich einen aktiven USB-Hub dazwischen klemme.

    Einmal editiert, zuletzt von PInguin (15. April 2014 um 19:10)

  • Faszinierend ;) :denker: :denker:

    Das dieser "Patch" bei dir funktioniert (mit den Kollateralschäden) ist schon etwas "gespenstisch"...

    Hast du noch einen andere RPi, an dem das reproduzierbar ist?

    :angel:
    Kann es sein, dass du Strom aus nicht genfreiem Anbau bekommst und dein Atomstromfilter nicht ordnungsgemäß gereinigt wurde, so dass die Hyperion-Schwingungen III.Ordnung in Blafasel-Resonanz mit dem Subkutangerüst des RPi kommen, so dass die Binärordnung der Bits im Speicher azyclisch permutieren ?
    Liegt ja fast auf der Hand :cool:
    :angel:


  • Faszinierend ;) :denker: :denker:

    Ja, Mr. Spock!

    Zitat


    Das dieser "Patch" bei dir funktioniert (mit den Kollateralschäden) ist schon etwas "gespenstisch"...

    Wieso gespenstisch? Nach dem, was ich darüber gelesen habe, scheine ich nicht der erste zu sein, bei dem dieser Parameter Wirkung zeigt.

    Zitat


    Hast du noch einen andere RPi, an dem das reproduzierbar ist?

    Nein, ich habe nur einen Pi, kein Pi-Pi... :lol:

    Zitat


    :angel:
    Kann es sein, dass du Strom aus nicht genfreiem Anbau bekommst und dein Atomstromfilter nicht ordnungsgemäß gereinigt wurde, so dass die Hyperion-Schwingungen III.Ordnung in Blafasel-Resonanz mit dem Subkutangerüst des RPi kommen, so dass die Binärordnung der Bits im Speicher azyclisch permutieren ?
    Liegt ja fast auf der Hand :cool:
    :angel:

    Ich habe jedes Elektron und jede Elektronin einzeln aus biologisch abbaubarer Bodenhaltung bezogen und mit dem Fluxkompensator den Spin gleichgerichtet. Reicht das?

  • Hallo zusammen,

    ich muss gestehen, dass ich das Thema etwas überflogen habe, aber wohl geschlussfolgert habe, dass es keine eindeutige Lösung für das Problem gibt.

    Ich hatte damals mit der Rev 1 häufiger WLAN Abbrüche, die auch nur durch einen Neustart zu beheben waren.

    Nun hatte ich mit der Rev 2 schon ewig lange dieses Problem nicht mehr. Letzte Woche habe ich allerdings mein ewig vorhandenes System von einer 8GB SD Karte auf eine 16 GB SD Karte überspielt
    und seitdem wieder mit den WLAN Abbrüchen zu kämpfen. Am Setup, Netzteil, Hardware, etc hat sich gar nichts geändert. Nichtmal der physische Standort des Pi.

    Nach unbestimmter Zeit, meldet mit Putty, dass die Verbindung weg sei. Im Router sehe ich dann eine tatsächliche Abmeldung aus dem WLAN. Ca. 1-2 Minuten nach dem Abbruch ist der
    Pi allerdings wieder erreichbar.

    Merkwürdig, oder?

  • Das er sich wieder verbindet, hängt vermutlich mit dem ifplugd - Daemon zusammen: Du wirst dhcp eingestellt haben und der Daemon versucht, nach der Trennung nach einer Weile wieder ein DHCP Lease zu bekommen.
    Offenbar klappt das, weil die Interface-Konfiguration nicht verloren gegangen ist.
    Bei anderen geht diese verloren (Thema USB-Reconfiger) und die eth0/wlan0-Konfiguration ist weg.

    Hast du mal in die Logs geschaut, was die Ursache des Disconnects war?

    ifplugd - Daemon:
    Es gibt ja hier im Forum den Tip, diesen Daemon zu deaktivieren, was bei einigen ja offenbar zielführend war, mir sich jedoch nicht erschließt: Ich tippe in diesen Fällen immer auf anderweitige Konfigurationsfehler... aber naja...

  • Moin Zentris,


    ...
    ifplugd - Daemon:
    Es gibt ja hier im Forum den Tip, diesen Daemon zu deaktivieren ...

    also Konfigurationsfehler? Das wäre aber dann der pure Zufall, wenn alle deren Fehlerbild mit der Deinstallation des ifplugd verschwunden ist, die gleichen Konfigurationsfehler haben.
    Ich brauch ihn nicht, er stört, ... also weg damit und Ruhe :) ...

    Schönen Tag noch,
    -ds-

  • Bei mir läuft er auf _allen_ RPs "und das ist gut so ", er tut.

    Warum nicht Konfigurationsfehler?

    "Millionen Fliegen können nicht irren?" :lol:

    Ich lese recht oft/viel diverse "tut" im Netz und oft stehen da so Sachen drin, die, wenn schon nicht falsch, so doch nicht korrekt sind... oder zumindest nicht schaden, aber auch nicht nutzen - Seiteneffekte? ... :angel:

    Es gibt ja bei Konfigurationsfehlern bekanntlich verschiedene Ausprägungen:
    1) Fehler fällt sofort auf, weil entweder das Programm den Fehler "entdeckt" oder das Programm totalen Mist macht.

    2) Fehler fällt nicht gleich auf, aber mit der Zeit, weil irgendwas anderes nicht so funktioniert, weil Vorrausetzungen fehlerhaft (Bsp: iptables falsch - keine Zugriff über port xyz - natürlich erst, wenn man von ausserhalb drauf zugreifen will)

    3) der Fehler fällt gar nicht auf: jedenfalls nicht direkt. Weil erstmal alles tut. Bzw. eigendlich nicht alles, aber nur manchmal, nicht reproduzierbar... ist auch nicht wirklich reproduzierbar, weil abhängig von ganz bestimmten Vorrausetzungen (WLAN: Pegelstärke, Signal/Rauschabstand, ab der der Empfänger nicht mehr will, Nebensprechen wegen benachtbarter Kanäle, Last auf der Leitung, Spannungsschwankungen)

    Ich hatte mal den Fall, dass ein Filesystem immer voll lief, weil die Logs kein "housekeeping" hatten. Ging bis zum Systemstillstand...
    Dann wurde ein Script eingerichtet und per cronjob regelmäßig gestartet... der sollte dann aufräumen... hm, ja, leider wurden da freie Byte und freie Blockanzahl bei der Berechung durcheinander gebracht... naja...:mad_GREEN:

    Aber wie wir ja wissen: "Bei Nebenwirkungen fragen Sie Ihren Arzt oder Therapeuten..." :lol:

  • Hallo zusammen,

    jetzt habe ich einige Tage hier nicht mehr reingeschaut - aber es hat sich wieder mal viel ereignet.

    PInguin: Die Drosselung des USB-Chips in einer Weise, dass er Maus / Tastatur nicht mehr erkennt, ist für mich keine Lösung. Andererseits ist es interessant, dass das Mysterium auf diese Weise bei Dir verschwunden zu sein scheint.

    Ich habe vor ein paar Tagen zwei neue Raspberries geschenkt bekommen (ja, bisher wurden mir alle geschenkt - auch von Firmen, damit ich damit irgendwas Sinnvolles anstelle).

    Der eine verfügt über eine SD-Karte mit vorinstalliertem Raspbian Wheezy (Version: liefere ich hier nachher nach) ist über GPIO an ein LCD-Display angeschlossen. Demzufolge muss das Teil ein wenig mehr Strom abgeben als das andere Modell vorher.

    In den Stunden, in der das Teil am Netz hing, hat sich kein Mysterium ereignet.


    Bei dem anderen werde ich in den kommenden Tagen die brandaktuelle Version von Raspbian installieren und dann meinetwegen auch mit Pinguin's Bootparametern experimentieren.

    Aber Nichterkennen von USB-Standardhardware, die keinen nennenswerten Beitrag zum Datentransfer beisteuert, ist für mich keine Lösung. Meine Software-Lösung fängt das Mysterium zuverlässig ab - wie gesagt, mir reicht das erstmal.

    :s :s

    Was mir gerade einfällt - und mich beginnt sehr nachdenklich zu machen: Ich bin ja an eine 46kB-Leitung angeschlossen. Diese maximal ca. 46.000 Bits/s, die da durch die Leitung schlendern, sind ja gerade mal 0,5 Promille, die die sonstige Hardware erlaubt. Das ist für mich auch nichts, was ich als große Belastung des Systems USB-LAN-Chip einstufen würde.
    :s

    Fortsetzungen folgen ...

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.


  • ...
    Warum nicht Konfigurationsfehler?
    ...

    Nun ja, prinzipiell gebe ich Dir ja recht ... da ist vermutlich irgend etwas anderes im Argen.
    Aber in diesem Fall habe ich keine Lust Ursachenforschung zu betreiben und halte mich an die alte IT-Weisheit "Nichts läuft so gut und so lange wie ein Provisorium" ...

    cheers,
    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!