[Fli4l_dev] Langsamer Downstream mit IGEL bzw. WinNET P640

[Alexander Dahl]

Moin,

Heinz-Peter Faasen schrieb Donnerstag,  7. November 2019, 10:26 (CET):
>> ich habe an einem Standort einen fli4l-Router auf einem IGEL (WinNET
>> P640) laufen, seit mehreren Jahren. Der hängt hinter einem Kabelmodem
>> (Fritz!Box) als reiner Ethernet-Router. Aktuell ist 4.0 testing drauf
>> mit Kernel 4.19.80. Die 100 MBit onboard NIC geht zur Fritz!Box, der
>> Treiber ist IIRC 'via-rhine'.
>
> hast Du schon mal recherchiert, ob der evtl. irgendwelche Optionen 
> benötigt, damit er ordentlich läuft?

Noch nicht, muss ich noch machen. Wie gesagt, ich hab die Kiste seit
fli4l 3.x laufen seit ca. 2013 und da waren wir noch bei ganz anderen
Kernel-Versionen. Leider hab ich da keine tarballs zum Bauen mehr, das
ging immer aus dem SVN bei mir und ich hebe immer nur die letzten zwei
bis drei Build-Ordner auf.

>> Zum LAN hin ist eine Glasfaser-NIC drin,
>> Treiber ist 'tg3'. Die Hardware kann volle 100 MBit/s routen, hat sie
>> zumindest in der Vergangenheit schon gemacht.
>> 
>> Stöpsel ich mich mit dem Laptop direkt an die Fritz!Box kann ich mit 100
>> MBit/s aus dem Internet ziehen. Gehe ich hinter den IGEL, kommen nur
>> noch ca. 6 bis 8 MBit/s durch. iperf von/zum IGEL geht mit vollen 100
>> MBit/s (da ist ein alter 100 MBit/s Switch dazwischen).
>
> Melde Dich mal auf dem IGEL an (Konsole oder ssh) und mache einen 
> Download, z.B. von einem ISO:
>
> wget 
> http://ftp.halifax.rwth-aachen.de/ubuntu-releases/bionic/ubuntu-18.04.3-desktop-amd64.iso
>
> Alles in einer Zeile, falls da was umgebrochen wird.

Ja hab ich gestern schon gemacht. Da kommen ca. 6 MBit durch. :-/

>> CPU-Last und Load sind niedrig. Ich kann keinen offensichtlichen Grund
>> sehen, warum das so lahm ist. Das einzig auffällige im Log ist das hier:
>> 
>> 
>>   * [rc001.winnet-pc640] load drivers for WinNet PC640 hardware
>> VIA RNG detected
>> cryptodev: loading out-of-tree module taints kernel.
>> cryptodev: driver 1.10 loaded.
>> padlock_aes: Using VIA PadLock ACE for AES algorithm.
>> w83627hf: w83627hf: Found W83697HF chip at 0x290
>> ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000295-0x0000000000000296 (\IP) (20180810/utaddress-213)
>> ACPI: This conflict may cause random problems and system instability
>> ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
>
> Die sieht man auf fast jeder HW, weil ACPI selten konform implementiert 
> ist. Probleme hat es bislang aber nicht gemacht.

Meine ich auch. sensors etc. hat ja für die Kiste auch ewig problemlos
funktioniert.

>> w83627hf w83627hf.656: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().                                            [ OK ]
>
> Das ist imho ein Problem, das aus lm-sensors kommt. Deaktiviere das 
> Paket mal zu Testzwecken.

Hmm, das hieße also opt hwsupp ausschalten. Werde ich testen.

>> Leider weiß ich nicht, seit wann das schon so lahmt, aber vielleicht hat
>> ja hier jemand eine Idee, wie ich das Problem eingrenzen kann?
>
> Mache bitte mal ein "ip address" auf der Konsole.

Ja da bekomme ich 19 Interfaces inkl. lo, br*, vlans, wlan*, dummy* und
tun* … ;-)

>> P.S.: eine ähnliche Konfiguration mit 4.0 trunk läuft auf einem Alix 2D3
>> einwandfrei, da kann ich meine Bandbreite voll ausschöpfen.
>
> Wenn CPU-Last und RAM-Auslastung unauffällig sind, wird man an den 
> Treibern drehen müssen.

Entweder das, wahlweise mit Optionen beim Laden oder über sysfs. Im
schlimmsten Fall ist es ein Problem im Kernel, aber das zu bisecten
könnte schwierig werden.

Grüße
Alex

-- 
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6